Frontend-Performance in der Praxis: Ressourcenhinweise, Critical CSS und Code-Splitting bei jobs.at

Kontext: Warum Performance für jobs.at geschäftskritisch ist

Im Tech Talk „How we optimize our Front End“ von Jürgen Ratzenböck (jobs.at Recruiting GmbH) ging es um konkrete, praxistaugliche Maßnahmen, mit denen das Team die Web-Performance der Plattform verbessert. Ratzenböck leitet die Technologie bei jobs.at und arbeitet täglich an Backend und Frontend – mit einem Schwerpunkt auf PHP und dem Laravel-Framework sowie Vue.js auf der Frontend-Seite für Single-Page-Application-Produkte.

jobs.at ist ein kleines Team aus Linz, das eine schnelle, einfach zu bedienende Jobplattform betreibt – mit einem großen Stellen-Inventar quer durch Branchen und Gemeinden in Österreich. Der Vortrag nannte rund 58.000 aktive Jobs und über 830.000 Sessions pro Monat. Bei dieser Größenordnung zählen Ladezeit und Interaktivität – sowohl für Nutzerbindung als auch fürs Ranking in der Suche.

Die Motivation fasste Ratzenböck klar zusammen: Die tolerierbare Wartezeit im Web ist stark gesunken. Nutzer springen bei langsamen Seiten schnell ab. Wer bleiben soll, braucht eine Seite, die schnell sichtbar und zügig bedienbar ist. Das zahlt auf Wiederkehr, Engagement und Conversion ein. Gleichzeitig ist Google ein zentraler Kanal – und Web-Performance ist für die Suchmaschinenoptimierung wichtig. Ohne in Details der Ranking-Faktoren zu gehen, machte er deutlich: „Schnelle Websites sind wichtig“ – auch weil Google die Bedeutung von Performance-Metriken explizit betont.

Von TTFB bis Core Web Vitals: Metriken, die auf Nutzerwahrnehmung zielen

Ein Kernpunkt des Vortrags war die Einordnung der Metriken, mit denen wir „schnell“ messen. Klassische Kennzahlen entlang der Request-Response-Kette sind weiterhin relevant:

• Time To First Byte (TTFB) – Indikator, ob Server/Backend performant antworten
• DOMContentLoaded und onload – Marker, wann das Rendering formal abgeschlossen ist

Aber die Perspektive hat sich erweitert. Google hat in den letzten Jahren nutzerzentrierte Performance-Metriken in den Vordergrund gestellt. Sie zielen darauf ab, wie der Ladevorgang vom Menschen wahrgenommen wird:

• First Contentful Paint – ab wann sieht der Nutzer erstmals relevante Inhalte?
• Interaktivität – ab wann ist die Seite bedienbar?

Dies kulminiert in den Kernkennzahlen („Core Web Vitals“), die – so der Hinweis im Talk – für Google an Bedeutung gewinnen und „ab Juni“ auch das Ranking beeinflussen sollen. Im Kern adressieren diese drei Aspekte:

• Ladeverhalten
• Visuelle Stabilität
• Interaktivität

Für Teams heißt das: Nicht nur „wann fertig?“ messen, sondern „wann fühlt es sich schnell an?“

Die richtigen Werkzeuge: Messen, analysieren, verbessern

Zur Bewertung und Fehlersuche nannte Ratzenböck drei Tools, die sich ergänzen:

• PageSpeed Insights – seit Jahren etabliert für eine schnelle Standortbestimmung
• Google Lighthouse – tiefergehende Analysen inklusive SEO, Best Practices und PWA-Aspekten
• webpagedesk.org – mit Wasserfall-Diagrammen für granularen Einblick in jede Anfrage (DNS, TCP-Handshake, TLS-Verhandlung u. a.)

Die Empfehlung war eindeutig: Diese Werkzeuge geben „sehr detaillierte Einblicke“ und „viele Hinweise, wo man steht und was man tun kann“. Jede Optimierung sollte mit Messung beginnen – und mit Messung enden.

Ressourcenhinweise: Kleine Attribute, große Wirkung

Ein Schwerpunkt des Talks waren sogenannte Ressourcenhinweise („Resource Hints“). Die Botschaft:

Statt Ressourcen erst zum Zeitpunkt ihrer Nutzung abzuarbeiten, kann der Browser mit gezielten Hinweisen Vorarbeiten leisten – ohne das Rendering unnötig zu blockieren. Die zentralen Varianten:

DNS Prefetch

• Zweck: Frühe DNS-Auflösung einer Domain, bevor die eigentliche Ressource angefordert wird
• Wirkung: Wenn der Browser später eine Datei von dieser Domain lädt, ist die DNS-Auflösung bereits erledigt; die Anfrage startet schneller
• Einsatz: Vor allem für Drittanbieter-Ressourcen oder dynamisch generierte Ressourcen-URLs
• Charakter: Leichtgewichtig, läuft im Hintergrund

Preconnect

• Zweck: Einen Schritt weiter als DNS Prefetch: zusätzlich TCP-Handshake und TLS-Aushandlung vorziehen
• Wirkung: Spart Roundtrips, bevor eigentliche Requests starten
• Einsatz: Ebenfalls ideal für Third-Party-Hosts und dynamische Ressourcen

Prefetch

• Zweck: Ressourcen für wahrscheinliche Navigationspfade vorab im Cache bereitstellen
• Idee: Kennt man typische Nutzerpfade (z. B. von Seite A sehr häufig nach Seite B), lassen sich benötigte Dateien vorab abrufen
• Ergebnis: „Nahezu instant“ beim Navigieren, weil alles schon im Browsercache liegt
• Hinweis: Prefetch zielt auf die nächste Navigation – nicht auf die aktuelle Seite

Prerender

• Zweck: Noch aggressiver als Prefetch – die gesamte Zielseite wird vorgeladen und ausgeführt
• Nutzen: Navigation wirkt wie ein unmittelbares Umschalten
• Achtung: „Man muss vorsichtig sein“, betonte Ratzenböck. Prerender nutzt viele Ressourcen (CPU, Speicher, Bandbreite). Lohnt sich nur, wenn der Zielpfad sehr wahrscheinlich ist. Sonst droht negativer Nettoeffekt

Preload

• Einordnung: Formal kein Resource Hint, aber eng verwandt im Effekt
• Zweck: Ressourcen für die aktuelle Seite frühzeitig laden, z. B. Fonts, die später über CSS benötigt werden
• Nutzen: Kritische Assets stehen „rechtzeitig“ bereit, ohne auf die CSS-Verarbeitung warten zu müssen

Die Essenz: Mit wenigen Attributen lassen sich Timing-Flaschenhälse entschärfen. Dennoch gilt: Prefetch/Prerender sparsam und gezielt einsetzen, um Bandbreite und CPU nicht zu verschwenden.

Minifizierung und Bundling: Der de-facto-Standard, der oft mehr bringt als gedacht

Ein weiterer Block des Talks widmete sich der Größe von Auslieferungsartefakten. „JavaScript und CSS in Production minifizieren“ bezeichnete Ratzenböck als de-facto-Standard – mit gutem Grund: Bundle-Größe ist kritisch. Jeder gesparte Kilobyte beschleunigt Download und Parsing.

Moderne Bundler machen die Aktivierung einfach:

• Webpack
• Rollup
• Laravel Mix (ein Wrapper um Webpack)

Die Quintessenz: In vielen Setups reichen ein bis zwei Konfigurationszeilen, um Production-Builds automatisch zu minifizieren und zu bündeln.

Render-Blocking entschärfen: Defer, asynchrones Laden und kritisches CSS

Häufiger Befund in PageSpeed Insights: „Render-blocking resources“. Gemeint sind CSS und JavaScript, die das Rendering anhalten, bis sie geladen und ggf. ausgeführt sind. Ratzenböck unterschied klar zwischen „notwendig sofort“ und „kann warten“.

• JavaScript: Wo keine sofortige Ausführung nötig ist, sollte es „deferred“ werden. Das Attribut defer signalisiert dem Browser: Laden ja, Ausführen erst nach fertig aufgebautem DOM
• Effekt: Das Rendering der initial sichtbaren Inhalte („above the fold“) wird nicht unnötig angehalten

Für CSS liegt der Fokus auf dem „Critical CSS“ – also genau den Styles, die zur unmittelbaren Darstellung des sichtbaren Bereichs nötig sind.

• Ansatz: Kritische CSS-Regeln zuerst laden; alles Weitere anschließend asynchron
• Optional: Inlining des Critical CSS ist möglich (jobs.at macht das aktuell nicht), kann aber eine Option sein
• Vorsicht: „Flash of Unstyled Content“ (FOUC) vermeiden – der sichtbare Bereich muss von Beginn an korrekt gestaltet sein, sonst flackert die Darstellung

Die Botschaft: Initiale Darstellung priorisieren, unnötiges Blockieren vermeiden, Rest nachladen.

CSS abspecken mit PurgeCSS: Große Frameworks, kleine Nutzung

Frameworks wie Tailwind oder Bootstrap liefern viel – in Projekten wird meist nur ein Bruchteil davon wirklich genutzt. Im Lighthouse-Report sah das Team von jobs.at „recht schlechte Coverage“ auf einigen Seiten. Die Konsequenz: PurgeCSS.

• Funktionsweise: Im Build-Prozess vergleicht PurgeCSS die tatsächlich im Template verwendeten Klassen mit den CSS-Dateien und entfernt nicht benötigte Regeln
• Ergebnis: Spürbar kleinere CSS-Dateien
• Setup: „Sehr einfach“ z. B. mit Webpack, aber generell mit gängigen Bundlern möglich

Zwei konkrete Stolpersteine aus der Praxis hob Ratzenböck hervor:

1) Dynamisch nachgeladenes HTML (AJAX)

• Problem: PurgeCSS „weiß“ zur Build-Zeit nicht, welche Klassen später per AJAX ins DOM kommen. Diese Klassen könnten aus dem endgültigen CSS herausfallen
• Folge: Teile wirken ungestylt
• Implikation: Beim Einsatz von AJAX-Fragmenten sorgfältig prüfen und die Konfiguration so wählen, dass benötigte Klassen erhalten bleiben

2) Single-Page Applications (z. B. Vue.js) mit bedingtem Rendering

• Problem: Klassen, die erst zur Laufzeit über konditionale Pfade im DOM auftauchen, könnten im Build als „unbenutzt“ erscheinen
• Folge: Unerwartet fehlende Styles zur Laufzeit
• Implikation: „Aufpassen, dass nichts gelöscht wird, was man zur Laufzeit noch braucht“ – also bewusst mit der Tool-Konfiguration umgehen und die betreffenden Pfade berücksichtigen

Die Lehre: PurgeCSS ist eine starke Stellschraube – aber nur mit Bewusstsein für dynamische Inhalte.

Code-Splitting: Nur laden, was diese Seite wirklich braucht

Ein besonders praxisnaher Abschnitt war Ratzenböcks eigener Lernweg beim JavaScript-Bundling:

Konkrete Optionen, die er nannte:

• Serverseitige Steuerung: Bei jobs.at existiert ein eigener Asset Manager, der pro HTTP-Controller bzw. Route genau die passende JavaScript-Datei einbindet („eine JS-Datei pro Route“)
• Webpack: Nutzung der Möglichkeiten für Splitten, z. B. über das Split-Chunks-Plugin
• Vue.js: Dynamische Modulimporte über die ES6-Syntax; Komponenten werden erst geladen, wenn der Nutzer wirklich auf die entsprechende Seite navigiert (Beispiel im Talk: eine „Customer Login“-Komponente)

Ein weiterer Hinweis: „Shared bundles“ im Blick behalten, damit gemeinsame Abhängigkeiten nicht doppelt eingebunden werden. Duplicate Dependencies vergrößern das Transfer-Volumen unnötig.

Die Leitlinie: Code-Splitting reduziert Time-to-Interactive, indem die anfängliche JavaScript-Last sinkt – gerade bei größeren Single-Page- oder Multi-Page-Setups.

Praxisleitfaden: So lässt sich der Ansatz von jobs.at übertragen

Auf Basis der im Talk beschriebenen Schritte ergibt sich ein praktikabler Fahrplan, der sich auf viele Webanwendungen anwenden lässt – unabhängig vom Stack:

1) Messen und Ziele ableiten

• Mit PageSpeed Insights und Lighthouse den Status prüfen
• Mit webpagedesk.org Wasserfälle lesen: DNS, TCP, TLS, Blocker identifizieren
• Nutzerzentrierte Kennzahlen priorisieren: „wann sieht man etwas?“, „wann ist es bedienbar?“

2) Netzwerkvorarbeit mit Resource Hints

• dns-prefetch für Third-Party-Hosts, die sicher benötigt werden
• preconnect dort, wo TLS/Handshake-Latenzen sonst den Start verzögern
• prefetch nur für sehr wahrscheinliche Navigationsziele
• prerender nur, wenn die Zielseite nahezu sicher ist – sonst Bandbreitenverschwendung
• preload für kritische Assets der aktuellen Seite (insbesondere Fonts)

3) Bundles schlank halten

• Minifizierung im Production-Build einschalten (Webpack/Rollup/Laravel Mix)
• Aufteilung der Bundles statt „one big file“

4) Render-Blocking minimieren

• JavaScript, das nicht sofort nötig ist, mit defer laden
• Kritisches CSS zuerst – optional inline, danach asynchronen CSS-Load organisieren
• Auf FOUC achten; initial sichtbarer Bereich muss gestylt sein

5) CSS entrümpeln

• PurgeCSS in den Build integrieren
• Dynamische Inhalte (AJAX, SPA-Conditionals) bei der Konfiguration berücksichtigen

6) Code-Splitting konsequent nutzen

• Pro Route/page spezifische Chunks ausliefern (serverseitig oder via Build-Konfiguration)
• In SPA-Routern Komponenten lazy laden
• Shared Bundles deduplizieren

7) Nachmessen und iterieren

• Änderungen erneut mit Lighthouse und Wasserfall-Analysen verifizieren
• Trade-offs beobachten (z. B. Prefetch/Prerender vs. Bandbreite/CPU)

Beobachtungen aus dem Talk: Kleine Tweaks, große Hebel

Der rote Faden bei all diesen Maßnahmen: Viele davon sind „kleine Tweaks“, die in Summe spürbar wirken. Ratzenböck sprach von „Quick Wins“, etwa bei Resource Hints („es ist nur ein rel-Attribut – und fertig“). Genau diese Art von Maßnahmen sind für Teams attraktiv, weil sie mit überschaubarem Aufwand starten können und doch klare Effekte auf First Paint und Interaktivität bringen.

Ebenso wichtig ist die klare Trennung zwischen „was muss sofort passieren?“ und „was kann warten?“ – bei JavaScript, bei CSS, bei Daten. Wer diese Linie sauber zieht, erspart Nutzerinnen und Nutzern unnötige Blockaden in der kritischen Anfangsphase des Ladevorgangs.

SEO-Aspekt: Performance ist kein Selbstzweck

Der Talk stellte deutlich heraus, dass Performance nicht nur Selbstzufriedenheit für Entwicklerteams bedeutet, sondern konkrete Wirkung auf SEO entfaltet. Google betont die Bedeutung schneller Seiten, und die Fokussierung auf Core Web Vitals unterstreicht den Kurs. Der Hinweis, dass dies „ab Juni“ Einfluss aufs Ranking haben soll, verankert die Dringlichkeit im Tagesgeschäft: Performance ist Teil der Produkt- und Kanalstrategie.

Stack-Kontext: Laravel, Vue.js und SPA-Produkte

Für die Einordnung hilfreich: jobs.at arbeitet im Backend mit PHP/Laravel und im Frontend stark mit Vue.js, insbesondere bei SPA-Produkten. Viele der beschriebenen Maßnahmen sind gerade dort relevant, wo viel JavaScript anfällt und UI dynamisch aufgebaut wird:

• Resource Hints mildern Netzwerk-Overhead (DNS, TLS) – wichtig, wenn mehrere Hosts im Spiel sind
• Defer/Async und Code-Splitting begrenzen die anfängliche JavaScript-Last – essenziell für frühe Interaktivität
• PurgeCSS reduziert den CSS-Footprint – gerade bei Utility-First-Frameworks

Diese Punkte sind nicht stack-spezifisch, lassen sich aber mit den genannten Werkzeugen (Webpack, Rollup, Laravel Mix) gut in bestehende Pipelines einbetten.

Risiken bewusst managen: Wenn Optimierungen kippen können

Die Praxisnotizen im Talk waren realistisch: Optimieren heißt auch abwägen.

• Prefetch/Prerender: Nur einsetzen, wenn die Navigationswahrscheinlichkeit sehr hoch ist; sonst versehentliche Verschwendung von Bandbreite/CPU
• PurgeCSS: Dynamische Klassen nicht vergessen; fehlende Styles im Live-Betrieb sind ein hartes Gegenargument gegen „blindes“ Purgen
• Shared Bundles: Duplikate sind subtil – aber teuer. Build-Ausgabe und Netzwerk-Panel prüfen

Wer diese Risiken im Blick behält, profitiert netto – und spart sich Rückbauten.

Fazit: Ein fokussierter Werkzeugkasten, kein Over-Engineering

„How we optimize our Front End“ von Jürgen Ratzenböck (jobs.at Recruiting GmbH) zeigte einen klaren, umsetzbaren Weg zu schnellerer Auslieferung:

• Nutzerzentrierte Metriken ernst nehmen (schnell sichtbar, schnell interaktiv, visuell stabil)
• Messwerkzeuge kombiniert einsetzen (PageSpeed Insights, Lighthouse, webpagedesk.org)
• Netzwerk-Startkosten senken (DNS Prefetch, Preconnect)
• Navigationspfade beschleunigen (Prefetch, sehr gezielt Prerender)
• Kritische Pfade priorisieren (Defer für JS, Critical CSS zuerst)
• Bytes sparen (Minifizierung, PurgeCSS)
• Nur laden, was gebraucht wird (Code-Splitting, Lazy Loading, Shared-Bundle-Kontrolle)

Als Redaktion von DevJobs.at nehmen wir aus der Session mit: Die wirksamsten Schritte sind oft erstaunlich einfach zu starten – ein rel hier, ein defer dort, eine Purge-Konfiguration im Build – und sie addieren sich zu einer deutlich besseren Wahrnehmung von Geschwindigkeit. Gerade bei einer Plattform mit zehntausenden Jobs und hohem Traffic ist das nicht nur Technikpflege, sondern Produktstrategie. Performance hält Nutzer auf der Seite, verbessert die Rückkehrwahrscheinlichkeit und unterstützt die Sichtbarkeit in der Suche.

Oder in einem Satz: Ein schneller Erst-Eindruck, stabile Darstellung und frühe Interaktivität sind die Währung, in der moderne Websites bezahlt werden – und der Werkzeugkasten aus diesem Talk liefert genau dafür die passenden Hebel.

• 

  

  SPA without API

  Jürgen Ratzenböck von jobs.at spricht in seinem devjobs.at TechTalk "SPA without API" darüber, welche Vorteile und Challenges dieser Ansatz mit sich bringt und gibt technische Einblicke in das Thema.

  Jetzt ansehen

• 

  

  Jürgen Ratzenböck, Head of Technology von jobs.at

  Der Head of Technology von jobs.at Jürgen Ratzenböck erzählt im Interview über die flexible Teamorgansiation, wie ein Jobportal selbst an Bewerbungen kommt und welche Technologien zum Einsatz kommen.

  Jetzt ansehen