Suche nach Möglichkeiten zur Verbesserung der Nutzererfahrung mit den Webtools von Chrome.
Veröffentlicht: 11. Mai 2021
Heute stellen wir neue Tools in Lighthouse, PageSpeed und DevTools vor, mit denen Sie herausfinden können, wie Sie die Web Vitals Ihrer Website verbessern können.
Zur Erinnerung: Lighthouse ist ein automatisiertes Open-Source-Tool zur Verbesserung der Qualität von Webseiten. Sie finden es in den Chrome-Entwicklertools und können es auf jede Webseite anwenden, unabhängig davon, ob sie öffentlich ist oder eine Authentifizierung erfordert. Lighthouse ist auch in PageSpeed Insights, CI und WebPageTest verfügbar.
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.
Außerdem wird in PageSpeed Insights jetzt die Möglichkeit unterstützt, Element-Screenshots zu erstellen. So lassen sich Probleme bei einmaligen Leistungstests von Seiten leichter erkennen.
Core Web Vitals messen
Lighthouse kann die Core Web Vitals-Messwerte, einschließlich Largest Contentful Paint, Cumulative Layout Shift und Total Blocking Time (ein Lab-Proxy für First Input Delay), synthetisch messen. Diese Messwerte geben Aufschluss über das Laden, die Layoutstabilität und die Interaktionsbereitschaft. Auch andere Messwerte wie First Contentful Paint, die in der Zukunft von Core Web Vitals hervorgehoben werden, sind enthalten.
Der Abschnitt „Messwerte“ im Lighthouse-Bericht enthält Lab-Versionen dieser Messwerte. Sie können diese Liste als Zusammenfassung verwenden, um zu sehen, auf welche Aspekte der User Experience Sie sich konzentrieren müssen.
Feldmesswerte wie die im Chrome UX Report oder RUM enthaltenen sind davon nicht betroffen und ergänzen Labordaten sinnvoll, da sie die Erfahrungen echter Nutzer widerspiegeln. Felddaten sind nicht in der Lage, die Diagnoseinformationen zu liefern, die im Labor zur Verfügung stehen. Daher gehen beide Hand in Hand.
Verbesserungsmöglichkeiten bei den Web Vitals ermitteln
Largest Contentful Paint-Element ermitteln
Der LCP ist ein Messwert für die wahrgenommene Ladezeit. Er kennzeichnet den Punkt während des Seitenaufbaus, an dem der primäre (oder „größte“) Inhalt geladen wurde und für den Nutzer sichtbar ist.
Lighthouse bietet eine Prüfung für das Largest Contentful Paint-Element, mit der Sie ermitteln können, welches Element das größte Inhaltselement ist. Wenn Sie den Mauszeiger auf das Element bewegen, wird es im Hauptbrowserfenster markiert.
Wenn es sich bei diesem Element um ein Bild handelt, ist dies ein nützlicher Hinweis, dass Sie das Laden dieses Bildes optimieren sollten. 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äter erkannte 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 gefunden werden kann.
Es gibt einige häufig gestellte Fragen zum Vorladen von LCP-Bildern, die wir kurz beantworten möchten.
Kann ich responsive Bilder vorladen? 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 wie bei 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 für das Vorabladen hervorgehoben, wenn das LCP-Bild über einen CSS-Hintergrund definiert wird? Ja.
Jedes Bild, das als LCP-Bild gekennzeichnet ist, sei es über einen CSS-Hintergrund oder <img>, ist ein Kandidat, wenn es bei einer Abfolgetiefe von drei oder mehr gefunden wird.
Lazy Loading von nicht sichtbaren Bildern und Vermeidung dieses Vorgangs für den LCP
Bilder, die sich außerhalb des sichtbaren Bereichs befinden und für die Nutzerfreundlichkeit nicht unbedingt erforderlich sind, können lazy-loaded 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:
Wichtige Bilder, die ohne Scrollen sichtbar sind, wie das Largest Contentful Paint-Bild, sollten nicht mit Lazy Loading geladen werden. Dadurch kann sich das Laden des LCP-Bilds verzögern. Lighthouse weist über die Prüfung „Largest Contentful Paint-Bild wurde mit Lazy Loading geladen“ darauf hin, wenn ein LCP-Bild falsch mit Lazy Loading geladen wird:
CLS-Beiträge identifizieren
„Cumulative Layout Shift“ ist ein Messwert für die visuelle Stabilität. Er gibt an, wie stark sich der Inhalt einer Seite optisch verschiebt. Lighthouse bietet eine Prüfung zum Entfernen von CLS-Fehlern namens „Große Layoutverschiebungen vermeiden“.
Bei dieser Prüfung werden DOM-Elemente hervorgehoben, die am stärksten zu Verschiebungen der Seite beitragen. In der Spalte „Element“ auf der linken Seite sehen Sie eine Liste dieser DOM-Elemente und rechts ihren Gesamtbeitrag zur CLS.
Dank der neuen Funktion „Lighthouse-Screenshots“ können wir eine visuelle Vorschau der wichtigsten Elemente in der Prüfung sehen. Außerdem können wir durch Klicken auf die Schaltfläche zum Zoomen eine bessere Übersicht erhalten:
Bei der CLS nach dem Laden kann es sinnvoll sein, mit Rechtecken dauerhaft zu visualisieren, welche Elemente am stärksten zum 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:
Für einen vollständigen Überblick über Probleme mit Layoutverschiebungen nutze ich den Core Web Vitals-Bericht der Search Console. So kann ich die Seiten auf meiner Website mit einem hohen CLS sehen. In diesem Fall kann ich selbst ermitteln, für welche Vorlagen-Teile ich meine Zeit aufwenden muss:
CLS anhand von Bildern ohne Abmessungen ermitteln
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. So kann der Browser während des Ladens des Bildes den richtigen Platz im Dokument zuweisen.
Unter Höhe und Breite für Bilder festlegen finden Sie nützliche Informationen dazu, wie wichtig es ist, die Bildabmessungen und das Seitenverhältnis zu berücksichtigen.
CLS aus Anzeigen ermitteln
Mit Publisher-Anzeigen für Lighthouse können Sie Möglichkeiten zur Verbesserung des Anzeigenladevorgangs auf Ihrer Seite finden. Dazu gehören auch Faktoren, die zu Layoutänderungen und langen Aufgaben führen, die die Verfügbarkeit Ihrer Seite für Nutzer verzögern können. 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
- Vermeiden Sie Verschiebungen, indem Sie die größtmögliche Größe für den Anzeigenblock reservieren.
Nicht zusammengesetzte Animationen vermeiden
Nicht zusammengesetzte Animationen können auf Geräten mit geringerer Leistung ruckelig erscheinen, wenn der Hauptthread durch umfangreiche JavaScript-Aufgaben ausgelastet ist. Solche Animationen können Layout Shifts zur Folge haben.
Wenn Chrome feststellt, dass eine Animation nicht zusammengesetzt werden konnte, wird dies in einem DevTools-Trace protokolliert, den Lighthouse liest. So kann aufgelistet werden, welche Elemente mit Animationen nicht zusammengesetzt wurden und warum. Sie finden diese im Audit Nicht zusammengesetzte Animationen vermeiden.
Debug First Input Delay / Total Blocking Time / Long Tasks (Gesamte Blockierzeit)
„First Input“ gibt an, wie lange es ab dem Moment, an dem ein Nutzer das erste Mal mit einer Seite interagiert, dauert, bis der Browser diese Interaktion verarbeitet. Eine Interaktion findet beispielsweise statt, wenn der Nutzer auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes JavaScript-Steuerelement verwendet. Lange JavaScript-Aufgaben können sich auf diesen Messwert und den Proxy für diesen Messwert, die Gesamtblockierungszeit, auswirken.
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 der Scripts, die für lange Aufgaben im Haupt-Thread verantwortlich sind.
Rechts sehen wir die Dauer dieser Aufgaben. Zur Erinnerung: Langzeitaufgaben sind Aufgaben, die länger als 50 Millisekunden ausgeführt werden. Dadurch wird der Haupt-Thread so lange blockiert, dass die Framerate oder die Eingabelatenz beeinträchtigt wird.
Wenn Sie Drittanbieterdienste zur Überwachung in Betracht ziehen, gefällt mir auch die Zeitachse für die Ausführung des Hauptthreads in Calibre, mit der diese Kosten visualisiert werden. Dabei werden sowohl übergeordnete als auch untergeordnete Aufgaben hervorgehoben, die zu langen Aufgaben beitragen, die sich auf die Interaktivität auswirken.
Netzwerkanfragen blockieren, um die Auswirkungen vor und nach der Optimierung 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. So können Sie die Auswirkungen einzelner Scripts (z. B. von Drittanbieter-Embeds oder -Trackern) auf Messwerte wie die Blockierungszeit insgesamt (Total Blocking Time, TBT) und die interaktive Ladezeit besser nachvollziehen.
Die Blockierung der Netzwerkanfrage funktioniert übrigens auch mit Lighthouse. Sehen wir uns kurz den Lighthouse-Bericht für eine Website an. Der Perf-Wert beträgt 63/100 bei 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. Lass uns das blockieren.
Wir können im Bereich „Netzwerk“ der Entwicklertools mit der rechten Maustaste auf ein Script klicken und dann auf Block Request URL, um es zu blockieren. Hier machen wir das für die Intersection Observer-Polyfill.
Als Nächstes können wir Lighthouse noch einmal ausführen. Diesmal hat sich unsere Leistungsbewertung verbessert (70/100), da sich die Gesamtblockierungszeit (400 ms => 300 ms) verringert hat.
Kostenintensive 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 eingebetteten Inhalte sofort geladen und können mit kostspieligen Nutzlasten verbunden sein, die sich negativ auf die Nutzerfreundlichkeit auswirken. Das ist verschwenderisch, wenn der Drittanbieter nicht kritisch ist (z.B. wenn der Nutzer scrollen muss, um ihn zu sehen).
Ein Muster zur Verbesserung der Leistung solcher Widgets ist das Lazy Loading bei Nutzerinteraktion. Dazu wird eine schlanke Vorschau des Widgets (eine Fassade) gerendert und die Vollversion nur geladen, wenn ein Nutzer damit interagiert. Lighthouse bietet eine Prüfung, bei der Drittanbieterressourcen empfohlen werden, die mit einer Fassade per Lazy Load geladen werden können, z. B. eingebettete YouTube-Videos.
Zur Erinnerung: Lighthouse markiert Code von Drittanbietern, der den Haupt-Thread länger als 250 ms blockiert. Dadurch können alle Arten von Drittanbieter-Scripts (einschließlich von Google erstellter Scripts) sichtbar werden, die besser verschoben oder verzögert geladen werden sollten, wenn zum Ansehen des gerenderten Inhalts gescrollt werden muss.
Mehr als nur Core Web Vitals
Neben den Core Web Vitals bieten die neuesten Versionen von Lighthouse und PageSpeed Insights auch konkrete Anleitungen, wie Sie die Ladegeschwindigkeit von JavaScript-lastigen Webanwendungen verbessern können, wenn Sie Quellkarten aktiviert haben.
Dazu gehört eine wachsende Sammlung von Prüfungen zur Senkung der JavaScript-Kosten auf Ihrer Seite, z. B. weniger Abhängigkeit von Polyfills und Duplikaten, die für die Nutzerfreundlichkeit möglicherweise nicht erforderlich sind.
Weitere Informationen zu Core Web Vitals-Tools finden Sie im Twitter-Konto des Lighthouse-Teams und unter Neue Funktionen in DevTools.
Hero-Image von Mercedes Mehling auf Unsplash