Checkliste zur Webgeschwindigkeit 2021

Lassen Sie uns 2021... schnell machen! In der deutschen Übersetzung präsentieren wir eine Checkliste zur Optimierung der Frontend-Geschwindigkeit von Websites. Sie enthält nahezu alles, was Sie wissen müssen, um heute ein schnelles Benutzererlebnis im Web zu gewährleisten – von Metriken über Tools bis hin zu Entwicklertechniken.

Diese Checkliste ist eine Übersetzung des Front-End Performance Checklist 2021_ von Smashing Magazine. Vielen Dank an Smashing Magazine._

Inhaltsverzeichnis:

1. Vorbereitung: Planung und Metriken
2. Realistische Ziele setzen
3. Definition der Entwicklungsumgebung
4. Dateioptimierung
5. Build-Optimierung
6. Ladeoptimierung
7. Netzwerk und HTTP/2
8. Testen und Überwachen
9. Schnelle Erfolge

• Schaffen Sie eine „Performance-Kultur“, die die Webgeschwindigkeit unterstützt.

  Webgeschwindigkeit kann langfristig nicht ohne Investition aufrechterhalten werden. Untersuchen Sie häufige Beschwerden, die beim Kundensupport eingehen, und finden Sie heraus, wie eine Erhöhung der Geschwindigkeit helfen kann, einige dieser Probleme zu lindern. Erstellen Sie eine Fallstudie mit realen Daten und Geschäftsmesswerten, die auf Ihr Unternehmen zugeschnitten sind. Planen Sie bereits beim Entwurf Ihrer Website die Ladeabfolge und mögliche Kompromisse.

• Seien Sie 20 % schneller als Ihr schnellster Konkurrent.

  Sammeln Sie Daten über die Geräte, die Ihre Website-Besucher verwenden. Bevorzugen Sie reale Geräte gegenüber Simulationen. Wählen Sie ein Moto G4/G5 Plus; ein Mittelklasse-Samsung-Gerät (Galaxy A50, S8); ein gutes Mittelklassegerät wie das Nexus 5X, Xiaomi Mi A3 oder Xiaomi Redmi Note 7 und ein langsames Gerät wie das Alcatel 1X oder Cubot X19. Alternativ können Sie das mobile Betriebssystem auf einem Computer emulieren, indem Sie die Netzwerkgeschwindigkeit (z.B. 300 ms RTT, 1,6 Mb/s Download, 0,8 Mb/s Upload) und die CPU-Leistung (5-fache Verlangsamung) einschränken. Wechseln Sie dann zu normalem 3G, langsamen 4G (z.B. 170 ms RTT, 9 Mb/s Download, 9 Mb/s Upload) und Wi-Fi. Sammeln Sie Daten, erstellen Sie eine Tabelle, ziehen Sie 20 % von den Ergebnissen ab und setzen Sie Ihre Ziele („Performance Budgets“, Geschwindigkeitsbegrenzungen).

• Wählen Sie die richtigen Metriken.

  Nicht jede Metrik hat aus Optimierungssicht denselben Wert. Untersuchen Sie, welche Metriken am wichtigsten sind: Sie beziehen sich in der Regel darauf, wie schnell die wichtigsten Pixel gerendert werden und wie schnell die Eingabeantwort erfolgt. Konzentrieren Sie sich also auf das Laden der Seite nach den Prioritäten Ihrer Besucher. In der Regel geht es um die Zeit bis zur Interaktivität (Time To Interactive – TTI), erste Eingabeverzögerung (First Input Delay – FID), Zeit, bis das „Hero“-Element gerendert wird, größtes Contentful Paint (LCP), totale Blockierungszeit (Total Blocking Time – TBT) und kumulative Layoutverschiebung (Cumulative Layout Shift – CLS). Nicht auf: Erste sinnvolle Malzeit (First Meaningful Paint).

• Richten Sie Testprofile ein: „sauber“ und „kundenspezifisch“.

  Deaktivieren Sie Antivirenprogramme und CPU-intensive Hintergrundaufgaben, stoppen Sie Hintergrunddatentransfers und testen Sie mit einem „sauberen“ Benutzerprofil ohne Browsererweiterungen, um Ergebnisverzerrungen zu vermeiden. Untersuchen Sie, welche Erweiterungen Ihre Kunden verwenden, und testen Sie auch ein spezielles „Kunden“-Profil.

• Teilen Sie die Checkliste zur Webgeschwindigkeit mit Ihren Kollegen.

  Stellen Sie sicher, dass jedes Teammitglied diese Checkliste zur Webgeschwindigkeit kennt. Jede Entscheidung hat Auswirkungen auf die Leistung, und Ihr Projekt wird erheblich davon profitieren, wenn die Verantwortung im gesamten Team verteilt wird. Gleichzeitig kartieren Sie Designtentscheidungen und stellen sie gegen das Performance-Budget.

• Reaktionszeit von 100 Millisekunden, 60 Bilder pro Sekunde.

  Jeder Animationsrahmen sollte innerhalb von 16 Millisekunden ausgeführt werden – idealerweise 10 Millisekunden, um die gewünschten 60 Bilder pro Sekunde zu erreichen (1 Sekunde ÷ 60 = 16,6 Millisekunden). Seien Sie optimistisch und nutzen Sie Leerlaufzeiten; bei anspruchsvollen Aufgaben wie Animationen ist es besser, auf der Seite nichts anderes zu tun. Wo dies nicht möglich ist, tun Sie nur das absolut Notwendige. Die geschätzte Eingabelatenz sollte unter 50 ms liegen. Nutzen Sie Leerlaufzeiten mit der Methode Idle Until Urgent.

• LCP < 2,5 Sekunden; FID < 100 ms; CLS < 0,1; TTI < 5 Sekunden auf 3G.

  Wenn Sie als Standardgerät ein Android-Mobiltelefon für etwa 4.000 CZK in einem langsamen 3G-Netzwerk verwenden, das mit einer Übertragungsgeschwindigkeit von 400 ms RTT und 400 kB/s emuliert wird, konzentrieren Sie sich auf Time To Interactive (TTI) < 5 Sekunden und auf wiederholte Besuche unter 2–3 Sekunden. Streben Sie ein Largest Contentful Paint < 2,5 Sekunden an und minimieren Sie Total Blocking Time (TBT) und Cumulative Layout Shift (CLS). Versuchen Sie, diese Werte auf ein Minimum zu reduzieren.

• Dateigrößenlimit < 170 kB.

  Die ersten 14–16 kB HTML-Code sind am kritischsten – sie sind der einzige Teil, der im ersten Paket über das Netzwerk geliefert wird („first roundtrip“). Um die oben gesetzten Ziele zu erreichen, arbeiten Sie mit Dateigrößen von maximal 170 kB gzip (0,7 – 0,8 MB dekomprimiert). Stellen Sie sicher, dass Ihre Geschwindigkeitslimits je nach Netzwerkbedingungen und Hardwarebeschränkungen variieren.

• Wählen und konfigurieren Sie Ihre Build-Tools sorgfältig.

  Machen Sie sich nicht zu viele Gedanken darüber, ob es sich um ein „cooles“ Tool handelt oder nicht. Wenn Sie schnell Ergebnisse erzielen und keine Probleme mit der Pflege Ihres Entwicklungsprozesses haben, dann ist alles in Ordnung. Ausnahmen können Webpack oder Parcel sein, die nützliche Optimierungstechniken wie Code-Splitting bereitstellen. Wenn Sie diese Techniken noch nicht verwenden, sehen Sie sich das bereits erwähnte Code-Splitting und Tree-Shaking an.

• Verwenden Sie standardmäßig progressive Verbesserung (progressive enhancement).

  Entwerfen und erstellen Sie zunächst eine grundlegende Benutzeroberfläche, damit die Website ihre Grundfunktion erfüllt. Verbessern Sie dann die Oberfläche mit fortschrittlichen Funktionen für verschiedene Browser, um eine robuste und stabile Oberfläche für verschiedene Benutzer mit unterschiedlichen Geräten zu schaffen. Wenn Ihre Website auf einem langsamen Gerät mit einem schlechten Bildschirm und einem schlechten Browser in einem suboptimalen Netzwerk schnell läuft, läuft sie auch auf einem schnellen Gerät mit einem guten Browser und einem angemessen schnellen Netzwerk schneller.

• Setzen Sie hohe Leistungsstandards.

  JavaScript bringt die größten Kosten für die Benutzererfahrung mit sich. Mit einem Limit von 170 kB, das bereits kritische Daten und Wege enthält – HTML / CSS / JavaScript, Router, Zustandsverwaltung, Tools, Schnittstellen und Anwendungen – untersuchen Sie gründlich die zeitlichen Kosten für die Netzwerkübertragung, das Parsen, die Kompilierung und die Laufzeitkosten des Frameworks.

• Bewerten Sie jedes Framework und jede Abhängigkeit.

  Nicht jedes Projekt benötigt ein Framework, nicht jede Single Page Application (SPA) muss ein Framework laden. Wählen Sie mit Bedacht; bewerten Sie Drittanbieter-JS anhand von Funktionen, Zugänglichkeit, Stabilität, Geschwindigkeit, Paketökosystemen, Lernkurven, Dokumentation, Tools, Aufzeichnungen, Team, Kompatibilität und Sicherheit. Next.js (React), Gatsby (React), Vuepress (Vue) und Preact CLI bieten anständige Standardwerte für schnelles Laden auf durchschnittlicher mobiler Hardware.

• Wählen Sie weise: React, Vue, Angular, Ember und Co..

  Stellen Sie sicher, dass das von Ihnen gewählte Framework Server-Side Rendering (SSR) oder Prerendering bietet. Bevor Sie sich entscheiden, messen Sie auf mobilen Geräten die Renderzeiten sowohl auf dem Server als auch beim Client. Es ist wichtig, die „Schrauben und Muttern“ des Frameworks zu kennen, auf das Sie sich verlassen werden. Schauen Sie sich das PRPL-Muster und die App Shell-Architektur an. Gute Optionen sind Preact, Inferno, Vue, Svelte, Alpine, Polymer.

• Optimieren Sie die Leistung Ihrer APIs.

  APIs können leicht zum Flaschenhals werden, wenn mehrere Dienste gleichzeitig darauf zugreifen. Erwägen Sie die Verwendung von GraphQL, mit dem Sie Abfragen über ein von Ihnen erstelltes Typsystem ausführen können. Im Gegensatz zu REST kann GraphQL alle Daten in einer einzigen Abfrage abrufen, ohne zu viele oder zu wenige Daten herunterzuladen, was in REST-Architekturen häufig vorkommt.

• Werden Sie Google AMP oder Facebook Instant Articles ausprobieren?

  Auch ohne diese Technologien können Sie eine gute Leistung erzielen, aber AMP bietet eine sehr gute Leistungsbasis und ein globales CDN. Instant Articles helfen Ihnen, insbesondere auf Facebook sichtbar zu werden, und bieten ein bis zu 4-mal schnelleres Laden als herkömmliche mobile Websites.

• Wählen Sie Ihr CDN mit Bedacht.

  Berücksichtigen Sie, wie stark Sie von dynamischen Daten abhängen. Sie können mindestens einen Teil Ihrer Inhalte statisch erzeugen, auf ein CDN hochladen und so unnötige Datenbankabfragen vermeiden (JAMStack). Überprüfen Sie, ob das CDN Inhaltskompression und Bildkonvertierung (z.B. Optimierung und Größen- oder Formatänderung) durchführt und ob es Server-Worker unterstützt.

• Verwenden Sie Brotli zur Kompression.

  Brotli ist ein neues verlustfreies Datenformat, das in allen modernen Browsern unterstützt wird. Es ist effizienter als GZip und Deflate. Die Komprimierung ist sehr langsam, aber die Dekomprimierung schnell. Komprimieren Sie statische Assets mit Brotli und Gzip auf höchster Stufe vor, HTML komprimieren Sie dynamisch zur Laufzeit mit Brotli (Level 1-4). Überprüfen Sie auch die Brotli-Unterstützung bei Ihrem CDN. Stellen Sie sicher, dass der Server die „Content Negotiation“ für Brotli oder Gzip korrekt verarbeitet.

• Verwenden Sie responsive Bilder, AVIF und WebP.

  Wenn möglich, verwenden Sie responsive Bilder mit den Eigenschaften srcset, sizes, <picture> und image-set. Verwenden Sie AVIF und WebP Formate mit <picture> und JPEG/PNG als Fallback oder erkennen Sie die Unterstützung mit dem Accept-Header. Hinweis: Mit WebP reduzieren Sie die Datenmenge, aber mit JPEG können Sie die wahrgenommene Geschwindigkeit dank „progressivem Rendering“ verbessern.

• Sind die Bilder richtig optimiert?

  Verwenden Sie mozJPEG zur JPEG-Komprimierung, SVGO zur SVG-Komprimierung, Pingo für PNG oder Squoosh für alle davon (einschließlich AVIF). Um die Effektivität Ihres responsiven Markups zu überprüfen, können Sie das Tool imaging-heap verwenden. Verwenden Sie für kritische Bilder progressive JPEGs und verwischen Sie unnötige Teile (durch Anwendung von Gaußscher Unschärfe) und entfernen Sie den Kontrast (Sie können ihn mit CSS-Filtern wiederherstellen). Stellen Sie sicher, dass Sie die Attribute width und height für alle Ihre Bilder gesetzt haben. Fügen Sie die automatische Bildkomprimierung zu Ihren Pull-Requests hinzu und erkunden Sie das Lazy Loading weniger kritischer Bilder.

• Sind die Videos richtig optimiert?

  Verwenden Sie anstelle animierter GIFs entweder animierte WebP (und GIF als Fallback) oder binden Sie Schleifen mit Inline-HTML5-Videos ein. Stellen Sie sicher, dass Ihre MP4-Dateien mittels Multipass-Encodierung verarbeitet werden, mit dem Effekt „frei0r iirblur“ (falls verfügbar) verwischt werden, moov atom-Metadaten in den Dateikopf verschoben werden und Ihr Server Byte serving akzeptiert. Wo immer möglich, verwenden Sie Videos im AV1-Format, bieten aber auch Fallbacks für ältere Formate an. Passen Sie die Abmessungen der Videos an und bieten Sie Besuchern Inhalte, die sie auf ihren Geräten ohne Verzögerung abspielen können, mittels adaptivem Medien-Streaming an.

• Sind die Schriftarten optimiert?

  Stellen Sie das richtige Subsetting für die Schriftart ein. Bevorzugen Sie WOFF2 und verwenden Sie WOFF als Fallback. Zeigen Sie Inhalte sofort mit einer Fallback-Schriftart an, laden Sie die benutzerdefinierte Schriftart asynchron und schalten Sie die Schriftart erst dann um. Ideale Lösung: zweistufiges Rendering, zuerst mit einem kleinen Superset und den Rest später asynchron laden. Preloaden Sie 1-2 Schriftarten aus jeder Familie. Vermeiden Sie die Verwendung von local() in der Schriftartdeklaration, berücksichtigen Sie jedoch die Verwendung von systemeigenen Schriftarten. Vergessen Sie nicht, font-display:optional zu verwenden und verwenden Sie Font Load-Ereignisse zum Neuzeichnen. Verwenden Sie die Metriken Web Font Reflow Count und Time To Real Italics.

• Setzen Sie die Prioritäten richtig.

  Überprüfen Sie alle Ihre Ressourcen (JavaScript, Bilder, Schriftarten, Drittanbieter-Skripte, „teure“ Module auf der Seite) und teilen Sie sie in Gruppen ein. Definieren Sie das grundlegende Erlebnis (vollständig zugänglicher Basisinhalt für ältere Browser), das verbesserte Erlebnis (angereichert, vollwertig für moderne Browser) und Zusatzfunktionen (Ressourcen, die nicht unbedingt erforderlich sind und die lazy geladen werden können).

• Verwenden Sie native JavaScript-Module in der Produktion.

  Unterstützen Sie in älteren Browsern das grundlegende Erlebnis, vollständiges nur in modernen Browsern. Verwenden Sie zum Laden von JavaScript ES2017+ <script type="module">. Moderne Browser interpretieren das Skript als JavaScript-Modul und führen es wie erwartet aus. Ältere Browser ignorieren es.

• JavaScript auszuführen ist teuer, also zähmen Sie es.

  Bei SPA-Anwendungen benötigen Sie einige Zeit, um die Anwendung zu initialisieren, bevor Sie die Seite rendern können. Suchen Sie nach Modulen und Techniken, um die anfängliche Renderzeit zu beschleunigen, z.B. progressive hydration und Import bei Interaktion (auf älteren Mobilgeräten sind die Zeiten 2-5x höher).

• Verwenden Sie Tree-Shaking, Scope Hoisting und Code-Splitting zur Reduzierung der Ladezeit.

  Tree-Shaking ist eine Methode, die beim Build nur den tatsächlich verwendeten Code verwendet. Code-Splitting teilt den Code in „Blöcke“, die bei Bedarf geladen werden. Scope Hoisting erkennt, wo Verkettungen von Importen aufgelöst und in eine eingebettete Funktion umgewandelt werden können, während die Funktionalität erhalten bleibt (z.B. mit Webpack). Verwenden Sie granular chunking und verlagern Sie einen Teil des Renderings vom Client auf den Server. Definieren Sie die Aufteilung, indem Sie überwachen, welche CSS/JS-Blöcke verwendet werden und welche nicht. Erwägen Sie auch Code-Splitting auf Paketebene.

• Können Sie JavaScript in einen Web Worker oder WebAssembly verschieben?

  Wenn sich der Code entwickelt, beginnen sich Schwachstellen in der Leistung der Benutzeroberfläche zu zeigen. Es kommt vor, dass DOM-Operationen neben Ihrem JS im Haupt-Thread ausgeführt werden. Erwägen Sie, diese teuren Operationen in Hintergrundprozesse zu verschieben, die in einem anderen Thread mit Webworkern ausgeführt werden. Ein typischer Fall: das Vorladen von Daten in eine PWA. Erwägen Sie, rechenintensive Aufgaben in WebAssembly zu verschieben, das am besten für anspruchsvolle Webanwendungen wie Spiele geeignet ist.

• Senden Sie Code für ältere Browser nur an diese älteren Browser.

  Verwenden Sie babel-preset-env, um ES2017+ Funktionen zu transpilen, die von den modernen Browsern, die Sie unterstützen, nicht unterstützt werden. Dann richten Sie zwei Build-Versionen ein, eine für moderne und eine für ältere Browser.

  Für lodash verwenden Sie babel-plugin-lodash, das nur die Module lädt, die Sie im Quellcode verwenden. Ändern Sie allgemeine lodash-Anforderungen und wählen Sie nur die verwendeten aus, um Code-Duplikate zu vermeiden. Verwenden Sie <link rel="modulepreload">, um das frühzeitige (hochpriorisierte) Laden von Modulen zu initiieren.

• Identifizieren und überarbeiten Sie alten (Legacy-)Code mit „inkrementellem Entkopplung“.

  Überprüfen Sie die Abhängigkeiten im Projekt und beurteilen Sie, wie viel Zeit erforderlich wäre, um alten Code zu refaktorisieren oder neu zu schreiben. Legen Sie zuerst Metriken fest, die überwachen, ob das Verhältnis der Aufrufe von Legacy-Code gleich bleibt oder sinkt. Das Verhältnis darf nicht steigen. Setzen Sie im Team Bedingungen, die die Verwendung weiterer Bibliotheken nicht tolerieren, und stellen Sie sicher, dass CI immer die Entwickler bei einem Pull-Request benachrichtigt.

• Identifizieren und entfernen Sie ungenutzte CSS/JavaScript.

  CSS- und JavaScript-Abdeckung in Chrome ermöglicht es Ihnen zu sehen, welcher Code ausgeführt/verwendet wurde und welcher nicht. Sobald Sie ungenutzten Code sichergestellt haben, finden Sie diese Module und fügen Sie Lazy-Loading mit import() hinzu. Wiederholen Sie nach der Anpassung den Code-Coverage-Test und überprüfen Sie, dass beim ersten Laden weniger Code gesendet wird. Verwenden Sie Puppeteer, um die Code-Coverage-Ergebnisse automatisch zu sammeln.

• Reduzieren Sie die Größe von JavaScript-Abhängigkeiten.

  Es ist sehr wahrscheinlich, dass Sie in Ihren Projekten ganze JavaScript-Bibliotheken haben, die Sie tatsächlich nur zu einem Bruchteil nutzen. Erwägen Sie die Verwendung der automatischen webpack-libs-optimizations, die nicht verwendete Methoden und Polyfills während des Build-Prozesses entfernt. Fügen Sie die Paketüberprüfung zu Ihrem regelmäßigen Workflow hinzu. Bundlephobia hilft bei der Einschätzung der Performance-Auswirkungen durch das Hinzufügen einzelner NPM-Pakete zum Projekt. Size-limit erweitert die klassische Paketgrößenkontrolle um die Ausführungszeit in JavaScript. Skypack können Sie als Quelle für qualitativ hochwertige und leistungsorientierte Pakete verwenden, die von einzelnen Community-Mitgliedern gepflegt werden.

• Verwenden Sie prädiktives Prefetching für JavaScript-Teile?

  Nutzen Sie Ihre Erfahrung und Ihr Gefühl, um zu bestimmen, wann Sie Ihr JS vorladen. Guess.js umfasst Tools, die Daten aus Google Analytics verwenden, um festzustellen, welche Seite der Benutzer wahrscheinlich als nächstes besucht. Erwägen Sie Quicklink, Instant.page und DNStradamus. Hinweis: Vielleicht geben Sie dem Browser Anweisungen, unnötige Daten herunterzuladen und unnötige Seiten vorzuladen. Wir empfehlen dringend, vorsichtig zu sein, wenn es um die Anzahl der vorab geladenen Anfragen geht.

• Optimieren Sie für Ihre Ziel-JavaScript-Engines.

  Nutzen Sie script streaming für monolithische Skripte, damit sie direkt nach Beginn des Downloads in einem separaten Hintergrund-Thread geparst werden können. Verwenden Sie auch das Code-Caching der V8-Engine durch Trennung von Bibliotheken vom Code, der sie verwendet. Erwägen Sie auch JIT-Optimierungsstrategien für den Baseline-Interpreter des Firefox-Browsers.

• Finden Sie Wege, Client-Side- und Server-Side-Rendering zu kombinieren.

  In der Regel besteht das Ziel darin, ein optimales Gleichgewicht zwischen Client-Side- und Server-Side-Rendering zu finden. Erwägen Sie Prerendering, wenn sich Ihre Seiten nicht zu oft ändern, und wenn möglich, verzögern Sie das Booten von Frameworks. Streamen Sie HTML-Chunks mit Server-Side-Rendering und hydratisieren Sie erst bei Anzeige, Interaktion oder während des Leerlaufs, um das Beste aus beiden Welten zu erhalten. (Streaming Server-Side Rendering With Progressive Hydration).

• Erwägen Sie Mikrooptimierungen und progressives Booten.

  Verwenden Sie Server-Side-Rendering für schnelles „First Meaningful Paint“ (FMP), aber auch minimalen JS, um „Time To Interactive“ (TTI) nahe am „First Meaningful Paint“ zu halten. Führen Sie dann entweder auf Anfrage oder wenn die Zeit es erlaubt, nicht wesentliche Teile der Anwendung aus. Teilen Sie die Ausführung von Funktionen immer in asynchrone Aufgaben auf. Verwenden Sie nach Möglichkeit requestIdleCallback.

• Hosten Sie Drittanbieter-Ressourcen selbst.

  Die Verwendung einer öffentlichen CDN ist nicht automatisch schneller. Auch wenn zwei Websites auf genau dieselbe URL einer Drittanbieter-Ressource verweisen, wird der Code für jede Domain erneut heruntergeladen. Der Cache ist pro Domain isoliert. Eigene Ressourcen bleiben mit größerer Wahrscheinlichkeit im Cache als Drittanbieter-Ressourcen. Eigenes Hosting ist zuverlässiger, sicherer und leistungsfähiger.

• Begrenzen Sie die Auswirkungen von Drittanbieter-Skripten.

  Zu oft zieht ein Drittanbieter-Skript den „langen Schwanz“ und ruiniert die Geschwindigkeit. Erwägen Sie die Verwendung von Service Workern, um Ressourcen mit einem Zeitlimit herunterzuladen. Setzen Sie eine Content Security Policy (CSP) ein, um die Auswirkungen von Drittanbieter-Skripten zu begrenzen, indem Sie zum Beispiel das Herunterladen von Audio oder Video verbieten. Betten Sie Skripte über ein iframe ein, damit die Skripte keinen Zugriff auf den DOM haben. Für Belastungstests von Skripten untersuchen Sie die Zusammenfassung auf der Registerkarte „Performance“ (DevTools). Laden Sie Drittanbieter-Skripte erst, wenn die Anwendung geladen ist. Konzentrieren Sie sich auf Code-Teile, die das Blinken von Inhalten vor dem Laden des Skripts verhindern.

• Stellen Sie die HTTP-Cache-Header korrekt ein.

  Überprüfen Sie, ob expires, cache-control, max-age und andere HTTP-Cache-Header korrekt eingestellt sind. Im Allgemeinen sollten Ressourcen entweder für sehr kurze Zeit (wenn sie sich wahrscheinlich ändern) oder auf unbestimmte Zeit (wenn sie statisch sind) cachebar sein.

  Verwenden Sie cache-control: immutable, um Revalidierung zu verhindern. Stellen Sie sicher, dass Sie keine unnötigen Header senden (z.B. x-powered-by, pragma, x-ua-compatible, expires). Nutzen Sie null RTT für wiederholte Anzeige durch stale-while-revalidate.

• Laden Sie JavaScript asynchron.

  Nutzen Sie Lazy-Loading für alle Komponenten wie große JS-Dateien, Videos, iframes, Widgets und auch Bilder. Nutzen Sie native Lazy-Loading (Attribute loading und importance) oder Lösungen, die Intersection Observer verwenden. Die zweite Lösung können Sie auch für leistungsstarkes „Scrollytelling“ – Parallax-Effekte oder das Tracking von Anzeigen verwenden.

• Verschieben Sie das Rendering und Dekodieren großer Bilder.

  Mit der Eigenschaft content-visibility: auto können wir den Browser anweisen, das Rendering von Nachkommenelementen zu überspringen, wenn sich das Element außerhalb des Viewports befindet. Stellen Sie sicher, dass Sie die Eigenschaft contain-intrinsic-size mit einem geeigneten Platzhalter verwenden, um ein Verschlechtern der Metrik für die kumulative Layoutverschiebung (CLS) zu vermeiden. Verwenden Sie auch <img decoding="async">. Der Browser dekodiert das Bild dann außerhalb des Haupt-Threads und verkürzt die CPU-Zeit, die für die Operation benötigt wird.

• Laden Sie kritisches CSS so schnell wie möglich.

  Extrahieren Sie alle Stile, die zum Rendern des im Viewport sichtbaren Inhalts erforderlich sind (sogenanntes kritisches CSS oder CSS über dem Fold). Fügen Sie diese Stile als Inline in den <head>-Tag der Seite ein. Die goldene Regel ist, dass Sie insgesamt 14 kB nicht überschreiten sollten. Erwägen Sie bedingte CSS-Einfügungen auf der Seite. In einigen Fällen ist es besser, kritisches CSS in einer separaten Datei im Stammverzeichnis der Domain abzulegen. Durch Caching kann diese Lösung besser sein als das Einfügen von Inline-Stilen.

• Experimentieren Sie mit dem Umstrukturieren von CSS-Dateien/-Eigenschaften.

  Bei der Ladeoptimierung können Sie auch das Aufteilen von Haupt-CSS nach einzelnen Media Queries in Betracht ziehen. Platzieren Sie <link rel ="stylesheet"/> nicht vor asynchronen Dateien. Wenn Skripte nicht von Stilen abhängen, platzieren Sie blockierende Skripte über blockierenden Stilen. Wenn ja, teilen Sie dieses JavaScript in zwei Teile und laden Sie es vor und nach den CSS-Dateien. Speichern Sie eingebettete CSS mit Service Workern im Cache und experimentieren Sie mit in-body CSS. Dynamische Stile können „teuer“ sein: Überprüfen Sie, ob CSS-in-JS die Ausführung optimiert, wenn das CSS keine Abhängigkeiten von Erscheinungsbild oder Komponentenattributen hat, vereinfachen Sie die Komponenten (styled-components).

• Streamen Sie Antworten.

  Streaming bietet eine Schnittstelle zum Lesen oder Schreiben asynchroner Datenblöcke, deren Teilmenge zu einem bestimmten Zeitpunkt im Speicher verfügbar sein kann. Anstatt ein leeres UI-Skelett zu liefern und Inhalte mit JavaScript zu füllen, verwenden Sie einen Service Worker, laden Sie das Skelett aus dem Cache und den Inhalt aus dem Netzwerk. HTML, das während der ersten Anfrage gerendert wird, kann dann den HTML-Parser des Browsers vollständig nutzen.

• Berücksichtigen Sie die Anpassung Ihrer Komponenten an die Verbindung und den Speicher der Geräte.

  Verwenden Sie den Client-Hint Header Save-Data und passen Sie die Anwendung an, indem Sie die Einschränkungen Ihrer Benutzer (Kosten, Leistung) berücksichtigen. Sie können Anforderungen an hochauflösende Bilder auf niedrigauflösende Bilder überschreiben, Webfonts entfernen, Parallax deaktivieren, Autoplay von Videos ausschalten oder sogar die Art und Weise, wie Sie Code bereitstellen, ändern. Verwenden Sie die Network Information API zur Bereitstellung von Varianten ressourcenintensiver Komponenten basierend auf der Verbindung und die Device Memory API zur Anpassung von Ressourcen basierend auf dem Gerätespeicher.

• Halten Sie die Verbindung stabil, um die Bereitstellung zu beschleunigen.

  Sparen Sie Zeit durch die Verwendung von Resource Hints; dns-prefetch (DNS-Lookup im Hintergrund), preconnect (Starten des Verbindungs-Handshakes (DNS, TCP, TLS)), prefetch (Anforderung von Ressourcen), preload (Vorladen von Ressourcen ohne deren Ausführung) und prerender (Vorladen von Ressourcen ohne Ausführung von JS und ohne Rendering auf der Seite). Bei Verwendung von preload muss as definiert sein, sonst wird nichts geladen. Das Vorladen von Schriftarten ohne crossorigin Attribut führt zu doppeltem Laden. Bei Verwendung von preload gibt es eine Reihe von Prioritäten, daher erwägen Sie das Einfügen von rel=”preload” Elementen in den DOM unmittelbar vor externen blockierenden Skripten.

• Verwenden Sie Service Worker zum Cachen und als Fallback bei Netzausfällen.

  Wenn Ihre Website über HTTPS läuft, speichern Sie statische Ressourcen im Service Worker Cache und speichern Sie einen Offline-Fallback (oder sogar ganze Seiten) und laden Sie sie vom Gerät und nicht aus dem Netzwerk. Speichern Sie die Anwendungsumgebung im Service Worker Cache zusammen mit einigen kritischen Seiten, z.B. einer Offline-Seite oder der Startseite. Stellen Sie jedoch sicher, dass es einen korrekten CORS-Antwortheader gibt, speichern Sie keine undurchsichtigen Antworten und melden Sie Cross-Origin-Bilder im CORS-Modus an.

• Verwenden Sie Service Worker auf CDN/Edge (z.B. für A/B-Tests).

  Bei CDNs, die Service Worker auf dem Server implementieren, erwägen Sie die Leistungsoptimierung mit Service Workern direkt „on the edge“. Beispielsweise bei A/B-Tests, wenn HTML seinen Inhalt für verschiedene Benutzer ändern muss, verwenden Sie zur Verarbeitung der Logik einen Service Worker auf dem CDN.

  Websites, die Google-Schriften verwenden, können Sie durch Stream HTML rewriting beschleunigen.

• Optimieren Sie die Rendering-Leistung.

  Isolieren Sie bei Bedarf teure Komponenten mit CSS containment. Stellen Sie sicher, dass beim Scrollen der Seite oder bei der Animation eines Elements keine Verzögerung auftritt und dass Sie dauerhaft 60 Bilder pro Sekunde erreichen. Wenn dies nicht möglich ist, streben Sie an, die Bildrate zumindest konstant zu halten. Die minimale Bildwiederholrate wird allgemein als 15 Bilder pro Sekunde angesehen. Mit CSS will-change informieren Sie den Browser darüber, welche Elemente sich ändern werden.

• Haben Sie ein optimiertes Rendering-Erlebnis?

  Unterschätzen Sie nicht die Rolle der wahrgenommenen Geschwindigkeit. Wenn Sie Dateien laden, versuchen Sie, immer einen Schritt voraus zu sein, damit das Erlebnis reibungslos ist, auch wenn im Hintergrund viel passiert. Um den Kunden zu beeindrucken, verwenden Sie „Skeletons“ anstelle von Ladeindikatoren und fügen Sie Übergänge und Animationen hinzu.

• Vermeiden Sie Layoutverschiebungen (Reflow) und Neuzeichnungen (Repaint).

  Layoutverschiebungen werden häufig durch Änderungen an der Größe von Komponenten wie Videos und Bildern, das Nachladen von Web-Schriftarten, eingebettete Anzeigen oder das Nachladen von echtem Inhalt in Komponenten ausgelöst. Setzen Sie width und height bei Bildern, damit moderne Browser den benötigten Platz reservieren können. Verwenden Sie Platzhalter-SVGs, um genügend Platz zu reservieren, in dem sich Bilder oder Videos befinden werden. Verwenden Sie JavaScript-basiertes Lazy-Loading, wenn keine native Version für die Komponente verfügbar ist. Laden Sie JS Lazy-Loading wirklich erst, wenn Sie es benötigen. Identifizieren Sie Layoutverschiebungen, die durch Web-Schriftarten verursacht werden, und vergleichen Sie die line-height und die Abstände mit font-style-matcher. Verfolgen Sie die Layoutstabilität mit dem Layout Instability API und der Metrik Cumulative Layout Shift (CLS).

• Haben Sie OCSP Stapling aktiviert?

  OCSP Stapling kann den TLS-Authentifizierungsprozess beschleunigen, da der Browser keine Zeit damit verbringen muss, nach Informationen über das Zertifikat Ihrer Domain zu suchen und diese herunterzuladen.

• Haben Sie die Auswirkungen des Widerrufs von SSL-Zertifikaten reduziert?

  Extended Validation (EV)-Zertifikate sind teuer und zeitaufwändig, da sie immer manuell überprüft werden müssen. Gewöhnliche Domain Validation (DV)-Zertifikate sind kostenlos (Let’s Encrypt) und ihre Ausstellung und Erneuerung kann leicht automatisiert werden. EV-Zertifikate unterstützen außerdem kein OCSP Stapling, daher sollten Sie immer ein DV-Zertifikat mit aktiviertem Stapling haben.

• Verwenden Sie IPv6?

  Studien zeigen, dass Websites um bis zu 15 % schneller sind dank NDP (Neighbor Discovery Protocol) und Routenoptimierung. Aktualisieren Sie Ihre DNS-Einträge, damit Ihre Website auch über IPv6 erreichbar ist. Vergessen Sie jedoch nicht das bestehende IPv4, da beide Versionen nicht miteinander kompatibel sind.

• Wird TCP BBR verwendet?

  BBR ist ein relativ neuer Algorithmus zur Flusskontrolle des TCP-Protokolls. Es reagiert eher auf tatsächliche Überlastung als auf Paketverlust, wie es TCP tut. Daher ist es deutlich schneller, mit höherem Durchsatz und geringerer Latenz. Aktivieren Sie BBR und setzen Sie tcp_notsent_lowat auf 16 kB, damit die Priorisierung auf HTTP/2 zuverlässig auf Linux-Kernen 4.9 und neuer funktioniert.

• Bevorzugen Sie immer HTTP/2.

  HTTP/2 wird sehr gut unterstützt und bietet Geschwindigkeitssteigerungen. Je nachdem, wie groß Ihre mobile Benutzerbasis ist, müssen Sie möglicherweise verschiedene Builds (Anwendungsversionen) an Benutzer senden und können von der Anpassung verschiedener Builds für verschiedene Geräte profitieren. (HTTP/2 ist oft langsamer in Netzwerken mit spürbarem Paketverlust.)

• Implementieren Sie HTTP/2 korrekt.

  Sie müssen ein feines Gleichgewicht zwischen dem Verbinden von Modulen zu einem und dem parallelen Laden vieler kleiner Module finden. Teilen Sie Ihre gesamte Schnittstelle in viele kleine Module auf; gruppieren, komprimieren und bündeln Sie sie dann. Teilen Sie sie auf Paketebene oder indem Sie verfolgen, welche CSS/JS-Blöcke ungenutzt sind. Trennen Sie Drittanbieter-Code von Ihrem eigenen und trennen Sie Abhängigkeiten, die sich nur selten und oft ändern. Das Senden von etwa 6–10 Paketen von Frontend-Elementen scheint ein vernünftiger Kompromiss zu sein (und das ist nicht schlecht für ältere Browser). Experimentieren und messen Sie, um das richtige Gleichgewicht zu finden. Versuchen Sie, so viele Elemente wie möglich über eine einzige HTTP/2-Verbindung zu senden.

• Unterstützen Ihre Server und CDNs HTTP/2?

  Verschiedene Server und CDNs unterstützen HTTP/2 unterschiedlich. Mit Tools, die CDN vergleichen (z.B. CDN Comparison), können Sie Ihre Optionen überprüfen oder schnell die Unterstützungsstufe verschiedener Funktionen finden. Aktivieren Sie BBR und setzen Sie tcp_notsent_lowat auf 16 kB für die Priorisierung auf HTTP/2.

• Wird HPACK-Kompression verwendet?

  Wenn Sie HTTP/2 verwenden, überprüfen Sie, ob Ihre Server die HPACK-Kompression für HTTP-Antwortheader implementieren, um unnötigen Overhead zu reduzieren. HTTP/2-Server sind relativ neu und unterstützen möglicherweise nicht vollständig die Spezifikation, ein Beispiel ist HPACK. H2spec ist ein großartiges (wenn auch technisch sehr detailliertes) Tool, das dies überprüft.

• Bereiten Sie sich auf HTTP/3 vor.

  Bei HTTP/2 teilen sich mehrere Anfragen eine Verbindung. Bei HTTP/3 teilen die Anfragen ebenfalls eine Verbindung, aber sie streamen unabhängig, sodass ein verlorenes Paket nicht mehr alle Anfragen betrifft, sondern nur einen Stream. Mit der QUIC-Technologie auf HTTP/3 werden TCP und TLS kombiniert und in einem einzigen „Round Trip“ durchgeführt. Ab der zweiten Verbindung können wir bereits Daten der Anwendungsschicht in der ersten „Round Trip“ (0-RTT) senden und empfangen. Das Bündeln von Frontend-Elementen ist weiterhin wichtig, daher senden Sie statt eines monolithischen JS mehrere JS-Dateien parallel, wie bei HTTP/2. Erwarten Sie Auswirkungen von HTTP/3 auf die Ladezeiten bei mobilen Geräten.

• Unterstützen Ihre Server und CDNs HTTP/3?

  QUIC und HTTP/3 sind besser und stabiler: mit schnelleren „Handshakes“, besserer Verschlüsselung, zuverlässigeren unabhängigen Streams, mehr Verschlüsselung und 0-RTT, wenn der Client bereits eine Verbindung zum Server hatte. Es ist jedoch ziemlich CPU-intensiv (2–3-fache CPU-Auslastung für dieselbe Bandbreite). Überprüfen Sie, ob Ihre Server oder CDNs das HTTP over QUIC-Protokoll (auch bekannt als HTTP/3) unterstützen und aktivieren Sie es, wenn möglich.

• Stellen Sie sicher, dass die Sicherheit auf Ihrem Server undurchdringlich ist.

  Vergewissern Sie sich, dass Sicherheitsheader korrekt eingestellt sind, bekannte Sicherheitslücken entfernt wurden und das HTTPS-Setup überprüft wurde. Stellen Sie sicher, dass alle externen Plugins und Tracking-Skripte über HTTPS geladen werden, dass Cross-Site-Scripting nicht möglich ist und dass HTTP Strict Transport Security-Header und Content Security Policy-Header korrekt eingestellt sind.

• Überwachen Sie Warnungen zu gemischtem Inhalt (Mixed Content).

  Wenn Sie kürzlich von HTTP zu HTTPS migriert sind, vergessen Sie nicht, aktive und passive Mixed-Content-Warnungen mit Tools wie Report-URI.io zu überwachen. Sie können auch Mixed Content Scan verwenden, um gemischte Inhalte auf Ihrer HTTPS-unterstützten Website zu scannen.

• Haben Sie Ihren Audit- und Debug-Workflow optimiert?

  Investieren Sie Zeit in das Studium von Debugging- und Audit-Techniken in Ihrem Debugger, WebPageTest, Lighthouse und erweitern Sie Ihren Texteditor. Sie können beispielsweise WebPageTest aus einer Google-Tabelle ausführen und die Zugänglichkeits-, Leistungs- und SEO-Werte in Ihre Travis-Einstellungen integrieren, indem Sie Lighthouse CI oder direkt in Webpack verwenden. Für schnelle Überprüfungen verwenden Sie CSS Perf Diagnostic.

• Haben Sie in Proxy-Browsern und älteren Browsern getestet?

  Tests in Chrome und Firefox sind nicht ausreichend. Sehen Sie, wie Ihre Website in Proxy-Browsern und älteren Browsern (einschließlich UC Browser und Opera Mini) funktioniert. Messen Sie die durchschnittliche Internetgeschwindigkeit unter Ihren Benutzern, um große Überraschungen zu vermeiden. Testen Sie mit Netzwerkeinschränkungen und emulieren Sie Geräte mit hoher DPI. BrowserStack ist fantastisch, aber testen Sie auch auf echten Geräten.

• Haben Sie die Geschwindigkeit Ihrer 404-Seiten getestet?

  Jedes Mal, wenn ein Client ein Element der Website anfordert, das nicht existiert, erhält er eine 404-Antwort – und diese Antwort ist oft riesig. Vergessen Sie nicht, die Strategie zum Caching auch für Ihre 404-Seiten zu untersuchen und zu optimieren. Stellen Sie sicher, dass der Browser HTML nur dann anzeigt, wenn er eine HTML-Antwort erwartet, und für alle anderen Antworten eine Fehlerantwort zurückgibt.

• Haben Sie die Auswirkungen auf die Leistung Ihrer GDPR- und Cookie-Banner getestet?

  Normalerweise sollten Cookie-Zustimmungsaufforderungen keine Auswirkungen auf CLS haben, aber manchmal kann dies passieren, daher erwägen Sie die Verwendung kostenloser und Open-Source-Ressourcen wie Osano oder cookie-consent-box. Die Zustimmung wird wahrscheinlich die Auswirkungen von Skripten auf die Gesamtleistung ändern, daher richten Sie verschiedene Testprofile für die Web-Performance für verschiedene Arten von Zustimmung ein und studieren Sie sie.

• Haben Sie die Auswirkungen auf die Zugänglichkeit getestet?

  Große Seiten und DOM-Manipulationen mit JavaScript verursachen Verzögerungen bei Bildschirmlesern. Schnelle Time to Interactive bedeutet, wie viel Zeit vergeht, bis der Bildschirmleser die Navigation auf der Seite ankündigen kann und der Benutzer tatsächlich die Tastatur drücken kann, um zu interagieren.

• Ist kontinuierliches Monitoring eingerichtet?

  Gute Geschwindigkeitsmetriken entstehen durch die Kombination von passiven und aktiven Überwachungstools. Eine private WebPagetesting-Instanz und die Verwendung von Lighthouse sind immer von Vorteil für schnelle Tests, aber auch das Einrichten von kontinuierlichem Monitoring mit RUM-Tools wie SpeedTracker, SpeedCurve und anderen. Richten Sie Ihre eigenen User-Timing-Marken ein, um die spezifischen Metriken für Ihre Website zu messen und zu überwachen.

Die Checkliste zur Webgeschwindigkeit ist ziemlich komplex und die Umsetzung aller Optimierungen kann einige Zeit in Anspruch nehmen. Wenn Sie also nur 1 Stunde Zeit hätten, um erhebliche Verbesserungen zu erzielen, was würden Sie tun? Wir fassen es auf 18 leicht erreichbare Ergebnisse zusammen. Natürlich gilt, dass Sie die Ergebnisse messen sollten, sowohl bevor Sie beginnen als auch nachdem Sie fertig sind, einschließlich der Metriken Largest Contentful Paint und Time To Interactive auf 3G und auch Kabelverbindung.

• Messen Sie die Geschwindigkeit unter echten Benutzern und setzen Sie geeignete Ziele. Versuchen Sie, mindestens 20 % schneller zu sein als Ihr schnellster Konkurrent. Halten Sie Largest Contentful Paint unter 2,5 s, First Input Delay unter 100 ms, Time to Interactive unter 5 Sekunden im langsamen 3G, für wiederholte Besuche unter 2 s. Optimieren Sie mindestens für First Contentful Paint und Time To Interactive.
• Optimieren Sie Bilder mit Squoosh, mozjpeg, guetzli, pingo und SVGOMG und servieren Sie AVIF/WebP mit einem Bild-CDN.
• Bereiten Sie kritisches CSS für Ihre Hauptvorlagen vor und fügen Sie es inline in den <head> jeder von ihnen ein. Bei CSS und JS sollten Sie ein Budget für die Größe kritischer Dateien von maximal 170 kB nach gzip (0,7 MB entpackt) haben.
• Kürzen, optimieren, verzögern und lazy-loaden Sie Skripte. Investieren Sie in die Konfiguration Ihres Bundlers, um Redundanzen zu entfernen, und suchen Sie nach weniger datenintensiven Alternativen.
• Hosten Sie immer statische Frontend-Dateien auf Ihrer eigenen Domain. Bevorzugen Sie auch das Hosting von Drittanbieter-Komponenten auf Ihrer eigenen Domain. Begrenzen Sie deren Auswirkungen. Verwenden Sie Fassaden und Platzhalter, laden Sie Widgets bei Interaktionen und achten Sie auf das Blinken der ursprünglichen Version.
• Seien Sie anspruchsvoll bei der Auswahl des Frameworks. Bei Single-Page-Applications (SPA) identifizieren Sie kritische Seiten und rendern Sie sie statisch, oder prerendern Sie sie zumindest. Verwenden Sie progressive Hydration auf Komponentenebene und importieren Sie Module bei Interaktion.
• Rendering nur auf der Client-Seite ist keine gute Wahl für die Leistung. Prerendern Sie, wenn sich Ihre Seiten nicht zu oft ändern, und verzögern Sie das Booten von Frameworks. Verwenden Sie Streaming-Rendering auf der Server-Seite (SSR).
• Bieten Sie älteren Code nur für ältere Browser an, indem Sie das module/nomodule-Designmuster verwenden.
• Experimentieren Sie mit dem Umstrukturieren von CSS-Regeln und testen Sie CSS direkt im HTML.
• Fügen Sie Resource Hints hinzu, um das Servieren durch DNS-Lookup, Preconnect, Prefetch, Preload, Prerender zu beschleunigen.
• Subsetten Sie Webfonts und laden Sie sie asynchron, nutzen Sie font-display in CSS für schnelles erstes Rendering.
• Überprüfen Sie, ob die HTTP-Caches und Sicherheitsheader korrekt eingestellt sind.
• Aktivieren Sie Brotli-Kompression auf dem Server. (Falls nicht möglich, vergessen Sie nicht, Gzip-Kompression zu aktivieren.)
• Aktivieren Sie TCP-Flusskontrolle mit BBR, wenn Ihr Server auf einem Linux-Kernel ab Version 4.9 läuft.
• Wenn möglich, aktivieren Sie OCSP Stapling und IPv6. Servieren Sie immer ein DV-Zertifikat mit OCSP.
• Aktivieren Sie HPACK-Kompression für HTTP/2 und migrieren Sie zu HTTP/3, wenn verfügbar.
• Cachen Sie Ressourcen wie Schriftarten, Stile, JavaScript und Bilder im Service Worker Cache.
• Erkunden Sie Möglichkeiten, um Rehydratation zu vermeiden, verwenden Sie progressive Hydration und Server-Side-Streaming für Ihre Single-Page-Application (SPA).

Großer Dank für die Überprüfung des ursprünglichen Artikels in Smashing Magazine geht an Guy Podjarny, Yoav Weiss, Addy Osmani, Artem Denysov, Denys Mishunov, Ilya Pukhalski, Jeremy Wagner, Colin Bendell, Mark Zeman, Patrick Meenan, Leonardo Losoviz, Andy Davies, Rachel Andrew, Anselm Hannemann, Barry Pollard, Patrick Hamann, Gideon Pyzer, Andy Davies, Maria Prosvernina, Tim Kadlec, Rey Bango, Matthias Ott, Peter Bowyer, Phil Walton, Mariana Peralta, Pepijn Senders, Mark Nottingham, Jean Pierre Vincent, Philipp Tellis, Ryan Townsend, Ingrid Bergman, Mohamed Hussain S. H., Jacob Groß, Tim Swalling, Bob Visser, Kev Adamson, Adir Amsalem, Aleksey Kulikov und Rodney Rehm.

Deutsche Übersetzung: Tomáš Hejč, Martin Brychta, Zuzana Fatrdla, Martin Michálek. (Team PageSpeed.ONE)

Tags:Web Performance