Möglichkeiten zur Verbesserung der Nutzererfahrung mit den Webtools von Chrome
Heute geht es um neue Toolfunktionen in Lighthouse, PageSpeed und DevTools, mit denen ihr herausfinden könnt, wie eure Website die Web Vitals verbessern kann.
Zur Erinnerung: Lighthouse ist ein automatisiertes Open-Source-Tool zur Verbesserung der Qualität von Webseiten. Sie finden sie in der Suite der Chrome-Entwicklertools zur Fehlerbehebung und können sie auf jeder Webseite ausführen, ob öffentlich oder, für die eine Authentifizierung erforderlich ist. Sie finden Lighthouse auch in PageSpeed Insights, CI und WebPageTest.
Lighthouse 7.x enthält neue Funktionen wie Element-Screenshots, die die visuelle Prüfung von Teilen Ihrer UI erleichtern, die sich auf Messwerte zur Nutzerfreundlichkeit auswirken (z.B. welche Knoten zur Layoutverschiebung beitragen).
PageSpeed Insights bietet außerdem Unterstützung für Element-Screenshots. So lassen sich Probleme bei einmaligen Leistungsläufen von Seiten leichter erkennen.
Core Web Vitals messen
Lighthouse kann die Core Web Vitals-Messwerte synthetisch messen, darunter Largest Contentful Paint, Cumulative Layout Shift und Total Blocking Time (ein Lab-Proxy für First Input Delay). Diese Messwerte spiegeln die Ladezeiten, die Layoutstabilität und die Interaktionsbereitschaft wider. Andere Messwerte wie First Contentful Paint, die wir in zukünftigen Core Web Vitals vorstellen, werden ebenfalls berücksichtigt.
Der Bereich „Messwerte“ des Lighthouse-Berichts enthält Lab-Versionen dieser Messwerte. Sie können dies als Zusammenfassung verwenden, um zu sehen, welche Aspekte der User Experience Ihre Aufmerksamkeit erfordern.
Feldmesswerte, wie sie im UX-Bericht von Chrome oder RUM zu finden sind, unterliegen dieser Einschränkung nicht und sind eine wertvolle Ergänzung zu den Labordaten, da sie die Erfahrung realer Nutzer widerspiegeln. Felddaten bieten nicht die Art von Diagnosedaten, die Sie im Labor erhalten, daher gehen die beiden Hand in Hand.
Verbesserungsmöglichkeiten für Web Vitals ermitteln
Das Largest Contentful Paint-Element ermitteln
Der LCP steht für die wahrgenommene Ladeerfahrung. Sie kennzeichnet den Punkt beim Seitenaufbau, an dem der primäre oder der „größte“ Inhalt geladen wurde und für den Nutzer sichtbar ist.
Lighthouse hat die Prüfung „Largest Contentful Paint“, mit der ermittelt wird, welches Element der Largest Contentful Paint war. Wenn Sie mit der Maus auf das Element zeigen, wird es im Browser-Hauptfenster hervorgehoben.
Wenn dieses Element ein Bild ist, sind diese Informationen ein nützlicher Hinweis darauf, dass Sie das Laden dieses Bildes optimieren können. Lighthouse umfasst eine Reihe von Bildoptimierungsprüfungen, mit denen Sie herausfinden können, ob Ihre Bilder besser komprimiert, in der Größe angepasst oder in einem optimalen modernen Bildformat bereitgestellt werden können.
Vielleicht finden Sie auch das LCP Bookmarklet von Annie Sulivan nützlich, um das LCP-Element mit einem roten Rechteck mit nur einem Klick schnell zu identifizieren.
Später erkannte Bilder vorab laden, um den LCP zu verbessern
Wenn Sie den Largest Contentful Paint verbessern möchten, laden Sie wichtige Hero-Images vorab, wenn sie vom Browser erst spät erkannt werden. Eine späte Erkennung kann auftreten, wenn ein JavaScript-Bundle geladen werden muss, bevor das Bild sichtbar ist.
Es gibt einige häufig gestellte Fragen, die uns zum Vorabladen von LCP-Bildern gestellt werden und die möglicherweise auch kurz behandelt werden sollten.
Können responsive Bilder vorab geladen werden? Ja.
Nehmen wir an, Sie haben ein responsives Hero-Image, wie unten mit srcset und sizes angegeben:
<img src="lighthouse.jpg"
srcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">
Dank der Attribute imagesrcset und imagesizes, die dem Attribut link hinzugefügt wurden, können wir ein responsives Bild mit derselben Bildauswahllogik wie srcset und sizes vorab laden:
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">
Werden bei der Prüfung auch Möglichkeiten zum Vorabladen hervorgehoben, wenn das LCP-Bild über den CSS-Hintergrund definiert wird? Ja.
Jedes Bild, das über den CSS-Hintergrund oder <img> als LCP-Bild gekennzeichnet ist, kommt infrage, wenn es in einer Wasserfalltiefe von drei oder mehr erkannt wird.
Lazy Loading von nicht sichtbaren Bildern und Vermeidung des LCP-Werts
Nicht sichtbare Bilder, die für die Nutzerfreundlichkeit nicht entscheidend sind, können Lazy-Loading aufweisen. Bei dieser Methode wird der Download eines Bildes verzögert, bis der Nutzer in dessen Nähe scrollt. Dadurch können Netzwerkkonflikte für kritische Assets reduziert und in einigen Fällen der LCP-Wert verbessert werden. Die Prüfung Nicht sichtbare Bilder verschieben kann hier Abhilfe schaffen:
Für wichtige Bilder, die ohne Scrollen sichtbar sind, z. B. das Largest Contentful Paint-Bild, sollte kein Lazy Loading verwendet werden. Andernfalls kann es zu Verzögerungen beim Laden des LCP-Bilds kommen. Lighthouse zeigt bei der Prüfung "Largest Contentful Paint-Bild mit Lazy Loading" falsch geladene LCP-Bilder an:
CLS-Beiträge identifizieren
Cumulative Layout Shift ist ein Maß für die visuelle Stabilität. Sie gibt an, wie stark sich der Inhalt einer Seite visuell bewegt. Lighthouse bietet ein Audit zum Debuggen von CLS mit dem Namen „Große Layoutverschiebungen vermeiden“.
Bei dieser Prüfung werden DOM-Elemente hervorgehoben, die am meisten zu Verschiebungen der Seite beitragen. In der Spalte „Element“ auf der linken Seite sehen Sie die Liste dieser DOM-Elemente und rechts ihren CLS-Gesamtbeitrag.
Dank der neuen Funktion für Screenshots von Lighthouse-Elementen können wir sowohl eine visuelle Vorschau der wichtigsten Elemente sehen, die im Audit erfasst wurden, als auch durch Klicken zum Zoomen die Ansicht übersichtlicher gestalten:
Für CLS nach dem Laden kann eine dauerhafte Visualisierung mit Rechtecken hilfreich sein, welche Elemente am meisten zum CLS beigetragen haben. Diese Funktion findest du in Tools von Drittanbietern wie dem Core Web Vitals-Dashboard von SpeedCurve. Ich liebe es, den Defaced's Layout Shift GIF Generator für Folgendes zu verwenden:
Für eine websiteweite Ansicht von Problemen mit Layout Shifts ist der Core Web Vitals-Bericht der Search Console sehr hilfreich. Dadurch kann ich die Arten von Seiten meiner Website mit einem hohen CLS sehen (in diesem Fall kann ich selbst herausfinden, mit welchen Vorlagenbereichen ich meine Zeit verbringen muss):
CLS aus Bildern ohne Abmessungen erkennen
Sie können die Cumulative Layout Shift beschränken, die durch Bilder ohne Abmessungen verursacht wird. Fügen Sie dafür Breiten- und Höhenattribute für Bilder und Videoelemente ein. Dadurch wird sichergestellt, dass der Browser während des Ladens des Bildes die richtige Menge an Platz im Dokument zuweisen kann.
Unter Höhe und Breite von Bildern ist wieder wichtig finden Sie eine gute Zusammenfassung der Bedeutung von Bildabmessungen und -seitenverhältnis.
CLS aus Anzeigen erkennen
Mit Publisher Ads for Lighthouse können Sie herausfinden, wie sich die Ladezeit von Anzeigen auf Ihrer Seite verbessern lässt. Dazu gehören beispielsweise Beiträge zum Layout Shift und umfangreiche Aufgaben, die festlegen, wie schnell Ihre Seite von Nutzern verwendet werden kann. In Lighthouse können Sie dies über Community-Plug-ins aktivieren.
Denken Sie daran, dass Anzeigen einer der größten Bestandteile von Layoutverschiebungen im Web sind. Folgendes ist wichtig:
- Vorsicht beim Platzieren von nicht fixierten Anzeigen oben im Darstellungsbereich
- Eliminieren von Verschiebungen, indem die größtmögliche Größe für die Anzeigenfläche reserviert wird
Vermeiden Sie nicht zusammengesetzte Animationen
Nicht zusammengesetzte Animationen können auf Low-End-Geräten unregelmäßig werden, wenn der Hauptthread aufgrund von umfangreichen JavaScript-Aufgaben nicht ausgeführt wird. Solche Animationen können zu Layoutverschiebungen führen.
Wenn Chrome feststellt, dass eine Animation nicht zusammengesetzt werden konnte, wird sie an ein Entwicklertools-Trace von Lighthouse gemeldet. So kann aufgelistet werden, welche Elemente mit Animationen aus welchem Grund nicht zusammengesetzt wurden. Sie finden diese im Audit-Log Nicht zusammengesetzte Animationen vermeiden.
Fehlerbehebung bei First Input Delay / Total Blocking Time / Long Tasks
Die erste Eingabe misst die Zeit ab der ersten Interaktion eines Nutzers mit einer Seite (z.B. wenn er auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes JavaScript-Steuerelement verwendet) bis zu dem Zeitpunkt, zu dem der Browser als Reaktion auf diese Interaktion mit der Verarbeitung von Event-Handlern beginnen kann. Lange JavaScript-Aufgaben können sich auf diesen Messwert und den Proxy für diesen Messwert, die gesamte Blockierzeit, auswirken.
Lighthouse enthält die Prüfung Lange Aufgaben des Hauptthreads vermeiden, in der die längsten Aufgaben im Hauptthread aufgeführt werden. Dies kann hilfreich sein, um die Hauptursachen für die Eingabeverzögerung zu finden. In der linken Spalte sehen Sie die URL der Skripts, die für lange Hauptthread-Aufgaben zuständig sind.
Rechts sehen wir die Dauer dieser Aufgaben. Zur Erinnerung: Lange Aufgaben sind Aufgaben, die länger als 50 Millisekunden ausgeführt werden. Dies wird davon ausgegangen, dass der Hauptthread lange genug blockiert wird, um sich auf die Framerate oder die Eingabelatenz zu auswirken.
Wenn Sie Drittanbieterdienste für das Monitoring in Betracht ziehen, gefällt mir auch die Zeitachse für die Ausführung des Hauptthreads in Calibre zur Visualisierung dieser Kosten. Hier werden sowohl übergeordnete als auch untergeordnete Aufgaben hervorgehoben, die zu langen Aufgaben führen, die sich auf die Interaktivität auswirken.
Du kannst Netzwerkanfragen blockieren, um die Auswirkungen vor und nach den Auswirkungen in Lighthouse zu sehen
Die Chrome-Entwicklertools unterstützen das Blockieren von Netzwerkanfragen, um die Auswirkungen einzelner Ressourcen zu sehen, die entfernt wurden oder nicht verfügbar sind. Dies kann hilfreich sein, um die Kosten einzelner Skripts (z. B. Einbettungen von Drittanbietern oder Trackern) für Messwerte wie Gesamtblockzeit (Total Blocking Time, TBT) und Zeit bis Interaktivität zu verstehen.
Das Blockieren von Netzwerkanfragen funktioniert auch mit Lighthouse. Sehen wir uns kurz den Lighthouse-Bericht für eine Website an. Die Leistungsbewertung liegt bei 63/100 bei einer TBT von 400 ms. Im Code wird auf dieser Website ein nicht erforderlicher Intersection Observer-Polyfill in Chrome geladen. Dann blockieren wir es!
Wir können im Netzwerkbereich der Entwicklertools mit der rechten Maustaste auf ein Skript und dann auf Block Request URL klicken, um es zu blockieren. Hier verwenden wir den Intersection Observer-Polyfill.
Als Nächstes können wir Lighthouse noch einmal ausführen. Dieses Mal sehen wir, dass sich unsere Leistungsbewertung verbessert hat (70/100), da die gesamte Blockierzeit (400 ms => 300 ms) vorhanden ist.
Kostspielige Einbettungen von Drittanbietern durch eine Fassade ersetzen
Häufig werden Drittanbieterressourcen verwendet, um Videos, Beiträge in sozialen Medien oder Widgets in Seiten einzubetten. Standardmäßig werden die meisten Einbettungen sofort geladen und können kostspielige Nutzlasten enthalten, die sich negativ auf die Nutzererfahrung auswirken. Das ist verschwenderisch, wenn der Drittanbieter nicht kritisch ist (z.B. wenn der Nutzer scrollen muss, bevor er es sieht).
Ein Muster zur Verbesserung der Leistung solcher Widgets ist das Lazy Loading bei Nutzerinteraktion. Dazu wird eine einfache Vorschau des Widgets (eine Fassade) gerendert und die Vollversion nur geladen, wenn ein Nutzer damit interagiert. In Lighthouse wird ein Audit durchgeführt, bei dem Ressourcen von Drittanbietern empfohlen werden, die mit einer Fassade Lazy Loading geladen werden können, z. B. YouTube-Videoeinbettungen.
Zur Erinnerung: Lighthouse hebt Drittanbietercode hervor, der den Hauptthread länger als 250 ms blockiert. Dadurch können alle Arten von Drittanbieterskripts sichtbar gemacht werden (einschließlich von Google verfasster Skripts), deren Darstellung sich besser aufsetzen oder Lazy Loading lohnen würde, wenn für das Rendern gescrollt werden muss, um es zu sehen.
Über die Core Web Vitals hinaus
Neben den Core Web Vitals bieten die neuesten Versionen von Lighthouse und PageSpeed Insights auch konkrete Hinweise dazu, wie Sie die Ladezeit von JavaScript-lastigen Webanwendungen verbessern können, wenn Sie Source Maps aktiviert haben.
Dazu gehören eine wachsende Anzahl von Prüfungen zur Reduzierung der Kosten für JavaScript auf Ihrer Seite, z. B. zur Reduzierung der Abhängigkeit von Polyfills und Duplikaten, die für die Nutzererfahrung möglicherweise nicht erforderlich sind.
Weitere Informationen zu den Core Web Vitals-Tools finden Sie im Twitter-Konto des Lighthouse-Teams und unter Neues in den Entwicklertools.
Hero-Image von Mercedes Mehling auf Unsplash