Checkliste für Webgeschwindigkeit 2021

Lassen Sie uns das Jahr 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 eine schnelle Benutzererfahrung im Web zu gewährleisten – von Metriken über Tools bis hin zu Entwicklertechniken.

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

Inhalt des Artikels:

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 ohne Investitionen nicht nachhaltig sein. Untersuchen Sie häufige Beschwerden im Kundensupport und finden Sie heraus, wie eine Geschwindigkeitssteigerung einige dieser Probleme lindern kann. Erstellen Sie eine Fallstudie mit realen Daten und Geschäftsmessungen, die auf Ihr Unternehmen zugeschnitten sind. Planen Sie bereits bei der Gestaltung der Website den Ladevorgang und eventuelle Kompromisse.

• Seien Sie 20 % schneller als Ihr schnellster Mitbewerber.

  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 Mittelklasse-Gerät wie Nexus 5X, Xiaomi Mi A3 oder Xiaomi Redmi Note 7 und ein langsames Gerät wie Alcatel 1X oder Cubot X19. Alternativ können Sie mobile Betriebssysteme auf einem Computer emulieren, indem Sie die Netzwerkgeschwindigkeit einschränken (z.B. 300 ms RTT, 1,6 Mb/s Download, 0,8 Mb/s Upload) und die CPU begrenzen (5× Verlangsamung). Wechseln Sie dann zu normalem 3G, langsamem 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_“, Geschwindigkeitsgrenzen).

• Wählen Sie die richtigen Metriken aus.

  Nicht jede Metrik hat aus Sicht der Optimierung denselben Wert. Untersuchen Sie, welche Metriken am wichtigsten sind: In der Regel beziehen sie sich darauf, wie schnell die wichtigsten Pixel gerendert werden und wie schnell die Eingabeverzögerung ist. Konzentrieren Sie sich also auf das Laden der Seite nach den Prioritäten Ihrer Besucher. Meistens sind Time To Interactive (TTI), First Input Delay (FID), Rendering des „Hero“-Elements, Largest Contentful Paint (LCP), Total Blocking Time (TBT) und Cumulative Layout Shift (CLS) von Bedeutung. Nicht jedoch: First Meaningful Paint.

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

  Deaktivieren Sie Antivirenprogramme und CPU-intensive Hintergrundaufgaben, stoppen Sie Hintergrunddatenübertragungen und testen Sie mit einem „sauberen“ Benutzerprofil ohne Browsererweiterungen, um Ergebnisse nicht zu verfälschen. Untersuchen Sie, welche Erweiterungen Ihre Kunden verwenden, und testen Sie auch ein spezielles „Kunden“-Profil.

• Teilen Sie die Checkliste für Webgeschwindigkeit mit Ihren Kollegen.

  Stellen Sie sicher, dass jedes Teammitglied diese Checkliste für Webgeschwindigkeit kennt. Jede Entscheidung beeinflusst die Leistung, und Ihr Projekt profitiert erheblich davon, wenn die Verantwortung im gesamten Team verteilt wird. Gleichzeitig kartieren Sie Designentscheidungen und vergleichen sie mit dem Performance-Budget.

• Antwortzeit 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 sinnvoll; bei aufwendigen Aktivitäten wie Animationen ist es besser, auf der Seite nichts anderes zu tun. Wo das nicht möglich ist, tun Sie nur das absolut Notwendige. Die geschätzte Eingabelatenz sollte unter 50 ms liegen. Nutzen Sie Leerlaufzeiten mit dem Ansatz Idle Until Urgent.

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

  Wenn Sie als Ausgangsgerät ein Android-Mobiltelefon mit einem Preis von etwa 160 EUR auf einem langsamen 3G-Netzwerk in Betracht ziehen, emuliert bei einer Übertragungsgeschwindigkeit von 400 ms RTT und 400 kB/s, zielen Sie auf Time To Interactive (TTI) < 5 Sekunden und auf wiederholte Besuche unter 2–3 Sekunden. Fokussieren Sie auf Largest Contentful Paint < 2,5 Sekunden und minimieren Sie Total Blocking Time (TBT) und Cumulative Layout Shift (CLS). Bemühen Sie sich, diese Werte auf ein Minimum zu reduzieren.

• Dateigrößenlimit < 170 kB.

  Die ersten 14–16 kB HTML-Code sind am kritischsten — es handelt sich um den einzigen Teil, der im ersten über das Netzwerk übertragenen Paket („first roundtrip“) geliefert wird. Um die oben genannten Ziele zu erreichen, arbeiten Sie mit einer maximalen gzip-komprimierten Dateigröße von 170 kB (0,7 – 0,8 MB dekomprimiert). Stellen Sie sicher, dass Ihre Geschwindigkeitslimits je nach Netzwerkkonditionen 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 ein „cooles“ Tool ist oder nicht. Wenn Sie schnell Ergebnisse erzielen und keine Probleme mit der Wartung Ihres Entwicklungsprozesses haben, ist alles in Ordnung. Ausnahmen können Webpack oder Parcel sein, die nützliche Optimierungstechniken wie Code-Splitting bieten. Wenn Sie diese Techniken noch nicht verwenden, schauen Sie sich das bereits erwähnte Code-Splitting und Tree-Shaking an.

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

  Entwerfen und erstellen Sie zuerst eine grundlegende Oberfläche, damit die Website die 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 schlechter Anzeige und in einem schlechten Browser in einem nicht optimalen Netzwerk schnell läuft, wird sie auch auf einem schnellen Gerät mit gutem Browser und in einem ordentlichen Netzwerk schneller laufen.

• Setzen Sie die Performance-Latte hoch.

  JavaScript birgt die größten Kosten für die Benutzererfahrung. Mit einem Limit von 170 kB, das bereits kritische Daten und Pfade – HTML / CSS / JavaScript, Router, Statusmanagement, Tools, Schnittstelle und Anwendungen – umfasst, untersuchen Sie gründlich die Zeitkosten für Netzwerkübertragungen, Parsing, 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 sorgfältig aus; bewerten Sie Drittanbieter-JS durch Untersuchung 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 solide Ausgangswerte 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 Mobilgerä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-Designmuster 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. Berücksichtigen Sie die Verwendung von GraphQL, mit dem Sie Abfragen über ein von Ihnen erstelltes Typensystem auf Ihren Daten ausführen können. Im Gegensatz zu REST kann GraphQL alle Daten in einer Abfrage abrufen, ohne zu viele oder zu wenige Daten herunterzuladen, was oft in REST-Architekturen passiert.

• Probieren Sie Google AMP oder Facebook Instant Articles?

  Auch ohne diese Technologien können Sie gute Leistung erzielen, aber AMP bietet eine sehr gute Leistungsgrundlage und ein globales CDN. Instant Articles helfen Ihnen vor allem, Sichtbarkeit auf Facebook zu erlangen und bis zu 4-mal schnelleres Laden als herkömmliche mobile Websites zu erreichen.

• Wählen Sie Ihr CDN weise.

  Überlegen Sie, wie stark Sie von dynamischen Daten abhängen. Sie können zumindest einen Teil Ihres Inhalts statisch generieren, auf ein CDN hochladen und so überflüssige Datenbankabfragen vermeiden (JAMStack). Stellen Sie sicher, dass Ihr CDN Inhaltskomprimierung und Bildkonvertierung durchführt (z.B. Optimierung und Größen- oder Formatänderung) und dass es Server-Worker unterstützt.

• Verwenden Sie Brotli zur Komprimierung.

  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 im Voraus mit Brotli und Gzip auf höchstem Niveau, komprimieren Sie HTML 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 „Content Negotiation“ für Brotli oder Gzip korrekt durchführt.

• Verwenden Sie responsive Bilder, AVIF und WebP.

  Verwenden Sie nach Möglichkeit 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 per Accept-Header. Hinweis: Mit WebP reduzieren Sie das Datenvolumen, aber mit JPEG können Sie dank der Eigenschaft des „progressiven Renderings“ die wahrgenommene Geschwindigkeit verbessern.

• Sind die Bilder richtig optimiert?

  Verwenden Sie mozJPEG für die JPEG-Komprimierung, SVGO für die SVG-Komprimierung, Pingo für PNG oder Squoosh für alle davon (einschließlich AVIF). Um die Effizienz 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ßschem Weichzeichner) und entfernen Sie den Kontrast (Sie können ihn später mit CSS-Filtern wiederherstellen). Achten Sie darauf, dass Sie für alle Ihre Bilder die Attribute width und height gesetzt haben. Fügen Sie automatische Bildkomprimierung in Ihre Pull-Requests ein und erkunden Sie Lazy Loading für weniger kritische Bilder.

• Sind Videos richtig optimiert?

  Verwenden Sie anstelle von animierten GIFs entweder animierte WebP (und GIF als Fallback) oder betten Sie Schleifen mit Inline-HTML5-Videos ein. Stellen Sie sicher, dass Ihre MP4-Dateien mit Mehrfachdurchgang-Codierung verarbeitet werden, mit „frei0r iirblur“ (sofern verfügbar) verwischt sind, moov atom-Metadaten in den Header der Datei verschoben sind und Ihr Server Byte Serving akzeptiert. Wann immer möglich, verwenden Sie Videos im AV1-Format, bieten jedoch gleichzeitig Fallbacks für ältere Formate. Passen Sie die Videogrößen an und bieten Sie durch adaptive Medienbereitstellung Inhalte an, die Besucher auf ihren Geräten ohne Verzögerung abspielen können.

• Sind Schriftarten optimiert?

  Setzen Sie das richtige Subsetting für Ihre Schriftart. Bevorzugen Sie WOFF2 und verwenden Sie WOFF als Fallback. Zeigen Sie den Inhalt sofort mit einer Fallback-Schriftart an, laden Sie die benutzerdefinierte Schriftart asynchron und wechseln Sie dann zur Schriftart. Ideale Lösung: zweistufiges Rendering, zuerst mit einem kleinen Supersubset und den Rest später asynchron laden. Preloaden Sie 1-2 Schriften jeder Familie. Vermeiden Sie die Verwendung von local() in der Schrifterklärung, erwägen Sie jedoch die Verwendung von in Betriebssystemen installierten Schriftarten. Vergessen Sie nicht, font-display:optional zu verwenden und nutzen Sie Font Load-Ereignisse für das Neuzeichnen. Verwenden Sie Metriken wie 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 gruppieren Sie sie. Definieren Sie die grundlegende Erfahrung (vollständig zugänglicher Basisinhalt für ältere Browser), die verbesserte Erfahrung (bereichert, voll funktionsfähig für moderne Browser) und Add-ons (Ressourcen, die nicht unbedingt erforderlich sind und die lazy geladen werden können).

• Verwenden Sie native JavaScript-Module in der Produktion.

  In älteren Browsern unterstützen Sie die grundlegende Erfahrung, voll funktionsfähig nur in modernen Browsern. Verwenden Sie für das Laden von JavaScript ES2017+ <script type="module">. Moderne Browser interpretieren das Script als JavaScript-Modul und führen es erwartungsgemäß aus. Ältere Browser ignorieren es.

• JavaScript auszuführen ist teuer, also zügeln 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 zur Beschleunigung der anfänglichen Renderzeit, z.B. progressive hydration und Import bei Interaktion (bei ä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 „Chunks“, die bei Bedarf geladen werden. Scope Hoisting erkennt, wo das Import-Verketten konsolidiert und in eine Inline-Funktion umgewandelt werden kann, während die Funktionalität erhalten bleibt (z.B. mit Webpack). Verwenden Sie granular chunking und verschieben 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 Ihr Code weiterentwickelt, beginnen sich Leistungsengpässe in der Benutzeroberfläche zu zeigen. Es kommt daher vor, dass DOM-Operationen neben Ihrem JS im Hauptthread 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: Preloading von Daten in PWA. Erwägen Sie den Umzug rechenintensiver Aufgaben in WebAssembly, das sich am besten für anspruchsvolle Webanwendungen wie Spiele eignet.

• Senden Sie alten Code nur an ältere Browser.

  Verwenden Sie babel-preset-env, um ES2017+ Funktionen für nicht unterstützte moderne Browser zu transpilieren, die Sie unterstützen. Erstellen Sie dann zwei Build-Versionen, 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-Duplizierung zu verhindern. Verwenden Sie <link rel="modulepreload">, um frühzeitiges (hochpriorisiertes) Laden von Modulen zu initiieren.

• Identifizieren und überarbeiten Sie alten (Legacy) Code mithilfe von „incremental decoupling“.

  Überprüfen Sie die Abhängigkeiten Ihres Projekts und beurteilen Sie, wie viel Zeit für die Refaktorierung oder das Umschreiben von altem Code erforderlich wäre. Setzen Sie zunächst Metriken, die überwachen, ob der Anteil der Aufrufe von Legacy-Code gleich bleibt oder sinkt. Der Anteil darf nicht steigen. Legen Sie im Team Bedingungen fest, die die Verwendung zusätzlicher Bibliotheken nicht tolerieren, und stellen Sie sicher, dass CI die Entwickler bei Pull-Requests immer benachrichtigt.

• Identifizieren und entfernen Sie ungenutztes CSS/JavaScript.

  CSS- und JavaScript-Abdeckung in Chrome ermöglicht es Ihnen, festzustellen, welcher Code ausgeführt/verwendet wurde und welcher nicht. Sobald Sie ungenutzten Code identifiziert haben, finden Sie diese Module und fügen Sie Lazy Loading mit import() hinzu. Führen Sie den Abdeckungstest erneut durch und bestätigen Sie, dass beim ersten Laden weniger Code gesendet wird. Verwenden Sie Puppeteer, um automatisch Code-Abdeckungsergebnisse zu sammeln.

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

  Es besteht eine hohe Wahrscheinlichkeit, dass Sie in Ihren Projekten ganze JavaScript-Bibliotheken haben, aber tatsächlich nur einen Bruchteil des Codes verwenden. Erwägen Sie die Verwendung von automatischen webpack-libs-optimizations, das ungenutzte Methoden und Polyfills während des Build-Prozesses entfernt. Fügen Sie die Paketkontrolle in Ihren normalen Arbeitsablauf ein. Bundlephobia hilft, die Auswirkungen auf die Leistung beim Hinzufügen einzelner NPM-Pakete zu Ihrem Projekt zu beziffern. Size-limit erweitert die klassische Paketgrößenkontrolle um die Ausführungszeit in JavaScript. Skypack können Sie als Quelle für auf Qualität und Leistung ausgerichtete Pakete nutzen, die von einzelnen Community-Mitgliedern verwaltet werden.

• Verwenden Sie prädiktives Prefetch für JavaScript-Code-Segmente?

  Nutzen Sie Ihre Erfahrung und Ihr Gespür, um zu bestimmen, wann Sie Ihr JS prefetchen. Guess.js enthält Tools, die Google Analytics-Daten verwenden, um zu bestimmen, welche Seite der Benutzer wahrscheinlich als nächstes besucht. Erwägen Sie Quicklink, Instant.page und DNStradamus. Hinweis: Es ist möglich, dass Sie dem Browser Anweisungen geben, unnötige Daten herunterzuladen und unnötige Seiten vorab zu laden. Wir empfehlen dringend, vorsichtig zu sein, was die Anzahl der vorab geladenen Anforderungen betrifft.

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

  Nutzen Sie script streaming für monolithische Skripte, damit sie sofort nach Beginn des Downloads in einem separaten Hintergrundthread geparst werden können. Aktivieren Sie auch code caching für die V8-Engine, indem Sie Bibliotheken vom Code trennen, der sie verwendet. Erwägen Sie auch JIT-Optimierungsstrategien für den Baseline Interpreter des Firefox-Browsers.

• Finden Sie einen Weg, um Client- und Server-Seiten-Rendering zu kombinieren.

  Ziel ist es in der Regel, das optimale Gleichgewicht zwischen clientseitigem und serverseitigem Rendering zu finden. Erwägen Sie das Prerendern, wenn sich Ihre Seiten nicht zu häufig ändern, und verschieben Sie das Booten von Frameworks wenn möglich. Streamen Sie HTML-Chunks mit serverseitigem Rendering und hydratisieren Sie erst bei Anzeige, Interaktion oder im Leerlauf, um das Beste aus beiden Welten zu erhalten. (Streaming Server-Side Rendering With Progressive Hydration).

• Erwägen Sie Mikrooptimierungen und progressives Booten.

  Verwenden Sie serverseitiges Rendern für schnelles „First Meaningful Paint“ (FMP), aber fügen Sie auch minimales JS hinzu, um „Time to Interactive“ (TTI) nahe am „First Meaningful Paint“ zu halten. Führen Sie dann auf Anforderung oder nach Verfügbarkeit unwesentliche 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 eher im Cache als Drittanbieter-Ressourcen. Eigenes Hosting ist zuverlässiger, sicherer und leistungsfähiger.

• Beschränken Sie den Einfluss von Drittanbieter-Skripten.

  Zu oft macht ein Drittanbieter-Skript den „langen Schwanz“ und verdirbt die Geschwindigkeit. Erwägen Sie die Verwendung von Service Workern, um Ressourcen mit einem Zeitlimit herunterzuladen. Setzen Sie Content Security Policy (CSP) ein, um den Einfluss von Drittanbieter-Skripten zu begrenzen, z.B. durch das Verbot des Herunterladens von Audio oder Video. Betten Sie Skripte in iframes ein, damit sie keinen Zugriff auf das DOM haben. Untersuchen Sie die Performance-Zusammenfassung auf der DevTools-Registerkarte für Belastungstests von Skripten. Laden Sie Drittanbieter-Skripte erst, wenn die Anwendung geladen ist. Konzentrieren Sie sich auf Code-Segmente, die das Vorblinken von Inhalten vor dem Laden des Skripts verhindern.

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

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

  Verwenden Sie cache-control: immutable, um eine Revalidierung zu verhindern. Stellen Sie sicher, dass Sie unnötige Header (z.B. x-powered-by, pragma, x- ua-compatible, expires) nicht senden. Nutzen Sie null RTT für wiederholte Anzeigen über 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. Verwenden Sie native Lazy-Loading (Attribute loading und importance) oder eine Lösung, die Intersection Observer verwendet. Die zweite Lösung können Sie auch für leistungsstarkes „Scrollytelling“ – Parallax-Effekt oder Werbeverfolgung verwenden.

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

  Mit der Eigenschaft content-visibility: auto können wir den Browser anweisen, das Rendering der Nachkommen eines Elements zu überspringen, wenn sich dieses außerhalb des Viewports befindet. Stellen Sie sicher, dass Sie die Eigenschaft contain-intrinsic-size mit einem geeigneten Platzhalter verwenden, um eine Verschlechterung der Metrik Cumulative Layout Shift (CLS) zu vermeiden. Verwenden Sie auch <img decoding="async">. Der Browser dekodiert das Bild dann außerhalb des Hauptthreads, was die für die Operation benötigte CPU-Zeit verkürzt.

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

  Entfernen Sie aus dem CSS alle Stile, die zum Rendern von im Viewport sichtbarem Inhalt erforderlich sind (sogenanntes kritisches CSS oder Above-the-Fold-CSS). Fügen Sie diese Stile als Inline in das <head>-Tag auf der Seite ein. Die goldene Regel ist, dass Sie insgesamt nicht mehr als 14 kB überschreiten sollten. Erwägen Sie die bedingte Einbettung von CSS auf der Seite. In einigen Fällen ist es besser, kritisches CSS in eine separate Datei im Root der Domain einzufügen. Aufgrund des Cachings kann diese Lösung besser sein als Inline-Stile.

• Experimentieren Sie mit der Neuanordnung von CSS-Dateien/Eigenschaften.

  Bei der Ladeoptimierung können Sie auch die Aufteilung des 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, erwägen Sie, blockierende Skripte über blockierenden Stilen zu platzieren. Wenn doch, teilen Sie dieses JavaScript in zwei Teile und laden Sie es sowohl vor als auch nach CSS-Dateien. Cachen Sie eingebettetes CSS mit Service Workern 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 CSS keine Abhängigkeiten vom Erscheinungsbild oder den Eigenschaften der Komponente hat, und komplizieren Sie Komponenten nicht (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 servieren und den Inhalt mit JavaScript zu füllen, verwenden Sie Service Worker, laden Sie das Skelett aus dem Cache und den Inhalt aus dem Netzwerk. HTML, das während der initialen Anfrage gerendert wird, kann dann den HTML-Parser des Browsers voll ausnutzen.

• Erwägen Sie die Anpassung Ihrer Komponenten an die Verbindung und den Speicher des Geräts.

  Verwenden Sie den client-hint-Header Save-Data und passen Sie die Anwendung an, indem Sie die Einschränkungen Ihrer Benutzer (Kosten, Leistung) in Betracht ziehen. Sie können Anforderungen für hochauflösende Bilder auf niedrige Auflösung umschreiben, Webfonts entfernen, Parallax deaktivieren, Autoplay von Videos deaktivieren oder sogar ändern, wie Sie Code bereitstellen. Nutzen Sie die Network Information API, um Varianten von ressourcenintensiven Komponenten basierend auf der Verbindung bereitzustellen, und die Device Memory API, um Ressourcen basierend auf dem Gerätespeicher anzupassen.

• Halten Sie eine konstante Verbindung aufrecht, um die Bereitstellung zu beschleunigen.

  Sparen Sie Zeit durch die Verwendung von resource hints; dns-prefetch (DNS-Lookup im Hintergrund), preconnect (Verbindungs-Handshake starten (DNS, TCP, TLS)), prefetch (Ressourcenanforderung), preload (Ressourcen vorladen, ohne sie auszuführen) und prerender (Ressourcen vorab laden, ohne JS auszuführen und ohne auf der Seite zu rendern). Beim Verwenden von preload muss as definiert sein, oder es wird nichts geladen. Das Vorladen von Schriftarten ohne crossorigin-Attribut führt zu einem doppelten Laden. Beim Verwenden von preload gibt es mehrere Prioritäten, daher erwägen Sie das Einfügen von rel=”preload”-Elementen in den DOM direkt vor externen blockierenden Skripten.

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

  Wenn Ihre Website auf HTTPS läuft, speichern Sie statische Ressourcen im Service Worker Cache und speichern Sie ein Offline-Fallback (oder sogar ganze Seiten) und laden Sie diese 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-Header in der Antwort 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 durch Service Worker direkt „am Rand“. Z.B. bei A/B-Tests, wenn HTML seinen Inhalt für verschiedene Benutzer ändern muss, verwenden Sie zur Verarbeitung der Logik Service Worker auf dem CDN.

  Beschleunigen Sie Websites, die Google Fonts verwenden, mit Stream HTML Rewriting.

• Optimieren Sie die Rendering-Performance.

  Isolieren Sie bei Bedarf teure Komponenten mithilfe von CSS containment. Stellen Sie sicher, dass beim Scrollen der Seite oder bei der Animation eines Elements keine Verzögerung auftritt und dass Sie dauerhaft eine Geschwindigkeit von 60 Bildern pro Sekunde erreichen. Wenn dies nicht möglich ist, streben Sie an, die Bildrate zumindest konstant zu halten. Eine minimale Wiederholungsrate von 15 Bildern pro Sekunde gilt allgemein als akzeptabel. Verwenden Sie CSS will-change, um den Browser über die Elemente zu informieren, die 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 flüssig ist, auch wenn im Hintergrund viel passiert. Um den Kunden zu fesseln, verwenden Sie „Skeletons“ anstelle von Laderädern und fügen Sie Übergänge und Animationen hinzu.

• Vermeiden Sie Layoutverschiebungen (reflow) und Neuzeichnungen (repaint).

  Layoutverschiebungen werden häufig durch das Ändern der Größe von Komponenten wie Videos und Bildern, das Nachladen von Webfonts, eingebettete Anzeigen oder das Nachladen von tatsächlichem Inhalt in Komponenten verursacht. Stellen Sie width und height bei Bildern ein, damit moderne Browser den benötigten Platz reservieren können. Verwenden Sie Platzhalter-SVGs, um ausreichend Platz zu reservieren, in dem sich Bilder oder Videos befinden. Verwenden Sie JavaScript-Lazy-Loading, wenn keine native Version für die Komponente verfügbar ist. Laden Sie JS-Lazy-Loading wirklich nur herunter, wenn es benötigt wird. Identifizieren Sie Layoutverschiebungen, die durch Webfonts verursacht werden, und vergleichen Sie die Zeilenhöhe und Abstände mithilfe von font-style-matcher. Verfolgen Sie die Layoutstabilität mithilfe der 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, Informationen über das Zertifikat Ihrer Domain zu suchen und herunterzuladen.

• Haben Sie den Einfluss der SSL-Zertifikatsrücknahme verringert?

  Extended Validation (EV) Zertifikate sind teuer und zeitaufwendig, da sie immer manuell überprüft werden müssen. Normale Domain Validation (DV) Zertifikate sind kostenlos verfügbar (Let’s Encrypt) und können einfach automatisiert ausgestellt und erneuert werden. EV-Zertifikate unterstützen zudem kein OCSP-Stapling, stellen Sie daher immer ein DV-Zertifikat mit aktiviertem Stapling bereit.

• Verwenden Sie IPv6?

  Studien zeigen, dass Websites bis zu 15 % schneller sind dank NDP (Neighbor Discovery Protocol) und Optimierung der Route. 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.

• Verwenden Sie TCP BBR?

  BBR ist ein relativ neuer Flusskontrollalgorithmus des TCP-Protokolls. Es reagiert eher auf tatsächliche Überlastung als auf Paketverlust, wie es TCP tut. Als solches ist es erheblich 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 ab Version 4.9 funktioniert.

• Bevorzugen Sie immer HTTP/2.

  HTTP/2 wird sehr gut unterstützt und bietet Geschwindigkeitssteigerungen. Je nachdem, wie groß Ihre mobile Nutzerbasis 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 das richtige Gleichgewicht zwischen dem Zusammenführen von Modulen zu einem und dem parallelen Laden vieler kleiner Module finden. Teilen Sie Ihr gesamtes Interface in viele kleine Module auf; dann gruppieren, komprimieren und bündeln Sie sie. Teilen Sie sie auf Paketebene oder durch Überwachung, welche CSS/JS-Blöcke nicht verwendet werden. Trennen Sie Drittanbieter-Code von Ihrem eigenen und trennen Sie Abhängigkeiten, die sich selten und häufig ändern. Das Senden von etwa 6–10 Bündeln von Frontend-Elementen scheint ein guter Kompromiss zu sein (und 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ützungsebene 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 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 zu detailliertes) Tool, um dies zu überprüfen.

• Bereiten Sie sich auf HTTP/3 vor.

  Bei HTTP/2 teilen sich mehrere Anfragen eine Verbindung. Bei HTTP/3 teilen sich auch Anfragen eine Verbindung, aber sie streamen unabhängig, sodass ein verworfenes Paket nicht mehr alle Anfragen beeinflusst, sondern nur einen Stream. Mit QUIC auf HTTP/3 sind TCP und TLS kombiniert und in einem einzigen „Round Trip“ ausgeführt. Ab der zweiten Verbindung können wir bereits Daten der Anwendungsschicht im ersten „Round Trip“ (0-RTT) senden und empfangen. Die Bündelung von Frontend-Elementen spielt weiterhin eine Rolle, also senden Sie anstelle eines monolithischen JS mehrere JS-Dateien parallel, wie auf HTTP/2. Erwarten Sie Auswirkungen von HTTP/3 auf Ladezeiten bei Mobilgeräten.

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

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

• Stellen Sie sicher, dass die Sicherheit auf Ihrem Server unverwüstlich ist.

  Überprüfen Sie, ob die Sicherheitsheader korrekt eingestellt sind, beseitigen Sie bekannte Sicherheitslücken und überprüfen Sie die HTTPS-Konfiguration. Stellen Sie sicher, dass alle externen Plugins und Tracking-Skripte über HTTPS geladen werden, dass Cross-Site-Scripting nicht möglich ist und dass die HTTP Strict Transport Security- und Content Security Policy-Header korrekt gesetzt sind.

• Überwachen Sie Warnungen zu gemischten Inhalten (mixed-content).

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

• Haben Sie Ihren Audit- und Debugging-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 von einem Google-Tabellenblatt ausführen und die Zugänglichkeits-, Performance- und SEO-Bewertungen in Ihrem Travis-Setup mit Lighthouse CI oder direkt in Webpack einbeziehen. Für schnelle Überprüfungen verwenden Sie CSS Perf Diagnostic.

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

  Tests in Chrome und Firefox reichen nicht aus. Sehen Sie, wie Ihre Website in Proxy-Browsern und älteren Browsern funktioniert (einschließlich UC Browser und Opera Mini). Messen Sie die durchschnittliche Internetgeschwindigkeit in Ihrer Benutzerbasis, um große Überraschungen zu vermeiden. Testen Sie mit Netzwerkeinschränkungen und emulieren Sie hochauflösende Geräte. 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 Webelement anfordert, das nicht existiert, erhält er eine 404-Antwort — und diese Antwort ist oft riesig. Vergessen Sie nicht, Ihre Caching-Strategie zu untersuchen und zu optimieren auch für Ihre 404-Seiten. Stellen Sie sicher, dass der Browser HTML nur anzeigt, wenn er eine HTML-Antwort erwartet, und geben Sie bei allen anderen Antworten eine Fehlerantwort zurück.

• Haben Sie die Leistungsauswirkungen Ihrer Datenschutz- und Cookie-Banner getestet?

  Normalerweise sollten Datenschutz- und Cookie-Banner keinen Einfluss auf CLS haben, aber manchmal kann es passieren, daher erwägen Sie die Verwendung freier und Open-Source-Ressourcen wie Osano oder cookie-consent-box. Die Zustimmung wird wahrscheinlich die Auswirkungen von Skripten auf die Gesamtleistung ändern, richten Sie daher verschiedene Profile für die Überprüfung der Website-Leistung für verschiedene Zustimmungstypen ein und studieren Sie sie.

• Haben Sie die Auswirkungen auf die Barrierefreiheit getestet?

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

• Ist kontinuierliches Monitoring eingerichtet?

  Gute Geschwindigkeitsmetriken entstehen durch die Kombination passiver und aktiver Überwachungstools. Eine private WebPagetest-Instanz und die Verwendung von Lighthouse sind immer vorteilhaft für schnelle Tests, aber auch die Einrichtung eines kontinuierlichen Monitorings mit RUM-Tools wie SpeedTracker, SpeedCurve und anderen. Richten Sie Ihre eigenen User-Timing-Marken ein, um spezifische Metriken Ihrer Website zu messen und zu überwachen.

Die Checkliste für Webgeschwindigkeit ist ziemlich umfassend und es kann eine Weile dauern, alle Optimierungen abzuschließen. Wenn Sie also nur 1 Stunde hätten, um signifikante Verbesserungen zu erzielen, was würden Sie tun? Wir fassen alles auf 18 leicht erreichbare Erfolge zusammen. Natürlich gilt, dass Sie vor dem Start und nach Abschluss die Ergebnisse messen sollten, einschließlich der Metriken Largest Contentful Paint und Time To Interactive auf 3G und auch bei Kabelverbindung.

• Messen Sie die Geschwindigkeit zwischen echten Nutzern und setzen Sie geeignete Ziele. Streben Sie an, mindestens 20 % schneller zu sein als Ihr schnellster Mitbewerber. Halten Sie Largest Contentful Paint unter 2,5 s, First Input Delay unter 100 ms, Time to Interactive unter 5 Sekunden auf langsamem 3G, bei wiederholten Besuchen 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 liefern Sie AVIF/WebP mit einem Bild-CDN aus.
• Bereiten Sie kritisches CSS für Ihre Hauptvorlagen vor und betten Sie es inline in das <head> jeder von ihnen ein. Setzen Sie für CSS und JS ein Budget für die Größe kritischer Dateien von maximal 170 kB nach Gzip (0,7 MB entpackt).
• Schneiden, optimieren, verzögern und lazy laden Sie Skripte. Investieren Sie in die Konfiguration Ihres Bundlers, um Redundanz zu beseitigen, und schauen Sie nach weniger datenintensiven Alternativen.
• Hosten Sie statische Frontend-Dateien immer auf Ihrer eigenen Domain. Bevorzugen Sie auch das Hosting von Drittanbieter-Komponenten auf Ihrer eigenen Domain. Begrenzen Sie deren Einfluss. Verwenden Sie Fassaden und Platzhalter, laden Sie Widgets bei Interaktion und achten Sie auf das Vorblinken der Originalversion.
• Seien Sie anspruchsvoll bei der Auswahl des Frameworks. Bei Single Page Applications (SPA) identifizieren Sie kritische Seiten und rendern Sie diese statisch oder zumindest vor. Verwenden Sie progressive Hydration auf Komponentenebene und importieren Sie Module bei Interaktion.
• Client-Side-Only-Rendering ist keine gute Wahl für die Leistung. Prerendern Sie, wenn sich Ihre Seiten nicht zu häufig ändern, und verschieben Sie das Booten von Frameworks. Verwenden Sie Streaming-Rendering auf der Serverseite (SSR).
• Liefern Sie älteren Code nur an ältere Browser mit dem Designmuster module/nomodule.
• Experimentieren Sie mit der Neuanordnung von CSS-Regeln und testen Sie CSS, das direkt in HTML bereitgestellt wird.
• Fügen Sie Ressourcentipps (resource hints) hinzu, um die Bereitstellung durch DNS-Lookup, Preconnect, Prefetch, Preload, Prerender zu beschleunigen.
• Subsetten Sie Webfonts und laden Sie sie asynchron, verwenden Sie font-display in CSS für schnelles erstes Rendering.
• Überprüfen Sie, ob die HTTP-Cache- und Sicherheitsheader korrekt eingestellt sind.
• Aktivieren Sie die Brotli-Komprimierung auf dem Server. (Wenn das nicht möglich ist, vergessen Sie nicht, die Gzip-Komprimierung zu aktivieren.)
• Aktivieren Sie die TCP-Flusskontrolle mit BBR, wenn Ihr Server auf einem Linux-Kernel ab Version 4.9 läuft.
• Aktivieren Sie, wenn möglich, OCSP-Stapling und IPv6. Liefern Sie immer ein DV-Zertifikat mit OCSP.
• Aktivieren Sie die HPACK-Kompression für HTTP/2 und migrieren Sie zu HTTP/3, wenn verfügbar.
• Cachen Sie Elemente wie Schriftarten, Stile, JavaScript und Bilder im Service Worker Cache.
• Erkunden Sie Möglichkeiten, um Rehydratation zu vermeiden, verwenden Sie für Ihre Single Page Application (SPA) progressive Hydration und Server-Side-Streaming.

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