Front-End-Leistung 2021: Testen und Überwachen

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Machen wir 2021 … schnell! Eine jährliche Front-End-Performance-Checkliste mit allem, was Sie wissen müssen, um heute schnelle Erfahrungen im Web zu erstellen, von Metriken über Tools bis hin zu Front-End-Techniken. Aktualisiert seit 2016.

Inhaltsverzeichnis

  1. Vorbereitung: Planung und Metriken
  2. Realistische Ziele setzen
  3. Die Umgebung definieren
  4. Asset-Optimierungen
  5. Build-Optimierungen
  6. Lieferoptimierungen
  7. Netzwerk, HTTP/2, HTTP/3
  8. Testen und Überwachen
  9. Schnelle Gewinne
  10. Alles auf einer Seite
  11. Checkliste herunterladen (PDF, Apple Pages, MS Word)
  12. Abonnieren Sie unseren E-Mail-Newsletter, um die nächsten Anleitungen nicht zu verpassen.

Testen und Überwachen

  1. Haben Sie Ihren Revisionsworkflow optimiert?
    Es mag nicht nach einer großen Sache klingen, aber wenn Sie die richtigen Einstellungen zur Hand haben, können Sie beim Testen einiges an Zeit sparen. Erwägen Sie die Verwendung des Alfred-Workflows von Tim Kadlec für WebPageTest, um einen Test an die öffentliche Instanz von WebPageTest zu senden. Tatsächlich hat WebPageTest viele obskure Funktionen, also nehmen Sie sich die Zeit, um zu lernen, wie man ein WebPageTest Waterfall View-Diagramm liest und wie man ein WebPageTest Connection View-Diagramm liest, um Leistungsprobleme schneller zu diagnostizieren und zu lösen.

    Sie können WebPageTest auch von einer Google-Tabelle aus steuern und Zugänglichkeits-, Leistungs- und SEO-Ergebnisse in Ihr Travis-Setup mit Lighthouse CI oder direkt in Webpack integrieren.

    Werfen Sie einen Blick auf das kürzlich veröffentlichte AutoWebPerf, ein modulares Tool, das die automatische Erfassung von Leistungsdaten aus mehreren Quellen ermöglicht. Beispielsweise könnten wir einen täglichen Test auf Ihren kritischen Seiten einrichten, um die Felddaten aus der CrUX-API und Labordaten aus einem Lighthouse-Bericht von PageSpeed ​​Insights zu erfassen.

    Und wenn Sie etwas schnell debuggen müssen, Ihr Build-Prozess jedoch bemerkenswert langsam zu sein scheint, denken Sie daran, dass „das Entfernen von Leerzeichen und das Verstümmeln von Symbolen 95 % der Größenreduzierung im minimierten Code für die meisten JavaScript ausmachen – nicht aufwändige Codetransformationen. Sie können Deaktivieren Sie einfach die Komprimierung, um Uglify-Builds um das 3- bis 4-fache zu beschleunigen."

Ein Screenshot der Pull-Request-Benachrichtigung von GitHub, die besagt, dass eine Überprüfung erforderlich ist und dass das Zusammenführen blockiert ist, bis die Überprüfungen erfolgreich gelöst wurden
Die Integration von Zugänglichkeits-, Leistungs- und SEO-Scores in Ihr Travis-Setup mit Lighthouse CI wird die Leistungsauswirkung einer neuen Funktion für alle beitragenden Entwickler hervorheben. (Bildquelle) (Große Vorschau)
  1. Haben Sie in Proxy-Browsern und Legacy-Browsern getestet?
    Das Testen in Chrome und Firefox reicht nicht aus. Sehen Sie sich an, wie Ihre Website in Proxy-Browsern und älteren Browsern funktioniert. UC Browser und Opera Mini haben beispielsweise einen bedeutenden Marktanteil in Asien (bis zu 35 % in Asien). Messen Sie die durchschnittliche Internetgeschwindigkeit in Ihren Interessensländern, um später große Überraschungen zu vermeiden. Testen Sie mit Netzwerkdrosselung und emulieren Sie ein Gerät mit hoher DPI. BrowserStack eignet sich hervorragend zum Testen auf realen Remote- Geräten und ergänzt es mit mindestens ein paar echten Geräten in Ihrem Büro – es lohnt sich.
  1. Haben Sie die Leistung Ihrer 404-Seiten getestet?
    Normalerweise denken wir nicht lange nach, wenn es um 404-Seiten geht. Wenn ein Client eine Seite anfordert, die auf dem Server nicht vorhanden ist, antwortet der Server schließlich mit einem 404-Statuscode und der zugehörigen 404-Seite. Da ist nicht so viel dran, oder?

    Ein wichtiger Aspekt von 404-Antworten ist die tatsächliche Größe des Antworttexts , die an den Browser gesendet wird. Laut der 404-Seiten-Recherche von Matt Hobbs stammt die überwiegende Mehrheit der 404-Antworten von fehlenden Favicons, WordPress-Upload-Anfragen, defekten JavaScript-Anfragen, Manifest-Dateien sowie CSS- und Schriftdateien. Jedes Mal, wenn ein Kunde ein Asset anfordert, das nicht existiert, erhält er eine 404-Antwort – und oft ist diese Antwort riesig.

    Achten Sie darauf, die Caching-Strategie für Ihre 404-Seiten zu prüfen und zu optimieren. Unser Ziel ist es, dem Browser HTML nur dann bereitzustellen, wenn er eine HTML-Antwort erwartet, und für alle anderen Antworten eine kleine Fehlernutzlast zurückzugeben. Laut Matt „haben wir die Möglichkeit, die 404-Seiten-Antwort auf dem CDN zwischenzuspeichern, wenn wir ein CDN vor unserem Ursprung platzieren den Ursprungsserver zwingen, auf jede 404-Anfrage zu antworten, anstatt das CDN mit einer zwischengespeicherten Version antworten zu lassen."

    404-Fehler können nicht nur Ihre Leistung beeinträchtigen, sondern auch Traffic kosten. Daher ist es eine gute Idee, eine 404-Fehlerseite in Ihre Lighthouse-Testsuite aufzunehmen und deren Punktzahl im Laufe der Zeit zu verfolgen.

  2. Haben Sie die Leistung Ihrer DSGVO-Zustimmungsaufforderungen getestet?
    In Zeiten von GDPR und CCPA ist es üblich geworden, sich auf Drittanbieter zu verlassen, um Optionen für EU-Kunden bereitzustellen, um sich für das Tracking zu entscheiden oder es abzulehnen. Wie bei jedem anderen Skript von Drittanbietern kann ihre Leistung jedoch einen ziemlich verheerenden Einfluss auf den gesamten Leistungsaufwand haben.

    Natürlich wird die tatsächliche Zustimmung wahrscheinlich die Auswirkungen von Skripten auf die Gesamtleistung ändern, also sollten wir, wie Boris Schapira bemerkte, ein paar verschiedene Webleistungsprofile untersuchen:

    • Die Zustimmung wurde vollständig verweigert,
    • Die Zustimmung wurde teilweise verweigert,
    • Die Zustimmung wurde vollständig erteilt.
    • Der Benutzer hat nicht auf die Einwilligungsaufforderung reagiert (oder die Aufforderung wurde von einem Inhaltsblocker blockiert),

    Normalerweise sollten Cookie-Zustimmungsaufforderungen keinen Einfluss auf CLS haben, aber manchmal tun sie das, also erwägen Sie die Verwendung der kostenlosen und Open-Source-Optionen Osano oder cookie-consent-box.

    Im Allgemeinen lohnt es sich, die Popup-Performance zu untersuchen, da Sie den horizontalen oder vertikalen Offset des Mausereignisses bestimmen und das Popup relativ zum Anker richtig positionieren müssen. Noam Rosenthal teilt die Erkenntnisse des Wikimedia-Teams im Artikel Web performance case study: Wikipedia page previews (auch als Video und Protokoll verfügbar).

  3. Führen Sie ein Leistungsdiagnose-CSS?
    Obwohl wir alle Arten von Überprüfungen einschließen können, um sicherzustellen, dass nicht performanter Code bereitgestellt wird, ist es oft nützlich, sich einen schnellen Überblick über einige der niedrig hängenden Früchte zu verschaffen, die leicht gelöst werden könnten. Dafür könnten wir das brillante Performance Diagnostics CSS von Tim Kadlec verwenden (inspiriert von Harry Roberts 'Snippet, das verzögert geladene Bilder, Bilder ohne Größe, Bilder im Legacy-Format und synchrone Skripte hervorhebt.

    Sie möchten zB sicherstellen, dass keine Bilder "above the fold" geladen werden. Sie können das Snippet an Ihre Bedürfnisse anpassen, z. B. um nicht verwendete Webfonts hervorzuheben oder Icon-Fonts zu erkennen. Ein großartiges kleines Tool, um sicherzustellen, dass Fehler beim Debuggen sichtbar sind, oder um das aktuelle Projekt sehr schnell zu prüfen.

    /* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
  1. Haben Sie die Auswirkungen auf die Zugänglichkeit getestet?
    Wenn der Browser mit dem Laden einer Seite beginnt, erstellt er ein DOM, und wenn eine unterstützende Technologie wie ein Screenreader ausgeführt wird, erstellt er auch einen Barrierefreiheitsbaum. Der Bildschirmleser muss dann den Barrierefreiheitsbaum abfragen, um die Informationen abzurufen und sie dem Benutzer zur Verfügung zu stellen – manchmal standardmäßig und manchmal bei Bedarf. Und manchmal braucht es Zeit.

    Wenn wir von schneller Time to Interactive sprechen, meinen wir normalerweise einen Indikator dafür, wie schnell ein Benutzer mit der Seite interagieren kann, indem er auf Links und Schaltflächen klickt oder tippt. Bei Screenreadern ist der Kontext etwas anders. In diesem Fall bedeutet schnelle Interaktivität, wie viel Zeit vergeht, bis der Screenreader die Navigation auf einer bestimmten Seite ankündigen kann und ein Screenreader-Benutzer tatsächlich die Tastatur drücken kann, um zu interagieren.

    Leonie Watson hat einen aufschlussreichen Vortrag über die Leistung der Barrierefreiheit und insbesondere über die Auswirkungen langsamer Ladevorgänge auf Verzögerungen bei der Ankündigung von Screenreadern gehalten. Screenreader sind an schnelle Ansagen und schnelle Navigation gewöhnt und daher möglicherweise noch weniger geduldig als sehende Benutzer.

    Große Seiten und DOM-Manipulationen mit JavaScript führen zu Verzögerungen bei Screenreader-Ankündigungen. Ein ziemlich unerforschter Bereich, der etwas Aufmerksamkeit und Tests gebrauchen könnte, da Screenreader auf buchstäblich jeder Plattform verfügbar sind (Jaws, NVDA, Voiceover, Narrator, Orca).

  2. Ist eine kontinuierliche Überwachung eingerichtet?
    Eine private Instanz von WebPagetest ist für schnelle und unbegrenzte Tests immer von Vorteil. Ein kontinuierliches Überwachungstool – wie Sitespeed, Calibre und SpeedCurve – mit automatischen Benachrichtigungen gibt Ihnen jedoch ein detaillierteres Bild Ihrer Leistung. Legen Sie Ihre eigenen Benutzer-Timing-Marken fest, um geschäftsspezifische Metriken zu messen und zu überwachen. Erwägen Sie auch das Hinzufügen automatisierter Leistungsregressionswarnungen, um Änderungen im Laufe der Zeit zu überwachen.

    Erwägen Sie die Verwendung von RUM-Lösungen, um Leistungsänderungen im Laufe der Zeit zu überwachen. Für automatisierte Unit-Test-ähnliche Lasttest-Tools können Sie k6 mit seiner Skript-API verwenden. Schauen Sie sich auch SpeedTracker, Lighthouse und Calibre an.

Inhaltsverzeichnis

  1. Vorbereitung: Planung und Metriken
  2. Realistische Ziele setzen
  3. Die Umgebung definieren
  4. Asset-Optimierungen
  5. Build-Optimierungen
  6. Lieferoptimierungen
  7. Netzwerk, HTTP/2, HTTP/3
  8. Testen und Überwachen
  9. Schnelle Gewinne
  10. Alles auf einer Seite
  11. Checkliste herunterladen (PDF, Apple Pages, MS Word)
  12. Abonnieren Sie unseren E-Mail-Newsletter, um die nächsten Anleitungen nicht zu verpassen.