Website Performance Optimierung: Pagespeed

Front-End-Leistungs-Checkliste 2020
Nachfolgend finden Sie eine Übersicht über die Front-End-Performance-Probleme, die Sie möglicherweise berücksichtigen müssen, um schnelle und reibungslose Antwortzeiten zu gewährleisten.
____

Planung und Metriken

    • Etablieren Sie eine Leistungskultur.

      Solange es kein Buy-in der Unternehmen gibt, kann die Leistung nicht langfristig aufrechterhalten werden. Untersuchen Sie häufige Beschwerden, die beim Kundendienst eingehen, und finden Sie heraus, wie die Verbesserung der Leistung dazu beitragen kann, einige dieser Probleme zu lösen. Erstellen Sie eine auf das Unternehmen zugeschnittene Fallstudie mit echten Daten und Geschäftskennzahlen. Planen Sie eine Ladereihenfolge und Kompromisse während des Designprozesses.

    • Seien Sie 20 % schneller als Ihr schnellster Mitbewerber.

      Sammeln Sie Daten auf einem für Ihre Zielgruppe repräsentativen Gerät. Bevorzugen Sie reale Geräte gegenüber Simulationen. Wählen Sie ein Moto G4/G5 Plus, ein Samsung-Gerät der Mittelklasse (Galaxy A50, S8), ein gutes Gerät der Mittelklasse wie einen 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 Erfahrungen auf dem Desktop emulieren, indem Sie auf einem gedrosselten Netzwerk (z.B. 300ms RTT, 1,6 Mbps unten, 0,8 Mbps oben) mit einer gedrosselten CPU (5× Verlangsamung) testen. Dann wechseln Sie zu regulärem 3G, langsamem 4G (z.B. 170ms RTT, 9 Mbps abwärts, 9 Mbps aufwärts) und Wi-Fi. Sammeln Sie Daten, erstellen Sie eine Tabellenkalkulation, rasieren Sie 20% ab und legen Sie Ihre Ziele (Leistungsbudgets) fest.

    • Wählen Sie die richtigen Metriken.

      Nicht jede Metrik ist gleich wichtig. Untersuchen Sie, welche Metriken am wichtigsten sind: Gewöhnlich hängt es davon ab, wie schnell Sie mit dem Rendern der wichtigsten Pixel beginnen können und wie schnell Sie auf Eingaben reagieren können. Priorisieren Sie das Laden von Seiten so, wie es von Ihren Kunden wahrgenommen wird. Die Zeit bis zur Interaktivität, die erste Eingabeverzögerung, die Renderingzeiten des Helden, der größte zufriedenstellende Farbauftrag, die Gesamtblockierungszeit, die kumulative Layoutverschiebung und der Geschwindigkeitsindex spielen normalerweise eine Rolle.

    • Richten Sie „saubere“ und „Kunden“-Profile für Tests ein.

      Schalten Sie Anti-Virus und Hintergrund-CPU-Aufgaben ab, entfernen Sie Bandbreitenübertragungen im Hintergrund und testen Sie mit einem sauberen Benutzerprofil ohne Browser-Erweiterungen, um verzerrte Ergebnisse zu vermeiden. Untersuchen Sie, welche Erweiterungen Ihre Kunden verwenden, und testen Sie auch mit einem speziellen „Kunden“-Profil.

    • Geben Sie die Checkliste an Ihre Kollegen weiter.

      Stellen Sie sicher, dass die Checkliste jedem Mitglied Ihres Teams bekannt ist. Jede Entscheidung hat Auswirkungen auf die Leistung, und es wäre für Ihr Projekt von großem Vorteil, die Verantwortung auf das gesamte Team zu verteilen. Ordnen Sie Designentscheidungen dem Leistungsbudget zu.

Realistische Ziele setzen

      • 100 Millisekunden Reaktionszeit, 60 Bilder pro Sekunde.

        Jedes Einzelbild der Animation sollte in weniger als 16 Millisekunden idealerweise 10 Millisekunden abgeschlossen sein, wodurch 60 Bilder pro Sekunde (1 Sekunde ÷ 60 = 16,6 Millisekunden) erreicht werden. Seien Sie optimistisch und nutzen Sie die ungenutzte Zeit weise. Für Punkte mit hohem Druck wie die Animation ist es am besten, nichts anderes zu tun, wo es möglich ist, und das absolute Minimum, wo es nicht möglich ist. Die geschätzte Input-Latenzzeit sollte unter 50 ms liegen. Nutzen Sie die Leerlaufzeit vernünftig mit dem Ansatz „Leerlauf bis zur Dringlichkeit“.

      • FID < 100ms, Time-To-Interactive < 5s bei 3G.

        Wenn man als Ausgangsbasis ein Android-Telefon im Wert von 200 USD auf einem langsamen 3G-Telefon, emuliert mit 400 ms RTT und 400 kbps Übertragungsgeschwindigkeit, nimmt man an, dass die Time-to-Interactive-Zeit < 5 s und für wiederholte Besuche unter 2-3 s liegt. Angestrebt wird ein größtmöglicher Contentful Paint von unter 1s und eine Minimierung der Gesamtblockierungszeit und der kumulativen Layoutverschiebung. Bemühen Sie sich, diese Werte so niedrig wie möglich zu halten.

      • Kritisches Budget für Dateigrößen < 170 KB Die ersten 14-16 KB des HTML-Dokuments sind der kritischste Teil der Nutzlast und der einzige Teil des Budgets, der im ersten Roundtrip geliefert werden kann. Um die oben genannten Ziele zu erreichen, sollten Sie sich an ein kritisches Dateigrößen-Budget von max. 170KB gzipped (0,7-0,8MB dekomprimiert. Stellen Sie sicher, dass sich Ihre Budgets je nach Netzwerkbedingungen und Hardwarebeschränkungen ändern.

Definieren der Umgebung

      • Wählen Sie Ihre Build-Tools aus und richten Sie sie ein.

        Achten Sie nicht so sehr darauf, was angeblich cool ist. Solange Sie schnell Ergebnisse erzielen und keine Probleme haben, Ihren Build-Prozess aufrechtzuerhalten, sind Sie gut unterwegs. Die einzige Ausnahme könnte Webpack sein, das viele nützliche Optimierungstechniken wie Code-Splitting bietet. Wenn es noch nicht in Gebrauch ist, sollten Sie sich im Detail mit Code-Splitting und Tree-shaking beschäftigen.

      • Verwenden Sie standardmäßig die progressive Verbesserung.

        Entwerfen und erstellen Sie zunächst das Kernerlebnis, und verbessern Sie dann das Erlebnis mit erweiterten Funktionen für fähige Browser, um ein belastbares Erlebnis zu schaffen. Wenn Ihre Website auf einem langsamen Rechner mit einem schlechten Bildschirm in einem schlechten Browser in einem suboptimalen Netzwerk schnell läuft, wird sie nur auf einem schnellen Rechner mit einem guten Browser in einem anständigen Netzwerk schneller laufen.

      • Wählen Sie eine starke Leistungsbasis.

        JavaScript hat die höchsten Kosten für die Erfahrung. Bei einem Budget von 170 KB, das bereits HTML/CSS/JavaScript für den kritischen Pfad, Router, Statusverwaltung, Dienstprogramme, Framework und die Anwendungslogik enthält, sollten Sie die Netzwerkübertragungskosten, die Parse-/Kompilierzeit und die Laufzeitkosten für das Framework unserer Wahl gründlich prüfen.

      • Bewerten Sie jedes Framework und jede Abhängigkeit.

        Nicht jedes Projekt benötigt ein Framework, nicht jede Seite einer SPA muss das Framework laden. Seien Sie bei Ihren Entscheidungen überlegt. Bewerten Sie JS von Drittanbietern, indem Sie Funktionen, Zugänglichkeit, Stabilität, Leistung, Paket-Ökosystem, Gemeinschaft, Lernkurve, Dokumentation, Werkzeuge, Erfolgsbilanz, Team, Kompatibilität und Sicherheit untersuchen. Gatsby (React), Vuepress (Vue) und Preact CLI bieten vernünftige Standardeinstellungen für das schnelle Laden out of the box auf durchschnittlicher mobiler Hardware.

      • Wählen Sie Ihre Kämpfe mit Bedacht: React, Vue, Angular, Ember und Co.

        Stellen Sie sicher, dass das Framework Ihrer Wahl serverseitiges Rendering bietet. Stellen Sie sicher, dass Sie die Bootzeiten im Server und Client-Rendering-Modus auf mobilen Geräten messen, bevor Sie sich für ein Framework entscheiden. Verstehen Sie die Schrauben und Muttern des Frameworks, auf das Sie sich verlassen werden. Informieren Sie sich über das PRPL-Muster und die Shell-Architektur der Anwendung.

      • Optimieren Sie die Leistung Ihrer APIs.

        Wenn viele Ressourcen Daten von einer API benötigen, kann die API zu einem Leistungsengpass werden. Erwägen Sie die Verwendung von GraphQL, einer Abfragesprache und einer serverseitigen Laufzeit zur Ausführung von Abfragen unter Verwendung eines von Ihnen für Ihre Daten definierten Typensystems. Im Gegensatz zu REST kann GraphQL alle Daten in einer einzigen Anfrage abrufen, ohne dass Daten über oder untermäßig abgerufen werden, wie es bei REST typischerweise geschieht.

      • Werden Sie AMP oder Instant Articles verwenden?

        Sie können auch ohne sie eine gute Leistung erzielen, aber AMP könnte mit einem kostenlosen CDN einen soliden Leistungsrahmen bieten, während Instant Articles Ihre Sichtbarkeit und Leistung auf Facebook steigern wird. Sie könnten auch progressive Web-AMPs erstellen.

      • Wählen Sie Ihr CDN mit Bedacht.

        Je nachdem, wie viele dynamische Daten Sie haben, können Sie möglicherweise einen Teil des Inhalts an einen statischen Website-Generator „auslagern“, ihn in ein CDN schieben und von dort aus eine statische Version bereitstellen und so Datenbankanforderungen (JAMStack) vermeiden. Vergewissern Sie sich, dass Ihr CDN Inhaltskomprimierung und -konvertierung (z.B. Bildoptimierung in Bezug auf Formate, Komprimierung und Größenänderung am Rand), Unterstützung für Serverarbeiter und Edge-Side-Includes für Sie durchführt.

Asset-Optimierungen

      • Verwenden Sie Brotli für die Komprimierung von reinem Text.

        Brotli, ein neues verlustfreies Datenformat, wird jetzt in allen modernen Browsern unterstützt. Es ist effektiver als Gzip und Deflate, komprimiert sehr langsam, dekomprimiert aber schnell. Statische Assets werden mit Brotli+Gzip auf der höchsten Stufe vorkomprimiert, (dynamisches) HTML wird mit Brotli auf Stufe 1-4 on the fly komprimiert. Prüfen Sie auch bei CDNs auf Brotli-Unterstützung. Stellen Sie sicher, dass der Server die Inhaltsaushandlung für Brotli oder gzip korrekt handhabt.

      • Verwenden Sie reaktionsfähige Bilder und WebP.

        Verwenden Sie, soweit möglich, responsive Bilder mit srcset, Größen und dem Element . Verwenden Sie das WebP-Format, indem Sie WebP-Bilder mit und einem JPEG-Fallback bereitstellen oder indem Sie die Inhaltsaushandlung verwenden (unter Verwendung von Accept-Headern). Hinweis: Mit WebP verringern Sie die Nutzlast, aber mit JPEG verbessern Sie die wahrgenommene Leistung, so dass die Benutzer ein tatsächliches Bild mit einem guten alten JPEG schneller sehen können, obwohl WebP-Bilder schneller durch das Netzwerk gelangen.

      • Sind Bilder richtig optimiert?

        Verwenden Sie mozJPEG für die JPEG-Komprimierung, SVGO für die SVG-Komprimierung, Pingo für PNGs oder Squoosh für alle. Um die Effizienz Ihres Response-Markups zu überprüfen, können Sie Imaging-Heap verwenden. Verwenden Sie für kritische Bilder progressive JPEGs und verwischen Sie unnötige Teile (durch Anwendung eines Gaußschen Weichzeichnungsfilters) und entfernen Sie den Kontrast (Sie können ihn mit CSS-Filtern erneut anwenden). Stellen Sie sicher, dass Breite und Höhe für alle Bilder definiert sind, fügen Sie eine automatische Bildkomprimierung zu Ihren Pull-Anforderungen hinzu und schauen Sie sich weniger kritische Bilder an, die zu langsam geladen werden.

      • Sind Videos richtig optimiert?

        Verwenden Sie anstelle von animierten GIFs entweder animiertes WebP (wobei GIF ein Fallback ist) oder inline HTML5-Videos in Schleifen. Stellen Sie sicher, dass Ihre MP4s mit einer Multipasskodierung verarbeitet, mit dem frei0r-Iirblur-Effekt (falls zutreffend) verwischt und Moov-Atom-Metadaten an den Anfang der Datei verschoben werden, während Ihr Server Byte-Serving akzeptiert. Seien Sie auf das AV1-Format vorbereitet, das gute Chancen hat, der ultimative Standard für Video im Web zu werden.

      • Sind Web-Schriftarten optimiert?

        Die Chancen stehen gut, dass die Web-Schriftarten, die Sie bereitstellen, Glyphen und zusätzliche Funktionen enthalten, die nicht wirklich genutzt werden. Unterteilen Sie die Schriftarten. Bevorzugen Sie WOFF2 und verwenden Sie WOFF als Ausweichlösung. Zeigen Sie den Inhalt in den Ersatzschriftarten sofort an, laden Sie die Schriftarten asynchron und wechseln Sie dann die Schriftarten in dieser Reihenfolge. Endgültige Lösung: zweistufiges Rendern, zunächst mit einem kleinen Supersubset, und der Rest der Familie wird später asynchron geladen. Laden Sie 1-2 Schriftarten jeder Familie vor. Vermeiden Sie den local()-Wert für Schriftartendeklarationen, sondern berücksichtigen Sie lokal installierte OS-Schriftarten. Vergessen Sie nicht, font-display: optional einzuschließen, und verwenden Sie Font Load Events für Gruppen-Neuzeichnungen. Verwenden Sie Web Font Reflow Count und Time To Real Kursiv-Metriken.

Build-Optimierungen

      • Setzen Sie Ihre Prioritäten richtig.

        Führen Sie eine Bestandsaufnahme all Ihrer Assets durch (JavaScript, Bilder, Schriften, Skripte von Drittanbietern, „teure“ Module auf der Seite), und gliedern Sie sie in Gruppen auf. Definieren Sie die grundlegende Kern-Erfahrung (vollständig zugängliche Kerninhalte für ältere Browser), die erweiterte Erfahrung (eine angereicherte, vollständige Erfahrung für fähige Browser) und die Extras (Assets, die nicht unbedingt benötigt werden und die sich faul laden lassen).

      • Verwendung nativer JavaScript-Module in der Produktion.

        Übertragen Sie die Kern-Erfahrung auf ältere Browser und eine verbesserte Erfahrung auf moderne Browser. Verwenden Sie ES2015+