Googles Web Core Vitals: Todesstoß für langsame Seiten?

Das Nutzererlebnis in Zahlen zu messen, ist nicht einfach. Google hat sich daher auf drei einigermaßen objektive Messwerte festgelegt:

 

• Largest Contentful Paint (LCP) – die größte inhaltliche Anzeigefläche. Wie lange dauert es, bis der wesentliche Inhalt der Seite erscheint? Zeigt mein Smartphone also 10 Sekunden weiß und dann den Inhalt, ist der LCP 10 Sekunden – egal, ob der wesentliche oder größte Inhalt Text, ein Bild oder ein Video ist.
• First Input Delay (FID) – Verzögerung für die erste Eingabe. Meist will ich nicht nur auf eine Website schauen, sondern weiter mit dieser interagieren. Zum Beispiel, indem ich einen Link klicke. Bei manchen Seiten funktioniert dies aber nicht sofort, weil im Hintergrund noch etwas rechnet. FID misst diese Verzögerung bis eine Website auf mich reagiert. Google setzt hier ein Ziel von <100ms, also weniger als eine Zehntelsekunde.
• Cumulative Layout Shift (CLS) – Aufsummierte Darstellungsverschiebung. Manchmal klicke ich einen Link – und lande ganz woanders, denn ein Werbebanner hat sich dorthin geschoben, wo eben noch mein eigentliches Ziel war. Super. Um solche sich verändernden Flächen zu messen, hat Google die CLS eingeführt. Sie wird berechnet durch den Anteil der sich nach dem ersten Laden noch verändernden Inhalte innerhalb einer gewissen Zeit.

 

Bei allen dreien dieser Metriken ist vor allem der Inhalt above the fold wichtig und maßgeblich, also der Inhalt, der ohne Scrollen auf dem Bildschirm sichtbar ist. Denn dies ist auch der Inhalt, den ein Nutzer zunächst sieht – alles, was weiter unten folgt, kann aus Nutzersicht auch später geladen werden; auf den Ersteindruck hat dies keine Auswirkung. Ermittelt werden die Daten seitenbasiert.

An einer guten User Experience sollte jedem gelegen sein, auch ohne Google oder andere Suchmaschinen. Dass sich das lohnt, wurde vielfach belegt: So sorgt bereits eine Ladezeit von 3 Sekunden (LCP) entsprechend einer Studie aus dem Jahr 2016 zu einer Absprungrate von 53% (Quelle); im eCommerce wurde wiederholt nachgewiesen, dass auch kleinste Verzögerungen zu Umsatzeinbußen führen.

Allerdings muss für einige notwendige Optimierungen das grundsätzliche Vorgehen neu gedacht werden. Das Problem zeigt sich beim Aufwand – nicht nur in einmaliger Erstellung, sondern auch bei der Wartung. Einige Beispiele, die etablierten Praktiken entgegenlaufen:

• CSS (Angaben, wie Elemente dargestellt werden sollen) wird heute in einer zentralen Datei gebündelt – das gesamte CSS einer Website. Eine einzelne Seite benötigt oft nur einen Bruchteil dieser Angaben; der sichtbare Bereich noch weniger. Resultat: Es wird viel geladen, was gar nicht gebraucht wird. Was unmittelbar gebraucht wird, muss in die Seite integriert werden – dass kann sich aber pro Seite unterscheiden. Die Lösung: das wichtige CSS muss (zusätzlich) direkt in die jeweilige Seite integriert werden.
• JavaScript fügt diverse Funktionalitäten zur Seite hinzu, ohne die eine Website fast gar nicht mehr funktioniert, muss aber erst verarbeitet werden und lädt oft langsam. Hinzu kommen ähnliche Probleme wie bei gebündeltem CSS. Auch hier muss dementsprechend pro Seite ausgesteuert werden, welches JavaScript geladen wird; womöglich noch unterteilt in sofort und später zu ladendes. Die Empfehlung „eine einzige JS-Datei“ wird damit ad absurdum geführt.
• Einige Entwickler setzen aus Komfortgründen zudem auf diverse Libraries und Frameworks, um Dinge schnell und einfach umzusetzen. Von diesen Libraries wird aber oft nur ein sehr kleiner Teil benötigt – der Rest muss aber trotzdem geladen und verarbeitet werden.

Für all diese Praktiken gibt es gute Gründe. In der Entwicklung wird damit Zeit gespart. Allerdings zahlt der User die Zeche in Form erhöhter Ladezeiten. Umgekehrt bedeutet dies, dass eine optimierte Seite höhere Aufwände bei der (Weiter-) Entwicklung verursacht. Manchmal muss hier wohl zukünftig auch die Systematik neugedacht werden müssen.

Zusätzlich sollten seit Jahren bekannte Best Practices beachtet werden: Libraries sollten nicht grundsätzlich eingebunden werden, weil man eine einzige Funktion so gerne nutzt; neben Komfort und Geschwindigkeit bei Entwicklung und Wartung, sollte die Auswirkung auf den Nutzer (inklusive Suchmaschinen) mindestens ebenso stark gewichtet werden.

Bilder möglichst klein zu halten ist ebenfalls ein einfacher „Trick“ zur Seitenbeschleunigung. (Dieser beißt sich aber wieder mit der Forderung nach hochauflösenden Bildern (z.B. für Retina-Displays) – den Kompromiss gilt es zu finden!). HTTP2, moderne Bildformate wie webP und Co sind weitere individuelle Maßnahmen, die oft weiterführen.

Ein Nebenproblem ist das Vorhandensein von Tools und Messdaten. Google stellt https://web.dev und Lighthouse zur Verfügung.

Hier zeigen sich aber schon erste Schwierigkeiten: Führe ich 10-mal hintereinander einen Test mit der gleichen Seite durch, bekomme ich mehrere unterschiedliche (oft stark voneinander abweichende) Ergebnisse. Das liegt daran, dass web.dev meinen eigenen Rechner nutzt und auf eine festgelegte Verbindungsgeschwindigkeit drosselt. Alles, was gleichzeitig auf diesem abläuft, kann das Ergebnis beeinflussen. Außerdem ändert sich der Inhalt der Seite womöglich – gerade Werbeeinblendungen sind oft wenig optimiert und verursachen extreme Unterschiede. Diese Daten sind „Labordaten“. Durch die mitgelieferten Empfehlungen bieten sie immerhin Ansatzpunkte zur Verbesserung.

Die Alternative sind echte Nutzerdaten, die Google über Chrome sammelt und zur Verfügung stellt. Allerdings sind nur für einigermaßen große Websites ausreichend Daten vorhanden; kleinen Websites bleibt diese Möglichkeit verwehrt. Pragmatisch bleibt dann nur die Nutzung von Tools mit Labordaten.

Aber auch die Empfehlungen sind nicht unproblematisch: Oft zeigt sich, dass eine „mögliche Ersparnis“ nur mit viel Aufwand erreichbar ist. Manche Empfehlung zeigt hingegen nur geringe Wirkung. Andere Empfehlungen kann man schlicht nicht umsetzen: Ist man zum Beispiel auf das Script eines Drittanbieters angewiesen, kann man dessen Performance kaum beeinflussen. Andererseits kann einiges auch sehr einfach erreicht werden: Um die CLS auf 0 zu bringen, genügt womöglich eine fest deklarierte Größe für alle Elemente. Und wenn schon Sekunden bei der Anfrage an den Server verloren gehen, sollte man auf ein besseres Hosting umsteigen.

Auf der SMX 2021 empfahl so auch Martin Splitt von Google ein schnelles Trial & Error-Vorgehen mit den Empfehlungen. Auch er konnte eine Kritik allerdings nicht ganz entkräften: Deutschland hat fast flächendeckend bessere Verbindungen als von den Testtools angenommen. Dies ist sicher das bekannte Dilemma zwischen Fokus auf die Plätze mit guter Infrastruktur und jenen Gebieten, in denen diese hinterherhinkt.

Gute UX fördert den Verkauf – das galt auch schon bevor Google die Web Core Vitals zum Rankingfaktor machte und unabhängig von Suchmaschinen. Dementsprechend helfen die gleichen Best Practices, die seit Jahren empfohlen werden:

• Nutzen Sie ein responsives Design, damit alle Geräte Ihre Website gut darstellen.
• Spielen Sie insbesondere Bilder in passenden Größen aus.
• Nutzen Sie Lazy Loading für Elemente, die nicht unmittelbar sichtbar sein müssen, um die initiale Darstellung zu beschleunigen.
• Schaffen Sie Seiten, die zu ihren Kampagnen und den Zielen Ihrer Besucher passen: Erkennt Ihre Kundin sofort, dass sie am richtigen Ort ist, wartet sie gerne ein wenig.
• Bieten Sie relevante, wertvolle Inhalte.
• Stellen Sie eine intuitive, klare Navigation und Nutzerführung sicher. (Auch Suchmaschinen erkennen gut strukturierte Inhalte besser.)
• Bereiten Sie Ihren Content für mobile Endgeräte auf. Priorisieren Sie insbesondere Elemente above the fold, also im unmittelbar sichtbaren Bereich.

 

Wie eine Optimierung konkret aussehen kann, beschreibe ich in Web Core Vitals optimieren - ein Praxisbeispiel.

Sie wissen nicht, wo Sie stehen? Sie wollen Ihre Website fit machen für die Wünsche der Nutzer? Sichern Sie sich noch heute einen Experten.