Browser-Rendering-Optimierung einfach erklärt

Wie fühlst du dich bei langen Ladezeiten von Websites? Vielleicht kennst du das: Die Seite lädt endlich, aber du kannst trotzdem nicht klicken oder scrollen, weil im Hintergrund noch etwas arbeitet. 

Und sobald die Seite schließlich reagiert, bremsen wilde Animationen alles aus und wirken billig und träge … Schon mal erlebt? 

Ich schon – und das erst kürzlich. Erstaunlicherweise sehe ich das immer noch, obwohl es so viele Optimierungstools und -praktiken gibt. 

Die Optimierung des Browser-Renderings ist ein weites Feld und umfasst viele Bereiche: Tools, Techniken und unzählige Chancen für Verbesserungen. 

Dieser Artikel konzentriert sich vor allem auf die effiziente Auslieferung der Seite für Endnutzer: auf Ladezeiten, deren Messung und darauf, wie man sie als Frontend-Entwickler verbessert. 

Aspekte der Seitenoptimierung

Themen wie schnellere Rendering-Performance nach dem Laden (schnellere Interaktionen und flüssigere Animationen) behandeln wir in einem separaten Blogartikel. 

Werfen wir zunächst einen Blick auf folgende Aspekte der Seitenoptimierung: 

Warum du das Page Rendering optimieren solltest

Application Lifecycle – das RAIL-Modell 

Wie man eine Seite auditiert – verfügbare Kennzahlen und Tools

Optimierungstechniken – Lösungen und Tricks zur Beschleunigung in vier Bereichen: Environment, Assets, Build und Delivery

*(Da sich Rendering-Optimierung und Auditing in den letzten Jahren rasant entwickelt haben, kann hier nicht jedes Thema im Detail abgedeckt werden. Manche Bereiche werden nur angerissen; wo möglich, verweise ich auf externe Quellen.) 

Warum Browser-Rendering optimieren? 

Es gibt bereits viele Studien und Beiträge dazu, wie wichtig Ladezeiten und verschiedene User-Experience-Metriken für Unternehmen sind.

Ein Kollege von mir hat kürzlich einen hervorragenden Artikel geschrieben, der viele Daten dazu zusammenführt, wie die User Experience einer Website zentrale, funktionale Bereiche eines internetpräsenten Unternehmens beeinflusst. 

Du kannst den Artikel hier lesen. 

Ein paar schnelle Zahlen verdeutlichen, wie wichtig Optimierung geworden ist: 

Schnellere Ladezeiten: 25% höhere Ad-Viewability, 70% längere Sessions und 35% niedrigere Bounce-Rate verzeichnen Seiten, die innerhalb von 5 Sekunden laden. 

Fünf Sekunden sind aber nicht ideal. Eine Studie aus 2016 zeigte, dass jeder zweite Mobile-Nutzer erwartet, dass eine Seite in weniger als 2 Sekunden lädt – und bis zu 53% der Besucher springen ab, wenn es länger als 3 Sekunden dauert. 

2017 veröffentlichte Google einen Report darüber, wie steigende Ladezeiten die Bounce-Rate erhöhen. In derselben Studie zeigte sich: Die Geschwindigkeit des initialen Seitenaufbaus ist für Nutzer der wichtigste Faktor in der User Experience. 

Sie ist sogar dreimal wichtiger als das Erscheinungsbild der Seite – und wichtiger als die Leichtigkeit, mit der Informationen zu finden sind! Ladezeit lässt sich zudem direkt mit den Umsätzen einer Seite verknüpfen: 80% der Internetnutzer sind bereit, für eine gute User Experience mehr zu bezahlen.

Aber genug Theorie. Schauen wir in die Technik.

RAIL und der Application Lifecycle

Wenn wir über allgemeine Seitenperformance sprechen, ist das RAIL-Modell hilfreich. RAIL nimmt vier Phasen im Lebenszyklus einer Anwendung an (nicht zu verwechseln mit dem Component Lifecycle großer Frameworks): Response, Animation, Idle und Load. 

Diese Reihenfolge entspricht allerdings nicht der tatsächlichen Chronologie beim Öffnen einer neuen Seite (dann wäre es LIAR: Load, Idle, Animation, Response).

 Ich bleibe bei dieser Reihenfolge und gehe die Phasen nacheinander durch. 

Die Loading-Phase ist das initiale Laden der Seite. Je kürzer, desto besser. Unterschiedliche Quellen empfehlen maximal 1 bis 5 Sekunden, allerdings stuft Google alles über 2,5 Sekunden als „verbesserungsbedürftig“ ein. 

Das ist eine der wichtigsten Kennzahlen für die User Experience. 

Die Idle-Phase ist die Zeit nach dem anfänglichen Laden, in der Nutzer überlegen, was sie als Nächstes tun. Die Seite wartet auf Interaktion; hier können wir Aufgaben nachholen, die wir aus der Ladephase herausgenommen haben (Bilder, Videos, Kommentarbereiche). 

Diese Tasks sollten in 50-ms-Chunks ausgeführt werden, damit bei einer Interaktion immer die Reaktion auf den User-Eingriff Vorrang vor Hintergrundarbeit hat. 

Für flüssige Animationen muss ein Frame in weniger als 16 ms erzeugt werden. In einem Artikel zum RAIL-Modell auf web.dev heißt es: 

In Hochdruck-Phasen wie Animationen ist es entscheidend, wo möglich nichts zu tun – und andernfalls das absolute Minimum. Nutze nach Möglichkeit das 100-ms-Response-Fenster, um teure Arbeiten vorab zu berechnen und so die Chance auf 60 FPS zu maximieren. 

Die Response-Phase ist die Reaktion auf Nutzeraktionen (z. B. Buttonklick, Routing) und sollte innerhalb von 100 ms erfolgen. Das ist die maximale Zeitspanne, die vom Nutzer als „sofortig“ wahrgenommen wird. 

In der obigen Grafik sind Load und Idle blau markiert, Animation und Response grün – denn während Load und Idle bei jedem neuen Seitenaufruf einmalig sind (in SPAs teils einmal für die gesamte App-Lebensdauer), wiederholen sich Animation und Response bei jeder Interaktion.

Google Web Vitals nutzen

Um Performance zu messen und zu erkennen, ob, wann und wo Optimierungen nötig sind, brauchen wir Tools. Ideal sind universelle Werkzeuge, damit sich Ergebnisse mit anderen Seiten im Web vergleichen lassen. 

Google hat hier mit Web Vitals vorgelegt. Web Vitals ist eine Initiative von Google mit einheitlichen Leitlinien für Qualitätssignale, die für eine großartige User Experience im Web entscheidend sind. 

Es gibt viele Tools zur Messung und Optimierung der Website-Performance, Google hat jedoch eines geschaffen, das jeder leicht verstehen und anwenden kann. 

Dafür gibt es die Teilmenge Core Web Vitals, die drei Aspekte der User Experience misst: Laden, Interaktivität und visuelle Stabilität. 

Gemessen wird mit drei Metriken:

Quelle: https://web.dev/vitals/ 

Largest Contentful Paint (LCP) – misst die initiale Ladezeit. Wie zu sehen, sollte das Laden innerhalb von 2,5 Sekunden erfolgen. Bereits 1,5 Sekunden mehr (insgesamt 4) und die User Experience gilt als schlecht.

First Input Delay (FID) – misst die Interaktivität. Eine Nutzeraktion sollte innerhalb von 100 ms eine Reaktion auslösen. Dauert es länger, wirkt die Seite träge. 

Cumulative Layout Shift (CLS) – zeigt die Stabilität des Layouts. Wenn Inhalte beim Laden springen, weil große Bilder oder später erscheinende Anzeigen Elemente verschieben, ist das eine schlechte User Experience.

Core Web Vitals mit Lighthouse messen

Es gibt verschiedene Wege, Core Web Vitals (und mehr) zu messen. Ein Tool, mit dem jeder Entwickler starten sollte, ist Lighthouse: ein automatisiertes Open-Source-Tool zur Performance-Analyse und zum Aufzeigen von Schwachstellen. 

Früher lag es im Audits-Tab der DevTools, inzwischen wurde es entfernt und als separate Chrome-Erweiterung bereitgestellt.

Ist die zu prüfende Website bereits live, brauchst du die Erweiterung nicht. Das Tool ist auch hier verfügbar. Lighthouse enthält die drei oben beschriebenen Indikatoren (LCP, FID, CLS) sowie weitere. 

Ein Beispiel:

Hier ein Lighthouse-Audit für eine zufällig gewählte Website mit den entsprechenden Ergebnissen:

Quelle: https://web.dev/measure/ 

Wie du siehst, gibt es vier Hauptbereiche: Performance, Accessibility, Best Practices und SEO. Da unser Fokus bislang auf Performance liegt, brechen wir diese Bewertung weiter auf.

Am Ende des Berichts stehen sechs Kennzahlen, die unterschiedliche Performance-Bereiche definieren. Drei davon kurz erklärt:

Speed Index (SI) –  Vergleich deines Speed Index mit dem echter Websites, basierend auf Daten aus dem HTTP Archive. Mehr zum Speed Index hier. 

Time to Interactive (TTI) – misst die Zeit, bis die Seite vollständig interaktiv ist. Berücksichtigt u. a. FCP, registrierte Event-Handler für sichtbare Elemente und Reaktionen auf Nutzeraktionen innerhalb von 50 ms. Details zur Berechnung hier. 

Total Blocking Time (TBT) – eng an die Idle-Phase des RAIL-Modells gekoppelt. Zeigt die gesamte blockierende Zeit durch Hintergrund-Tasks. Idealerweise dauern diese Chunks jeweils maximal 50 ms. 

Allerdings ist Lighthouse nicht perfekt. Im Laufe der Zeit wurden Inkonsistenzen beobachtet, dokumentiert u. a. auf Calibre und in diesem Blogartikel. 

PageSpeed

Ein weiteres großartiges Tool ist die Google Developers-Seite PageSpeed (PageSpeed Insights). Einfach die URL der zu prüfenden Seite einfügen und auf Analysieren klicken. Nach Sekunden erhältst du einen Bericht mit zwei Abschnitten und Geräteauswahl. 

Ich beginne mit dem zweiten Abschnitt, Diagnose von Leistungsproblemen. Kommt dir bekannt vor? Richtig: Es sieht aus wie ein Lighthouse-Report – ist es auch. PageSpeed nutzt Laborwerte aus Lighthouse. 

Cool. Oder auch nicht. Was, wenn deine Seite mittelmäßig abschneidet, du aber noch nicht weißt, wodurch einzelne Schwachpunkte entstehen? Lighthouse hilft weiter. 

Scrollst du im Bericht nach unten, siehst du eine Liste potenzieller Probleme mit Hinweisen auf Lösungen. Sie sind markiert und nach Schweregrad und Optimierungswirkung sortiert. 

Der erste Abschnitt ist am wichtigsten, denn er zeigt die reale Nutzererfahrung auf deiner Website. Auf Basis echter Chrome-Nutzersitzungen siehst du, wie sich die Seite im Alltag verhält – im Gegensatz zur eher laborartigen Umgebung von Lighthouse. 

Außerdem kannst du diese Experience getrennt für Desktop und Mobile betrachten.

Oben im PageSpeed-Bericht siehst du eine Kennzahl, die wir noch nicht besprochen haben: FCP, den First Contentful Paint. 

FCP zeigt an, wann Nutzer erstmals sichtbaren Content sehen. Diese Metrik ist wichtig, weil zumindest etwas Inhalt so früh wie möglich erscheinen sollte:

Quelle: https://pagespeed.web.dev/ 

Genug Theorie und Kennzahlen – kommen wir zu den Gründen für schlechte Werte und dazu, wie wir sie verbessern. 

Optimieren mit Environment, Assets, Build und Delivery 

Da wir endlich über Optimierung reden, gebe ich dir jetzt zehn Tipps, mit denen deine Seite blitzschnell wird – und du nie wieder optimieren musst. 

Nur Spaß. 

Eigentlich doch. Was meine ich damit?

Es gibt viele Guides zur Website-Optimierung. Vitaly Friedman hat einen großartigen Artikel über nahezu alle Rendering-Optimierungen geschrieben, die 2021 relevant waren – deshalb ist es auch eine sehr ausführliche, dreistündige Lektüre. 

Angesichts der vielen Variablen in unseren Entwicklungsumgebungen gibt es endlos viele Fehlerquellen – oder Kombinationen, die in einer App funktionieren, in einer anderen aber nicht. 

Wir gehen nicht alles im Detail durch, sonst würde das ein weiterer dreistündiger Artikel – und viele klügere Autoren haben das schon getan. 

Stattdessen bekommst du eine Liste von Punkten, die sich bei der Optimierung lohnen – in den vier Bereichen, die ein Frontend-Entwickler beeinflussen kann: Environment, Assets, Build und Delivery.

Environment 

Build-Tools – Grunt, Gulp, Webpack, Parcel, Rollup, Snowpack … Solange Wartbarkeit und Performance-Ziele passen, bist du mit jeder Konfiguration auf Kurs. Wenn dir die Wahl schwerfällt: Webpack ist lange etabliert und bietet viele Optimierungs-Plugins. 

Framework – Angular, Vue, React, Svelte? Bedenke: Moderne Frameworks priorisieren schwächere Geräte nicht. Und nicht jede Seite in einer SPA muss das gesamte Framework laden. Lesenswert ist diese Netflix- Fallstudie.

Rendering – Server-Side, Static, Streaming Server-Side, Client-Side … egal wofür du dich entscheidest: Wichtig ist, die Zeit zwischen LCP und TTI zu minimieren.

Baseline Performance Cost – Statt ein pures Framework zu nutzen, kannst du ganz ohne auskommen – oder eine meinungsstarke Alternative wie Next.js oder Nuxt.js wählen. Hier eine spannende Untersuchung zu den Performance-Kosten von Frameworks. 

Quelle: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/

Assets

AVIF, AV1, WebP, WebM –  Moderne Bild- und Videoformate können die Ladezeit massiv senken. Für WebM und AVIF ist die Unterstützung noch nicht überall perfekt, aber sie wird stetig besser.

Responsive Images – Nutze immer responsive Bilder mit `srcset`, `sizes` und dem <picture>-Element. Auch Background-Images können responsiv sein – siehe die CSS-Eigenschaft `image-set`. 

Web Fonts, Google Fonts –  Ein großes Thema für sich; mehr dazu in diesem Artikel.

Brotli –  Ein vielversprechendes, quelloffenes, verlustfreies Kompressionsformat. 

GIFs –  Lass sie sein – sie sind in Sachen Dateigröße ineffizient. Nutze stattdessen geloopte HTML-Videos:

Quelle: https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/#defining-the-environment 

Build

JS Modules, Module/Nomodule Pattern (Differential Serving) –  Mehr dazu in der Dokumentation der V8-Engine und im PerfPlanet-Blog.

Tree-Shaking, Code-Splitting, Scope-Hoisting –  Sind inzwischen Standardpraktiken in Bundlern wie Webpack. 

Web Worker – Zur Reduktion des TTI ist es sinnvoll, einen Teil der anfänglichen Berechnungen an einen Web Worker auszulagern. 

SPA-Optimierung – Die meisten Frontend-Devs arbeiten heute mit SPA-Frameworks. Es gibt zahlreiche Stellschrauben; für einen praxisnahen Einstieg empfehle ich diesen Artikel von CSS-Tricks. 

Unbenutztes CSS/JS identifizieren und entfernen – Nutze Chrome DevTools (Coverage-Tool) oder Puppeteer, das u. a. auch Pre-Rendering übernehmen kann.

Partial Hydration – Wer tiefer einsteigen möchte: gute Fallstudien gibt es hier für React und hier für Vue. 

Cache-Control – Caching ist nicht neu, aber unter der Oberfläche steckt viel. Es gibt zahlreiche Strategien und Fallstricke bei der Frage, wie der Browser Assets cachen soll. Ein schneller Einstieg hier. Fortgeschrittene lesen hier, warum Netzwerkzugriffe teils schneller als Cache-Treffer sein können.

Third-Party Libraries – Je weniger, desto besser. Laut thirdpartyweb.today entfallen 57% der gesamten JS-Ausführungszeit auf Drittanbieter. Falls nötig, hoste diese Libraries am besten selbst.

Quelle: thirdpartyweb.today 

Delivery

Lazy Loading – Neben defer oder async für Skripte ist natives Lazy Loading in allen gängigen Browsern verfügbar (für Bilder, iFrames folgen/unterstützt). 

Intersection Observer – Laut Definition: Die Intersection Observer API erlaubt es, Änderungen der Überschneidung eines Zielelements mit einem Vorfahren oder dem Viewport asynchron zu beobachten. Einfacher gesagt: Wir erhalten granulare Kontrolle über Elemente, die gleich in den Viewport kommen. Zusammen mit Lazy Loading äußerst mächtig. Ein schönes Praxisbeispiel gibt es hier.

Content-Visibility – Sobald es flächendeckend unterstützt wird, können wir ganze Seitensektionen rein per CSS lazy laden. Bei langen Homepages (mit vielen Sektionen etc.) ist es sinnvoll, Abschnitte erst kurz vor dem Sichtbarwerden zu rendern. Hier ein gutes Beispiel, wie sich damit der LCP verbessern lässt. 

Critical CSS – Heutzutage gängige Praxis: Above-the-Fold-CSS abtrennen/kennzeichnen und im <head> einbetten.

Service Worker – Sie können nach dem ersten Besuch die Ladezeit deutlich reduzieren, indem sie gecachte Ressourcen nutzen.

Rendering-Performance – Damit sich eine Website reaktionsschnell anfühlt, sollten wir den Frame-Rendering-Prozess verstehen und entsprechend optimieren. Das ist ein eigenes, großes Thema; dazu erscheint ein separater Artikel über die Animation- und Response-Phasen des RAIL-Modells.

Connection-Aware Components – Nutze die wachsenden Browser-APIs und rendere Komponenten abhängig von der verfügbaren Bandbreite (siehe navigator.connection). Besonders hilfreich bei globalen Apps mit Nutzern zwischen sehr langsamen und sehr schnellen Verbindungen:

Quelle: https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6 

Proaktive und reaktive Browser-Optimierung

Die obige Liste kann zunächst überwältigend wirken. Also fragst du dich vielleicht: Muss ich wirklich jeden Punkt abklopfen, wenn meine Website maximal performant sein soll? 

Gut ist, die Punkte im Hinterkopf zu haben. Optimierung sollte aber ein Mix aus proaktivem und reaktivem Vorgehen sein. Manche Dinge sind offensichtlich und sollten bereits beim Coden berücksichtigt werden. 

Dazu zählen Dependency-Management, SSR, Asset-Management, Fonts, Tree-Shaking, Third-Party-Libraries, Caching und Lazy Loading. Wer das in den Alltag integriert, hat sehr gute Chancen, in Performance-Analysen hoch zu punkten. 

Wenn die Ergebnisse trotzdem nicht zufriedenstellen, zeigen die genannten Tools Schwachstellen auf, die man anschließend gezielt optimiert (Webpack, CDN, SSR, Differential Serving, Partial Hydration, verzögerte Importe, Deferred Rendering, Critical CSS, Service Worker usw.). 

Wie ein Optimierungspfad für die Landingpage eines großen Fashion-Unternehmens aussehen kann, zeigt dieses Video von Addy Osmani, einem der führenden Google-Experten für Optimierung.

Du kannst außerdem jenseits von Code und Server-Tuning in der Browserkonfiguration ansetzen, um Google Chrome zu optimieren. Für viele Nutzer reicht schon ein Blick in die Chrome-Einstellungen (und chrome://flags), um Optionen wie Hardwarebeschleunigung und den Flag „Override software rendering list“ zu entdecken. Auf manchen Maschinen entlastet die Hardwarebeschleunigung die CPU und hilft Chrome, komplexe Seiten flüssiger zu rendern; auf anderen führt sie zu Rucklern und Grafikfehlern. In solchen Fällen kann das Deaktivieren der Hardwarebeschleunigung in den Chrome-Einstellungen den Browser bei animations- oder grafiklastigen Seiten fühlbar stabiler und berechenbarer machen.

Für fortgeschrittene Diagnosen liefert Google Chrome zudem einen integrierten Task-Manager (Shift+Esc), der zeigt, welche Tabs, Erweiterungen und Prozesse beim Seitenladen am meisten CPU und RAM verbrauchen. So lässt sich eine fehlverhaltende Erweiterung aus dem Chrome Web Store schneller enttarnen, die die Performance bremst – selbst wenn Code und Server-Setup bereits optimiert sind. Eine aufgeräumte Erweiterungslandschaft in Kombination mit sinnvoller Browserkonfiguration gibt dir eine zusätzliche, wirkungsvolle Stellschraube für echte Performance – als Ergänzung zu allen Rendering- und Delivery-Optimierungen aus diesem Artikel. 

Zusammenfassung

Ich hoffe, es ist deutlich geworden, wie entscheidend eine optimale User Experience ist. Nach dem Blick auf die ersten beiden Phasen des RAIL-Modells sollte auch klar sein, wie man den Seitenaufbau richtig angeht und Nutzern so schnell wie möglich die gesuchten Inhalte liefert.

Wir haben Lighthouse und PageSpeed behandelt – Tools, die helfen, Faktoren zu identifizieren, die die Reaktionsfähigkeit deiner Seite beeinträchtigen. Anschließend folgte ein komprimierter Spickzettel mit verschiedenen Optimierungstechniken, um dieses Ziel zu erreichen. 

Denke daran: Die hier beschriebenen Themen sind nur die Spitze des Eisbergs. Ich hoffe aber, dass sie dich inspirieren, tiefer in die vorgestellten Techniken einzutauchen – und dass du dadurch deine Skills in der Website-Optimierung spürbar ausbaust.

Happy Coding!