Häufigste Fehler, die Web Vitals beeinträchtigen

Im Rahmen des PageSpeed.ONE-Projekts habe ich bereits Dutzende von Geschwindigkeitsaudits und kleinere Analysen für Websites unterschiedlicher Größe durchgeführt. Ich habe daher beschlossen, alle Analysen zu überprüfen, um die häufigsten Fehler zu finden, die in unseren Audits immer wieder auftreten und die Metriken der Core Web Vitals beeinträchtigen.

Die Aufzeichnung des Vortrags können Sie sich auf dem YT-Kanal von Frontendisti ansehen. Wenn Sie die schriftliche Form bevorzugen, lesen Sie den heutigen Artikel unten.

Inhalt#

• Web Vitals auf den Punkt gebracht
• Wie misst man die Geschwindigkeit Ihrer Website?
• FID - Eine JavaScript-Metrik, die fast keiner Optimierung bedarf
• LCP - wahrscheinlich die wichtigste und meine Lieblingsmetrik
• CLS - eine Metrik voller Missverständnisse

Web Vitals auf den Punkt gebracht#

Die Geschwindigkeit von Websites ist ein immer größer und komplexer werdendes Thema, in dem man sich leicht verlieren kann. Und dann gibt es da noch die Web Vitals. Was sind die und warum sollten wir uns darum kümmern?

Web Vitals sind Metriken von Google, die zu einem der Bewertungskriterien für die Platzierung in den Suchergebnissen werden sollen. Weitere Details zur Google Page Experience würden einen eigenen Artikel füllen, daher verweise ich Sie, wenn Sie mehr über dieses Update lesen möchten, auf den Blogpost zur Google Page Experience von Martin Michálek.

Nun ein kurzer Überblick über die Web Vitals. Die grundlegenden Metriken sind drei: First Input Delay (FID), Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS). Alle Metriken haben empfohlene Werte, die Sie im Bild sehen.

Aber wir wissen immer noch nicht, wie man die Web Vitals misst.

Wie misst man die Geschwindigkeit Ihrer Website?#

Es gibt viele Möglichkeiten. Ein Werkzeug ist zum Beispiel Google Data Studio, in dem Sie Berichte mit den Ergebnissen der einzelnen Metriken erstellen können. Leider ist die Arbeit mit Data Studio oft kompliziert und zeitaufwändig.

Web Vitals können auch in PageSpeed Insights angezeigt werden, aber dort sind die Daten wieder stark eingeschränkt und vereinfacht. Bei PageSpeed.ONE haben wir daher mit den Kollegen ein Update des Testers 2.0 entwickelt, das (nicht nur) dieses Problem löst. Das Ergebnis ist ein vollständiger Überblick über die Nutzerdaten – einfach und übersichtlich.

Falls Sie gerade die Adressen Ihrer Websites im Tester eingegeben haben und Ihnen die Ergebnisse nicht gefallen, habe ich eine gute Nachricht für Sie. Viele Fehler wiederholen sich fast auf jeder Website, also schauen Sie doch mal mit mir, wonach Sie suchen sollten.

FID - First Input Delay#

Zu Beginn werfen wir einen Blick auf die Metrik First Input Delay. Wie der Name nicht wirklich verrät, handelt es sich um eine JavaScript-Angelegenheit, die die Zeit von der ersten Interaktion des Nutzers mit der Seite bis zur Verarbeitung der Interaktion durch den Browser misst.

FID mussten wir bisher nicht wirklich ernsthaft angehen, da sie sich als wenig strenge Metrik erweist. Ihr Grenzwert für eine gute Bewertung liegt bei 100 ms, was Websites gut leisten können.

Eine sehr ähnliche JS-Metrik ist Total Blocking Time (TBT), bei der Google auf die Verbindung zu FID hinweist. In der Praxis hat sich jedoch nicht bestätigt, dass ein schlechter TBT ein schlechtes FID-Ergebnis bedeutet. Wenn Sie jedoch TBT optimieren, verbessern Sie oft auch die FID.

Ein Beispiel für vermasselte JavaScript-Metriken: Auf der ersten Hälfte des Screenshots unten ist das Messergebnis einer Seite zu sehen, auf der ein YouTube-Video in einem iframe tobt, ein bekannter Killer der Metriken TBT und Time to Interactive (TTI). Die Metriken sind so hoch, weil YouTube große CSS- und JS-Dateien herunterlädt.

Lösung für bessere Metriken? Für YT, das über ein iframe eingebettet ist, nutzen Sie entweder das native Lazyloading oder YouTube Lite Embed.

LCP - Largest Contentful Paint#

Meine Lieblingsmetrik, das ist Largest Contentful Paint. Lieblingsmetrik, weil sie komplex ist. Um sie zu optimieren, muss man viele Bereiche beim Laden beherrschen. Sie kann die Kenntnisse der Entwickler beim Laden einer Website solide überprüfen, und wir können damit die Darstellung des größten Elements auf der Seite messen.

Beim Feintuning von LCP ist es am wichtigsten, zuerst die LCP-Elemente zu identifizieren. Für Mobil- und Desktopgeräte sind diese oft unterschiedlich. Zuverlässig finden Sie Ihre LCP-Elemente mit Lighthouse, PageSpeed Insights oder im Detail des Tests in unserem Tool PageSpeed.ONE.

LCP und Lazy Loading#

Die überwiegende Mehrheit der Websites schadet ihrer LCP-Metrik durch schlecht implementiertes Lazy Loading. Es ist entscheidend zu verstehen, dass Lazy Loading die Reihenfolge des Herunterladens von Bildern verändert.

Ein sehr häufiger Fehler ist ein Lazy Loading, das nur auf große Bilder auf der Seite angewendet wird. Ja, logischerweise spart das Verschieben des Ladens der größten Bilder am meisten Daten, aber im Fall eines LCP-Elements untergräbt es Ihren Erfolg.

Die Regel besagt, dass Bilder ohne Lazy Loading zuerst heruntergeladen werden. Bilder mit Lazy Loading werden erst später heruntergeladen, auch wenn sie im Sichtfeld sind. Wenn Sie Lazy Loading auf ein Bild anwenden, das gleichzeitig ein LCP-Element ist, wird dieses Bild viel später heruntergeladen, was die LCP-Zeit erhöht.

Die Lösung haben Sie wahrscheinlich bereits beim Lesen selbst erkannt: Entfernen Sie das Lazy Loading von den LCP-Elementen auf Ihrer Website und fügen Sie es zu allen anderen Elementen hinzu.

LCP und komplexes DOM#

Eine schlechte Nachricht gleich zu Beginn, dies nimmt bei der Optimierung meist viel Zeit in Anspruch. Andererseits gebe ich Ihnen einen Hotfix, bevor Sie größere Änderungen am Code vornehmen.

Hier entsteht das Problem meist schon im Design, wo es einen großen Unterschied zwischen der Desktop- und der mobilen Version gibt. Das müssen Sie natürlich lösen, oft durch das Ausblenden von Elementen auf Mobilgeräten.

Die dunkelblaue Fläche ist ziemlich umfangreich, nicht wahr? Das wird Ihre LCP-Metrik ganz schön durcheinanderbringen. Es ist wichtig zu erwähnen, dass es nicht so schlimm wäre, wenn wir von einfachen DOM-Text-Elementen sprechen würden. Hier gibt es jedoch ein Problem mit vielen Bildern, die heruntergeladen werden, auch wenn sie nicht sichtbar sind.

Es gibt mehrere Lösungen. Wenn Sie Zeit und Kapazitäten haben, schreiben Sie das HTML so um, dass es die LCP-Elemente widerspiegelt. Sie können auch Preload für das Bild verwenden, das als LCP auf Mobilgeräten identifiziert wurde.

<link rel="preload" as="image" href="image.jpg" />

Mit Preload seien Sie jedoch sehr vorsichtig, besonders wenn Sie bereits andere Preloads auf der Seite haben. Sie können auch das Attribut loading="lazy" nutzen, denn Bilder in versteckten Elementen mit diesem Attribut werden nicht heruntergeladen.

LCP und Bilder aus dem WYSIWYG#

Die Arbeit mit Bildern im Editor muss kontrolliert werden. Viele E-Shops schreiben unter ihrer Domain einen Blog, der ebenfalls die Metriken beeinträchtigen kann, und oft ist das tatsächlich der Fall. Ich möchte nicht auf Entwickler und Programmierer einprügeln, aber das, was der Benutzer über den WYSIWYG hochlädt, ist auch Ihr Problem. Auch hier müssen Größen, Komprimierungen, geeignete Formate und srcsets gelöst werden.

CLS - Cumulative Layout Shift#

Cumulative Layout Shift ist eine Metrik, die sich mit Verschiebungen und Springen des Layouts der Seite beschäftigt. Kritisch sind nicht nur Layout-Verschiebungen beim Laden, die von synthetischen Tools gemessen werden, sondern auch Layout-Verschiebungen während des Durchsuchens der Seiten. Diese können Sie durch einen Blick in die Nutzerdaten des Chrome UX-Berichts erkennen.

Wie testet man einen solchen CLS? Idealerweise über ein Chrome-Plugin namens Web Vitals oder direkt im Chrome unter dem Reiter Rendering mit der Option "Core Web Vitals".

CLS und die Attribute width und height#

Was CLS betrifft, bemängeln wir auf jeder Website fehlende Attribute width und height im img-Tag. Oft handelt es sich um eine Nachlässigkeit, daher müssen alle Bilder im Projekt gesucht und fehlende Attribute überprüft werden.

<img src="image.jpg" alt="img" width="150" height="200" />

Eine weitere Lösung gegen das Springen von nicht nur Bildern, sondern auch anderen Inhaltselementen wird in Zukunft die CSS-Eigenschaft aspect-ratio sein. Mit einer einzigen Codezeile lösen Sie den Raum, den das Element für seinen Inhalt reservieren soll.

.box {
  aspect-ratio: 4/3;
  background: grey;
}

Wenn Sie sofort eine wasserdichte Lösung benötigen, empfehlen wir den Padding-Top-Trick.

CLS und Karussells (zum Beispiel)#

Cumulative Layout Shift kann nicht nur durch Karussells, sondern durch jegliche Initialisierungen von Inhalten mittels JavaScript verschlechtert werden. Oft handelt es sich um verschiedene Quizze, Rechner, Widgets usw.

In der Regel erfolgt die Initialisierung von JavaScript sehr spät, weshalb der CLS steigt. Es ist nicht ratsam, Dinge mit JavaScript zu lösen, die wir in CSS stylen können. Typischerweise sind dies die Breiten einzelner Elemente im Karussell.

Lösen Sie daher die Breiten und Höhen der Elemente in CSS, testen Sie Ihre Website mit deaktiviertem JavaScript. All das hilft Ihnen, die Schwachstellen auf Ihrer Website zu entdecken. Hilfreich kann beispielsweise das Chrome-Plugin Web Developer sein, mit dem JavaScript einfach mit einem Klick deaktiviert werden kann.

CLS und AJAX#

Die CLS-Metrik wird nicht nur zum Zeitpunkt des Ladens der Seite berechnet, sondern auch während des Navigierens der Seite durch den Benutzer. Wenn der Benutzer auf der Website beispielsweise entscheidet, „Weitere 24 Produkte“ zu laden, haben Sie nach dem Klicken ein Intervall von 0,5 Sekunden, um den Inhalt anzuzeigen, ohne den CLS weiter zu erhöhen.

Die Anweisungen für eine solche Situation sind wie folgt: Testen Sie langsame Netzwerke und laden Sie Inhalte verzögert, wenn der Browser „langweilig“ ist, mittels RequestIdleCallback();.

Ein paar Worte zum Abschluss#

Wenn Sie neu im Bereich der Website-Geschwindigkeit sind und ich Sie mit einer Flut neuer Informationen überhäuft habe, verzweifeln Sie nicht. Machen Sie sich zuerst einen Kaffee und konzentrieren Sie sich dann auf Datenerfassung und Tests. Interessieren sollten Sie sich nicht nur für die Nutzerdaten der Web Vitals, sondern auch für synthetische Messungen. Alles idealerweise im Kontext von mehreren Monaten.

Was die Synthetik betrifft, ist Lighthouse in Version 8 erschienen, wo zum Beispiel der Berechnungsmodus der Punktzahl angepasst wurde. Beispielsweise machen die Metriken TBT und LCP zusammen 55 % des Gesamtgewichts in der Berechnung aus. Das allein legt nahe, auf welche Metriken Sie sich konzentrieren sollten.

Abschließend möchte ich allen Entwicklern genug Neugier und Lust mit auf den Weg geben, zu verstehen, wie ein Browser wirklich funktioniert. Konzentrieren Sie sich auf DevTools und die Registerkarte Performance zur Optimierung, denken Sie ganzheitlich und versuchen Sie herauszufinden, wie sich die einzelnen Dinge auf der Website gegenseitig beeinflussen. Sie können auch lernen, beide problematischen Metriken zu optimieren – CLS und LCP.

Diskussion#

Nach dem Vortrag folgte auch eine moderierte Diskussion, in der ich zusammen mit Michal Matuška Fragen aus dem Publikum beantwortete.

Tags:Core Web Vitals