Möglichkeiten zur Verbesserung der Nutzerfreundlichkeit mit den Webtools von Chrome finden
Veröffentlicht: 11. Mai 2021
Heute stellen wir neue Toolfunktionen in Lighthouse, PageSpeed und den DevTools vor, mit denen ihr herausfinden könnt, wie ihr eure Website im Hinblick auf die Web Vitals verbessern könnt.
Zur Erinnerung: Lighthouse ist ein automatisiertes Open-Source-Tool zum Verbessern der Qualität von Webseiten. Ihr findet es in der Debugging-Tool-Suite Chrome-Entwicklertools und könnt es für jede Webseite ausführen, egal ob öffentlich oder mit Authentifizierung. 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 Benutzeroberfläche, die sich auf die Messwerte zur Nutzerfreundlichkeit auswirken, leichter visuell prüfen lassen (z.B. welche Knoten zur Layoutverschiebung beitragen).
Außerdem haben wir die Unterstützung für Element-Screenshots in PageSpeed Insights eingeführt, um Probleme bei einmaligen Leistungstests von Seiten leichter zu erkennen.
Core Web Vitals messen
Lighthouse kann die Core Web Vitals-Messwerte synthetisch messen, einschließlich Largest Contentful Paint, Cumulative Layout Shift und Total Blocking Time (ein Labor-Proxy für First Input Delay). Diese Messwerte spiegeln das Laden, die Layoutstabilität und die Interaktionsbereitschaft wider. Andere Messwerte wie First Contentful Paint, die im Artikel The future of Core Web Vitals hervorgehoben werden, sind ebenfalls vorhanden.
Der Abschnitt „Messwerte“ des Lighthouse-Berichts enthält Laborversionen dieser Messwerte. Sie können dies als Zusammenfassung der Aspekte der Nutzerfreundlichkeit verwenden, die Ihre Aufmerksamkeit erfordern.
Feldmesswerte, wie sie im Chrome UX Report oder in RUM zu finden sind, haben diese Einschränkung nicht und sind eine wertvolle Ergänzung zu Labordaten, da sie die Erfahrung echter Nutzer widerspiegeln. Felddaten können nicht die Art von Diagnoseinformationen liefern, die Sie im Labor erhalten. Daher gehen die beiden Hand in Hand.
Verbesserungspotenzial bei Web Vitals ermitteln
Largest Contentful Paint-Element identifizieren
Der LCP ist ein Messwert für die wahrgenommene Ladezeit. Er gibt den Punkt während des Seitenaufbaus an, 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 ermittelt wird, welches Element das Largest Contentful Paint-Element war. Wenn Sie den Mauszeiger auf das Element bewegen, wird es im Hauptfenster des Browsers hervorgehoben.
Wenn es sich bei diesem Element um ein Bild handelt, ist diese Information ein nützlicher Hinweis darauf, 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 der Größe angepasst oder in einem optimaleren modernen Bildformat bereitgestellt werden könnten.
Vielleicht ist auch das LCP-Bookmarklet von Annie Sullivan nützlich, um das LCP-Element mit nur einem Klick schnell mit einem roten Rechteck zu identifizieren.
Spät erkannte Bilder vorab laden, um den LCP zu verbessern
Um den Largest Contentful Paint zu verbessern, solltest du deine wichtigen Hero-Bilder vorab laden, 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 erkannt werden kann.
Es gibt einige häufig gestellte Fragen zum Vorabladen von LCP-Bildern, die wir hier kurz beantworten möchten.
Können responsive Bilder vorab geladen werden? Ja.
Angenommen, wir haben ein responsives Hero-Image, das mit srcset und sizes angegeben wird:
<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 vorab laden, die auch von srcset und sizes verwendet wird:
<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 einen CSS-Hintergrund definiert ist? Ja.
Jedes Bild, das als LCP-Bild gekennzeichnet ist, sei es über einen CSS-Hintergrund oder <img>, ist ein Kandidat, wenn es in einer Wasserfalltiefe von drei oder mehr gefunden wird.
Lazy Loading von Bildern, die nicht auf dem Bildschirm zu sehen sind, und Vermeiden von Lazy Loading für LCP
Bilder, die sich nicht im sichtbaren Bereich befinden und für die anfängliche Nutzererfahrung nicht entscheidend sind, können verzögert geladen werden. Bei dieser Technik wird das Herunterladen eines Bildes so lange verzögert, bis ein Nutzer in die Nähe des Bildes scrollt. Dadurch können Netzwerkkonflikte für kritische Assets reduziert und in einigen Fällen der LCP verbessert werden. Die Prüfung Nicht sichtbare Bilder aufschieben kann hier hilfreich sein:
Wichtige Bilder, die ohne Scrollen sichtbar sind („above the fold“), z. B. das Largest Contentful Paint-Bild, sollten nicht mit Lazy Loading geladen werden. Dies kann das Laden des LCP-Bilds verzögern. Lighthouse hebt hervor, wenn ein LCP-Bild fälschlicherweise mit Lazy Loading geladen wird. Dazu wird die Prüfung „Largest Contentful Paint-Bild wurde mit Lazy Loading geladen“ verwendet:
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 visuell verschiebt. Lighthouse bietet eine Prüfung zur Fehlerbehebung bei CLS mit dem Namen „Große Layoutverschiebungen vermeiden“.
Bei dieser Prüfung werden DOM-Elemente hervorgehoben, die am stärksten zu Verschiebungen auf der Seite beitragen. In der Spalte „Element“ links sehen Sie die Liste dieser DOM-Elemente und rechts ihren Gesamtbeitrag zur CLS.
Dank der neuen Funktion „Lighthouse-Element-Screenshots“ können wir uns eine visuelle Vorschau der wichtigsten Elemente ansehen, die in der Prüfung aufgeführt sind, und sie durch Klicken heranzoomen, um sie besser zu sehen:
Für den CLS nach dem Laden kann es hilfreich sein, mit Rechtecken dauerhaft zu visualisieren, welche Elemente am meisten zum CLS beigetragen haben. Diese Funktion ist in Drittanbietertools wie dem Core Web Vitals-Dashboard von SpeedCurve verfügbar. Ich verwende dafür gerne den Layout Shift GIF Generator von Defaced:
Für eine websiteweite Ansicht von Problemen mit Layoutverschiebungen ist der Core Web Vitals-Bericht der Search Console sehr hilfreich. So kann ich sehen, welche Arten von Seiten auf meiner Website einen hohen CLS-Wert haben. In diesem Fall kann ich selbst feststellen, mit welchen Vorlagenteilen ich mich beschäftigen muss:
CLS anhand von Bildern ohne Abmessungen identifizieren
Wenn ihr die durch Bilder ohne Größenangaben verursachte Cumulative Layout Shift begrenzen möchtet, fügt euren Bildern und Videoelementen die Größenattribute „width“ und „height“ hinzu. So kann der Browser beim Laden des Bildes den richtigen Platz im Dokument zuweisen.
Eine gute Beschreibung der Bedeutung von Bildabmessungen und Seitenverhältnis findest du unter Setting Height And Width On Images Is Important Again.
CLS durch Werbung identifizieren
Mit Publisher Ads for Lighthouse können Sie Möglichkeiten finden, die Ladezeit von Anzeigen auf Ihrer Seite zu verbessern. Dazu gehören auch Beiträge zu Layoutverschiebungen und langen Aufgaben, die die Nutzbarkeit Ihrer Seite durch Nutzer verzögern können. In Lighthouse können Sie dies über Community-Plug-ins aktivieren.
Anzeigen sind einer der größten Faktoren für Layoutverschiebungen im Web. Folgendes ist wichtig:
- Vorsicht beim Platzieren nicht fixierter Anzeigen im oberen Bereich des Darstellungsbereichs
- Verschiebungen vermeiden, indem Sie die größtmögliche Größe für die Anzeigenfläche reservieren
Nicht zusammengesetzte Animationen vermeiden
Nicht zusammengesetzte Animationen können auf Geräten mit geringerer Leistung ruckelig wirken, wenn umfangreiche JavaScript-Aufgaben den Hauptthread belegen. Solche Animationen können zu Layoutverschiebungen führen.
Wenn Chrome feststellt, dass eine Animation nicht zusammengesetzt werden konnte, wird dies in einem DevTools-Trace gemeldet, den Lighthouse liest. So können die Elemente mit Animationen, die nicht zusammengesetzt wurden, und der Grund dafür aufgelistet werden. Diese finden Sie in der Prüfung Nicht zusammengesetzte Animationen vermeiden.
Fehlerbehebung bei First Input Delay / Total Blocking Time / Long Tasks
First Input Delay (FID) gibt die Zeit von der ersten Interaktion des Nutzers mit einer Seite bis zum Reagieren des Browsers auf diese Interaktion an. Eine Interaktion findet beispielsweise statt, wenn der Nutzer auf einen Link klickt, auf eine Schaltfläche tippt oder ein benutzerdefiniertes, JavaScript-basiertes Steuerelement verwendet. Lange JavaScript-Aufgaben können sich auf diesen Messwert und den Proxy für diesen Messwert, die Total Blocking Time, auswirken.
Lighthouse enthält die Prüfung Lange Hauptthread-Aufgaben vermeiden, in der die längsten Aufgaben im Hauptthread aufgeführt sind. Das kann hilfreich sein, um die größten Verursacher von Eingabeverzögerungen zu identifizieren. In der linken Spalte sehen wir die URL der Scripts, die für lange Aufgaben im Hauptthread verantwortlich sind.
Rechts sehen wir die Dauer dieser Aufgaben. Zur Erinnerung: Long Tasks sind Aufgaben, die länger als 50 Millisekunden dauern. Dies wird als Blockierung des Hauptthreads angesehen, die lang genug ist, um die Framerate oder die Eingabelatenz zu beeinträchtigen.
Wenn Sie Drittanbieterdienste für das Monitoring in Betracht ziehen, gefällt mir auch die visuelle Zeitachse für die Ausführung des Hauptthreads von Calibre, um diese Kosten zu visualisieren. Sie hebt sowohl übergeordnete als auch untergeordnete Aufgaben hervor, die zu Long Tasks 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 die Auswirkungen des Entfernens oder der Nichtverfügbarkeit einzelner Ressourcen zu sehen. Das kann hilfreich sein, um die Kosten einzelner Scripts (z. B. Einbettungen oder Tracker von Drittanbietern) für Messwerte wie Total Blocking Time (TBT) und Time to Interactive zu verstehen.
Die Blockierung von Netzwerkanfragen funktioniert auch mit Lighthouse. Sehen wir uns kurz den Lighthouse-Bericht für eine Website an. Der Leistungswert beträgt 63/100 mit einer TBT von 400 ms. Wenn wir uns den Code ansehen, stellen wir fest, dass diese Website ein Intersection Observer-Polyfill in Chrome lädt, was nicht erforderlich ist. Blockieren wir es!
Wir können im Netzwerkbereich der Entwicklertools mit der rechten Maustaste auf ein Skript klicken und Block Request URL auswählen, um es zu blockieren. Hier machen wir das für das Intersection Observer-Polyfill.
Als Nächstes können wir Lighthouse noch einmal ausführen. Dieses Mal sehen wir, dass sich unser Leistungswert (70/100) und die Total Blocking Time (400 ms => 300 ms) verbessert haben.
Kostspielige Einbettungen von Drittanbietern durch eine Fassade ersetzen
Es ist üblich, Ressourcen von Drittanbietern zu verwenden, um Videos, Beiträge in sozialen Medien oder Widgets in Seiten einzubetten. Standardmäßig werden die meisten eingebetteten Inhalte sofort geladen. Das kann zu großen Nutzlasten führen, die sich negativ auf die Nutzerfreundlichkeit auswirken. Das ist unnötig, wenn der Drittanbieter nicht wichtig ist (z.B. wenn der Nutzer scrollen muss, bevor er ihn sieht).
Eine Möglichkeit, die Leistung solcher Widgets zu verbessern, besteht darin, sie bei Nutzerinteraktionen per Lazy Loading zu laden. Dazu können Sie eine einfache Vorabversion des Widgets (eine Fassade) rendern und die Vollversion nur laden, wenn ein Nutzer damit interagiert. Lighthouse bietet eine Prüfung, bei der Drittanbieterressourcen empfohlen werden, die mit einer Fassade per Lazy Loading geladen werden können, z. B. eingebettete YouTube-Videos.
Zur Erinnerung: Lighthouse hebt Drittanbietercode hervor, der den Hauptthread länger als 250 ms blockiert. So können Sie alle Arten von Drittanbieterscripts (einschließlich der von Google erstellten) finden, die Sie besser verzögert oder per Lazy Loading laden sollten, wenn die gerenderten Inhalte erst nach dem Scrollen sichtbar sind.
Über die Core Web Vitals hinaus
In den aktuellen Versionen von Lighthouse und PageSpeed Insights werden nicht nur die Core Web Vitals hervorgehoben, sondern es wird auch versucht, konkrete Anleitungen zu geben, wie sich die Ladezeit von JavaScript-lastigen Webanwendungen verbessern lässt, wenn Source Maps aktiviert sind.
Dazu gehört eine wachsende Sammlung von Prüfungen, mit denen sich die Kosten für JavaScript auf Ihrer Seite reduzieren lassen, z. B. durch eine geringere Abhängigkeit von Polyfills und Duplikaten, die für die Nutzerfreundlichkeit möglicherweise nicht erforderlich sind.
Weitere Informationen zu Core Web Vitals-Tools findest du auf dem Twitter-Konto des Lighthouse-Teams und unter What's new in DevTools (Neuigkeiten in den Entwicklertools).