Suche nach Möglichkeiten zur Verbesserung der Nutzererfahrung mit den Webtools von Chrome.
Heute stellen wir neue Tool-Funktionen in Lighthouse, PageSpeed und in den Entwicklertools vor, mit denen ihr herausfinden könnt, wie eure Website im Hinblick auf die Web Vitals verbessert werden kann.
Zur Erinnerung: Lighthouse ist ein automatisiertes Open-Source-Tool zur Verbesserung der Qualität von Webseiten. Sie finden sie in den Debugging-Tools der Chrome DevTools. Sie können sie für jede beliebige Webseite ausführen, die öffentlich ist oder für die eine Authentifizierung erforderlich ist. Sie finden Lighthouse auch unter PageSpeed Insights, CI und WebPageTest.
Lighthouse 7.x enthält neue Funktionen wie Element-Screenshots, mit denen sich Teile der UI, die sich auf die Nutzererfahrung auswirken (z.B. welche Knoten zu Layout Shifts beitragen) leichter visuell überprüfen lassen.
In PageSpeed Insights unterstützen wir auch Screenshots von Elementen, sodass Sie Probleme bei einmaligen Leistungsläufen von Seiten einfacher erkennen können.
Core Web Vitals messen
Lighthouse kann synthetisch die Core Web Vitals-Messwerte wie Largest Contentful Paint, Cumulative Layout Shift und Total Blocking Time (ein Lab-Proxy für First Input Delay) messen. Diese Messwerte spiegeln das Laden, die Layoutstabilität und die Bereitschaft der Interaktion wider. Auch andere Messwerte wie First Contentful Paint, die in der Zukunft von Core Web Vitals vorgestellt werden, sind ebenfalls verfügbar.
Der Abschnitt „Messwerte“ des Lighthouse-Berichts enthält Lab-Versionen dieser Messwerte. Sie können hier eine Zusammenfassung der Aspekte der User Experience verwenden, die Ihre Aufmerksamkeit erfordern.
Feldmesswerte wie die im Chrome UX Report oder in RUM enthalten keine Einschränkung. Sie sind eine wertvolle Ergänzung zu Labdaten, da sie die Erfahrungen echter Nutzer widerspiegeln. Felddaten liefern nicht die Diagnoseinformationen, die Sie im Labor erhalten. Daher gehen beide Hand in Hand.
Ermitteln, wo Web Vitals-Werte verbessert werden können
Largest Contentful Paint-Element identifizieren
Der LCP ist ein Maß für die wahrgenommene Ladeerfahrung. Sie markiert den Punkt während des Seitenaufbaus, wenn der primäre oder „größte“ Inhalt geladen wurde und für den Nutzer sichtbar ist.
Lighthouse hat den Audit „Largest Contentful Paint-Element“, mit dem ermittelt wird, welches Element das Largest Contentful Paint war. Wenn Sie den Mauszeiger auf das Element bewegen, wird es im Hauptbrowserfenster markiert.
Wenn dieses Element ein Bild ist, sind diese Informationen ein nützlicher Hinweis für Sie, wenn Sie das Laden des Bildes optimieren möchten. Lighthouse umfasst eine Reihe von Prüfungen zur Bildoptimierung, mit denen Sie feststellen können, ob Ihre Bilder besser komprimiert, in ihrer Größe angepasst oder in einem optimaleren, modernen Bildformat bereitgestellt werden könnten.
Vielleicht finden Sie auch das LCP Bookmarklet von Annie Sullivan, das nützlich ist, um das LCP-Element mit nur einem Klick in einem roten Rechteck zu identifizieren.
Spät entdeckte Bilder vorab laden, um den LCP zu verbessern
Zur Verbesserung von Largest Contentful Paint sollten Sie Ihre kritischen Hero-Images vorab laden, wenn sie zu spät vom Browser entdeckt 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 zum Vorabladen von LCP-Bildern, die auch kurz erläutert werden sollten.
Können responsive Bilder vorab geladen werden? Ja.
Angenommen, 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, die auch von srcset und sizes verwendet wird, 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 für das Vorabladen hervorgehoben, wenn das LCP-Bild über einen 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 Bildern, die nicht auf dem Bildschirm zu sehen sind und dies für den LCP vermeiden
Nicht sichtbare Bilder, die für die anfängliche Nutzererfahrung nicht entscheidend sind, können per Lazy-Loading geladen werden. Mit dieser Technik wird der Download eines Bildes verzögert, bis der Nutzer in dessen Nähe scrollt. Dadurch werden Netzwerkkonflikte um wichtige Assets reduziert und in einigen Fällen der LCP verbessert. Die Prüfung Nicht sichtbare Bilder zurückstellen kann hier Abhilfe schaffen:
Kritische „above the fold“-Bilder wie „Largest Contentful Paint“ sollten nicht per Lazy Loading geladen werden. Andernfalls kann sich das Laden des LCP-Bilds verzögern. In Lighthouse wird bei der Prüfung „Largest Contentful Paint-Bild wurde mit Lazy Loading geladen“ angegeben, ob ein LCP-Bild fälschlicherweise per Lazy Loading geladen wird:
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 verändert. Lighthouse hat eine Prüfung 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 Lighthouse-Element-Screenshots sehen wir sowohl eine visuelle Vorschau der wichtigsten Elemente der Prüfung als auch durch Klicken zum Zoomen ein klareres Bild:
Für CLS nach dem Laden kann die permanente Visualisierung mit Rechtecken nützlich sein, welche Elemente am meisten zu CLS beigetragen haben. Diese Funktion findet ihr in Drittanbietertools wie dem Core Web Vitals-Dashboard von SpeedCurve und ich verwende gern den Layout Shift GIF Generator von Defaced für:
Der Core Web Vitals-Bericht der Search Console liefert mir einen umfassenden Überblick über Probleme mit Layoutverschiebungen. So kann ich sehen, welche Arten von Seiten auf meiner Website mit einem hohen CLS-Wert vorliegen (in diesem Fall kann ich selbst ermitteln, in welche Vorlagenteile ich meine Zeit investieren muss):
CLS bei Bildern ohne Abmessungen identifizieren
Wenn Sie den Cumulative Layout Shift einschränken möchten, der durch Bilder ohne Abmessungen verursacht wird, fügen Sie den Bildern und Videoelementen die Attribute für Breite und Höhe hinzu. Dieser Ansatz stellt sicher, dass der Browser den richtigen Speicherplatz im Dokument zuteilen kann, während das Bild geladen wird.
Unter Wie gesagt: Höhe und Breite für Bilder festlegen finden Sie einen guten Beitrag darüber, wie wichtig es ist, die Bildabmessungen und das Seitenverhältnis zu berücksichtigen.
CLS in Anzeigen identifizieren
Mit Publisher Ads for Lighthouse können Sie Möglichkeiten ermitteln, wie Sie das Laden von Anzeigen auf Ihrer Seite verbessern können. Dazu gehören zum Beispiel Beiträge zu Layoutverschiebungen und langwierige Aufgaben, die sich darauf auswirken, wie schnell Ihre Seite von Nutzern verwendet werden kann. In Lighthouse können Sie dies über Community-Plug-ins aktivieren.
Anzeigen sind einer der größten Anteile an Layout Shifts im Web. Folgendes ist wichtig:
- Vorsicht beim Platzieren nicht fixierter Anzeigen im oberen Bereich des Darstellungsbereichs
- Verschiebungen werden vermieden, indem die größtmögliche Größe für die Anzeigenfläche reserviert wird.
Nicht zusammengesetzte Animationen vermeiden
Nicht zusammengesetzte Animationen können auf Low-End-Geräten als instabile Animationen angezeigt werden, wenn der Hauptthread durch umfangreiche JavaScript-Aufgaben überlastet ist. Solche Animationen können Layout Shifts zur Folge haben.
Wenn Chrome feststellt, dass eine Animation nicht zusammengesetzt werden konnte, wird sie an ein Entwicklertools-Trace mit Lighthouse-Lesevorgängen gemeldet. So kann aufgelistet werden, welche Elemente mit Animationen aus welchem Grund nicht zusammengesetzt wurden. Sie finden diese im Audit Nicht zusammengesetzte Animationen vermeiden.
Debug First Input Delay / Total Blocking Time / Long Tasks (Gesamte Blockierzeit)
„First Input“ misst die Zeit von 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, an dem der Browser tatsächlich mit der Verarbeitung von Event-Handlern als Reaktion auf diese Interaktion beginnen kann. Lange JavaScript-Aufgaben können sich auf diesen Messwert und den Proxy für diesen Messwert auswirken: Gesamtblockierungszeit.
Lighthouse umfasst die Prüfung Lange Hauptthreadaufgaben vermeiden, in der die längsten Aufgaben im Hauptthread aufgelistet werden. Dies kann hilfreich sein, um die Hauptursachen für die Eingabeverzögerung zu ermitteln. In der linken Spalte sehen wir die URL von Skripts, die für lange Hauptthread-Aufgaben zuständig sind.
Rechts sehen Sie die Dauer dieser Aufgaben. Zur Erinnerung: Lange Aufgaben sind Aufgaben, die länger als 50 Millisekunden ausgeführt werden. Es wird davon ausgegangen, dass dadurch der Hauptthread so lange blockiert wird, dass sich dies auf die Framerate oder Eingabelatenz auswirkt.
Wenn Drittanbieterdienste für das Monitoring in Betracht ziehen, gefällt mir auch die Zeitleiste der Hauptthreadausführung, die Calibre zur Visualisierung dieser Kosten zur Verfügung stellt. Hier werden sowohl übergeordnete als auch untergeordnete Aufgaben hervorgehoben, die zu langen Aufgaben beitragen, die sich auf die Interaktivität auswirken.
Netzwerkanfragen blockieren, um die Vorher/Nachher-Auswirkungen in Lighthouse zu sehen
Die Chrome-Entwicklertools unterstützen das Blockieren von Netzwerkanfragen, um zu sehen, welche Auswirkungen es hat, wenn einzelne Ressourcen entfernt werden oder nicht verfügbar sind. Dies kann hilfreich sein, um die Kosten zu verstehen, die einzelne Skripts (z. B. Einbettungen oder Tracker von Drittanbietern) für Messwerte wie „Total Blocking Time“ (TBT) und „Time to Interactive“ haben.
Die Blockierung von Netzwerkanfragen funktioniert auch mit Lighthouse. Sehen wir uns kurz den Lighthouse-Bericht für eine Website an. Die Leistungsbewertung liegt bei 63/100 mit einer TBT von 400 ms. Wir sehen uns den Code genauer an und stellen fest, dass diese Website ein Intersection Observer-Polyfill in Chrome lädt, was nicht erforderlich ist. Dann blockieren wir sie!
Wir können in den Entwicklertools im Bereich „Netzwerk“ mit der rechten Maustaste auf ein Script und dann auf Block Request URL klicken, um es zu blockieren. Jetzt machen wir das für den Intersection-Observer-Polyfill.
Jetzt können wir Lighthouse noch einmal ausführen. Dieses Mal sehen wir, dass sich unsere Leistungsbewertung verbessert hat (70/100) und die Gesamtblockierungszeit (400 ms => 300 ms) liegt.
Kostspielige Einbettungen von Drittanbietern durch eine Fassade ersetzen
Häufig werden Ressourcen von Drittanbietern 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 Nutzerfreundlichkeit auswirken. Das ist Verschwendung, 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 kann eine einfache Vorschau des Widgets (eine Fassade) gerendert werden, wobei die Vollversion nur geladen wird, wenn ein Nutzer damit interagiert. In Lighthouse werden Ressourcen von Drittanbietern empfohlen, die lazy-Loading mit einer Fassade verwendet werden können, z. B. YouTube-Videoeinbettungen.
Zur Erinnerung: In Lighthouse wird Drittanbietercode hervorgehoben, der den Hauptthread länger als 250 ms blockiert. Dadurch können alle Arten von Drittanbieterskripts (auch solche, die von Google erstellt wurden) verfügbar gemacht werden, die sich besser auf ein Verzögerungs- oder Lazy Loading auswirken könnten, wenn zum Ansehen der gerenderte Inhalt Scrollen erforderlich ist.
Mehr als Core Web Vitals
Neben der Hervorhebung der Core Web Vitals bieten aktuelle Versionen von Lighthouse und PageSpeed Insights auch konkrete Hinweise, wie Sie die Geschwindigkeit von JavaScript-lastigen Webanwendungen verbessern können, wenn Sie Quellzuordnungen aktiviert haben.
Dazu gehört eine wachsende Sammlung von Prüfungen zur Senkung der JavaScript-Kosten auf Ihrer Seite, z. B. die Abhängigkeit von Polyfills und Duplikaten, die für die Nutzerfreundlichkeit möglicherweise nicht erforderlich sind.
Weitere Informationen zu den Core Web Vitals-Tools findest du im Twitter-Konto des Lighthouse-Teams und unter Neuerungen bei den Entwicklertools.
Hero-Image von Mercedes Mehling auf Unsplash