Wie Sie die Core Web Vitals verbessern können

Die Core Web Vitals (CWV) sind eine Reihe von Metriken, die Google bei der Analyse der Gesamtleistung von Webseiten unterstützen.

Die Core Web Vitals (CWV) sind eine Reihe von Metriken, die Google helfen, die Gesamtleistung von Webseiten zu bewerten.

Diese drei Metriken sind:

1. Largest Contentful Paint (LCP)
2. First Input Delay (FID)
3. Cumulative Layout Shift (CLS)

Jede der drei Core Web Vitals repräsentiert einen bestimmten Aspekt der Nutzererfahrung.

Zusammen mit anderen Web Vitals sind LCP, FID und CLS Teil der Page Experience Signale von Google, die für Ranking-Zwecke verwendet werden.

Die CWVs messen und bewerten drei Aspekte von Webseiten: Laden, Interaktivität und visuelle Stabilität.

Die erste Core Web Vital ist LCP (Largest Contentful Paint). Die LCP-Metrik wird verwendet, um die Zeit zu messen, die das größte Bild oder der größte Textblock innerhalb einer bestimmten Viewport benötigt, um sichtbar zu werden, nachdem eine Seite zu laden beginnt. Googles aktueller Benchmark für Largest Contentful Paint liegt unter 2,5 Sekunden.

Googles zweite Core Web Vital ist FID (oder First Input Delay). Die FID-Metrik bewertet die Reaktionsfähigkeit der Seite und misst die Zeit, die eine Seite benötigt, um auf Benutzereingaben (Klick, Berührung oder Tastendruck) zu reagieren. Ein guter First Input Delay gilt als unter 100 Millisekunden.

Zu guter Letzt misst die CLS-Metrik die visuelle Stabilität einer Seite. Wenn eine Webseite während des Seitenladens instabile Elemente aufweist, wird dies zu einem schlechten CLS-Score führen. Ein guter Cumulative Layout Shift Score sollte 0,1 oder weniger betragen.

Wie Core Web Vitals mit organischen Impressionen und Klicks korrelieren

Wenn Sie eine der Fallstudien zu Core Web Vitals lesen, werden Sie viele widersprüchliche Informationen darüber finden, wie gut ein guter CWV-Score mit organischen Impressionen und Klicks korreliert. Ich habe diesen Abschnitt bewusst an den Anfang der Studie gestellt, um zu zeigen, wie die Optimierung von CWVs für uns funktioniert hat und warum wir sie zu einer unserer Hauptprioritäten für das laufende Jahr gemacht haben.

Der CWV-Bericht in der Google Search Console hat eine 3-monatige Begrenzung der verfügbaren Daten. Um unsere Fortschritte bequemer als mit Googles Tools zu verfolgen, haben wir eine Integration zwischen der Google Search Console API und Microsoft PowerBI erstellt. Auf diese Weise konnten wir alle Daten in einem einzigen Dashboard zusammenführen und alle historischen Daten ohne Einschränkungen sammeln.

Ausgangspunkt

Der gesamte Prozess der CWV-Optimierung begann damit, dass wir unsere aktuelle Situation in der Google Search Console überprüft haben.

Neben der Search Console können Sie auch Googles PageSpeed Insights verwenden, um die CWVs auf Ihrer Website zu überprüfen. Es ist jedoch wichtig, den wesentlichen Unterschied zwischen den beiden zu verstehen und wie sie CWVs bewerten.

Die Search Console basiert auf Felddaten, d.h. den Daten des Chrome User Experience Reports (CrUX), was bedeutet, dass die CWV-Scores darauf basieren, wie reale Nutzer die Seiten erleben. Diese Daten werden alle 28 Tage aktualisiert, sodass Sie auf die Ergebnisse der Leistungsverbesserungen warten müssen.

PageSpeed Insights ermittelt die Scores anhand von Labordaten, einer Simulation dessen, was Google für einen durchschnittlichen Webnutzer hält. Sie können jede Seite jederzeit überprüfen.

Daher ist PageSpeed Insights nützlich, wenn Sie eine schnelle Einschätzung darüber erhalten möchten, was mit den CWVs auf einer bestimmten Seite passiert.

Wie wir die Core Web Vitals Metriken verbessert haben

Als wir zum ersten Mal von den drei Core Web Vitals erfuhren, schien deren Optimierung eine triviale Aufgabe zu sein. Wir konsultierten den Lighthouse-Bericht, PageSpeed Insights und die Search Console und folgten den gegebenen Empfehlungen. Was konnte schiefgehen?

Nur wenige Wochen später erkannten wir, dass es Hunderte von Problemen geben konnte, die zu schlechten CWV-Scores führten. Um unsere Erfahrungen zu teilen und Ihnen viel Zeit zu ersparen, habe ich mein Bestes getan, um alles, was getan wurde, in einem leicht verständlichen Format zusammenzufassen.

Vorbereitung von Geo-spezifischen Servern und CDNs

– Betroffene Metriken: TTFB, LCP –

Die Server-Antwortzeit ist entscheidend und kann alle CWV-Optimierungsbemühungen zunichtemachen, wenn sie nicht im Voraus bedacht wird. Eine der Metriken, die Google zur Bewertung der Server-Antwortzeit verwendet, nennt sich Time to First Byte (TTFB), und obwohl sie keine Core Web Vital ist, gehört sie zu den anderen Web Vitals.

Die TTFB misst die Zeit zwischen dem Zeitpunkt, an dem ein Nutzer auf einer Website landet, und dem Moment, in dem der erste „Bissen“ an Informationen geladen wird. Normalerweise sollte die TTFB unter 600 ms liegen.

Ein schlechter TTFB wirkt sich negativ auf LCP aus –, daher ist es entscheidend, diese so niedrig wie möglich zu halten. In den meisten Fällen kann der TTFB-Score einfach durch den Wechsel zu einem besseren Hosting-Provider verbessert werden. Das war jedoch bei link-assistant.com nicht der Fall.

Link-assistant.com hat ein globales Publikum, und Google verwendet Real User Monitoring (RUM)-Daten, um zu bestimmen, ob eine bestimmte Seite die Kriterien für Web Vitals erfüllt. Das bedeutet, wenn die TTFB z. B. für die USA gut ist und für Indien schlecht, wird letzteres den endgültigen TTFB-Score nach unten ziehen.

Bevor CWVs so wichtig wurden, hatten wir nur einen Serverstandort in den USA. Offensichtlich war das für eine Website mit internationalem Publikum nicht ausreichend.

Dies führte uns zu der Annahme, dass die Traffic-Volumen aus Indien für einen einzelnen Server zu hoch waren. Der Server war also wahrscheinlich überlastet, was zu einer schlechten TTFB für alle anderen Standorte als Indien führte. Wir haben daraufhin zwei neue Server hinzugefügt: einen in Osaka und den anderen in Singapur.

Da die zusätzlichen Server erst vor etwa einer Woche hinzugefügt wurden, müssen wir auf die endgültigen Ergebnisse warten. Die Verbesserung ist jedoch bereits für die meisten Standorte sichtbar.

Das gleiche Problem mit der TTFB wurde in Amerika beobachtet. Nicht nur die TTFB-Scores verbesserten sich nicht für die Standorte in den USA, sondern es gab auch enorm hohe Server-Antwortzeiten für Nutzer in Brasilien und Chile.

Hier zogen wir einige Schlussfolgerungen. Erstens ist unser organischer Traffic in Amerika so stark wie in Indien, daher können zwei Server den Fluss wahrscheinlich nicht bewältigen, ohne die TTFB zu beeinträchtigen.

Zweitens befand sich einer unserer Server bei Wowrack. Unser Entwicklungsteam stellte fest, dass dieser Server stark überlastet war, ziemlich veraltete technische Spezifikationen hatte und sich in der berüchtigten Zone des „ältesten Internets“ an der Westküste der USA befand, was zu erheblichen Verbindungsverzögerungen zwischen den Nutzern und dem Server selbst führte.

Als endgültige Lösung haben wir kürzlich einen zusätzlichen AWS-Server konfiguriert, sodass wir nun drei Server in den USA haben. Die Ergebnisse der von uns vorgenommenen Verbesserungen sind noch nicht signifikant, aber wir werden sie im Auge behalten und diese Studie später aktualisieren.

Insgesamt hat uns die Optimierung der TTFB für link-assistant.com ermöglicht, diese Metrik signifikant zu verbessern, was wiederum zu einer Verbesserung der LCP führte. Ein Win-Win-Ergebnis für uns.

Darüber hinaus haben wir, als wir sicher waren, dass die TTFB gut genug war, sichergestellt, dass alle unsere statischen Assets (Bilder, CSS, Javascript) von CDNs und nicht von unseren eigenen Servern geladen wurden. Obwohl indirekt, hilft es, alle statischen Assets auf CDNs zu haben, die TTFB-Scores zu verbessern, da die Server nicht mit zusätzlichen Anfragen zum Laden von Bildern, CSS oder JS überlastet werden.

Hinweis

Die Anschaffung zusätzlicher Server ist eine kostspielige Lösung, die nicht in 100 % der Fälle zwingend erforderlich ist. Wenn Ihre Website ein lokales Publikum bedient, können Sie problemlos einen einzelnen Server in der Nähe Ihres Zielpublikums verwenden. Wenn Sie Probleme mit der TTFB haben, probieren Sie weniger drastische Lösungen aus, wie den Wechsel des Hosting-Providers. Wenn die Probleme weiterhin bestehen, konsultieren Sie diesen Artikel von Google.

Verzögertes Laden von Drittanbieter-JS

– Betroffene Metriken: LCP –

Drittanbieter-JS umfasst alles von Facebook-Sharing-Buttons bis hin zu Google Analytics-Trackern auf einer Seite. Diese Seitenelemente verbrauchen immer viele Rendering-Ressourcen. Darüber hinaus stoppt jeder Browser, wenn er auf ein solches JS-Stück stößt, das Rendering von HTML, bis er mit dem Rendern des JS fertig ist. All dies führt zwangsläufig zu einem schlechten LCP.

Wir haben zuerst analysiert, welche blockierenden Rendering-JS-Dateien wir auf unseren Seiten hatten. Aus der Untersuchung ging hervor, dass die Hauptblocker Social-Media-Sharing-Buttons, Facebook-Kommentarblöcke, YouTube-Embeds und Sleeknote, das wir für Pop-ups verwendeten, waren.

Zum Beispiel konnten allein die eingebetteten YouTube-Videos zu einer LCP-Zeitverkürzung von bis zu 30 % beitragen:

Obwohl es nicht zwingend erforderlich war, haben wir alle Drittanbieter-Skripte, wo immer möglich, entfernt, um bessere LCP-Scores zu erzielen.

Gleichzeitig gab es Seiten, auf denen wir die Social-Media-Sharing-Buttons, Sleeknote oder GA-Tracker beibehalten wollten.

Um diese Seitenelemente beizubehalten, ohne den LCP zu beeinträchtigen, haben wir sie aus dem kritischen Rendering-Pfad verschoben. Dies geschah durch Hinzufügen eines der folgenden Attribute zum Tag
<script>:

• Async. Dieses Attribut weist den Browser an, das Skript asynchron auszuführen, ohne die Analyse einer Seite zu unterbrechen. Wir haben dieses Attribut für Skripte verwendet, die für verzögertes Laden empfindlich waren (Google Analytics):

Nur der Vollständigkeit halber, hier ist eine visuelle Erklärung der Attribute defer e async:

Es ist erwähnenswert, dass Sie es vermeiden müssen, das Attribut
defer zu verwenden und stattdessen
async für diverse Tracking-Skripte. In unserem Fall verpassten wir fast 15 % der Zielverfolgung in Google Analytics, nachdem wir das Tracking-Skript ans Ende des Rendering-Pfades verschoben hatten.

Hinweis

Die gleiche Technik wurde auch auf unseren benutzerdefinierten JS angewendet. Wir haben uns mit allen JavaScripts befasst, die auf unseren Seiten verwendet werden, und analysiert, welche Teile irrelevant waren, um sie zu löschen, und welche Teile beibehalten werden mussten: In den meisten Fällen ließen wir sie asynchron mit dem Attribut „async.

2. Optimierung der Zeichenverwendung

– Betroffene Metriken: LCP, CLS –

Webschriften sind entscheidend für ein ansprechendes Design, bessere Lesbarkeit und Markenidentität, aber sie sind auch große Dateien, deren Laden einige Zeit dauern kann und sowohl LCP als auch CLS beeinträchtigen kann.

Wenn eine Drittanbieter-Schriftart für einen Textblock verwendet wird, der das LCP-Element darstellt, kann sich die LCP-Punktzahl negativ auswirken, da der Browser Zeit benötigt, um diese Schriftart zu laden und abzurufen.

Was die Cumulative Layout Shift betrifft, so ist das Hauptproblem bei Drittanbieter-Schriften, dass der Browser eine Systemschriftart anzeigt, bevor eine bestimmte Schriftart geladen ist. Sobald die Drittanbieter-Schriftart geladen ist, kann sie mehr Platz auf dem Bildschirm einnehmen, was die visuelle Stabilität einer Seite beeinträchtigt, zu einer Layoutverschiebung führt und eine schlechte CLS-Punktzahl verursacht.

So sieht die Layoutverschiebung aus:

Bevor Core Web Vitals ein Thema wurden, hatten wir viele verschiedene Schriftarten auf einer einzigen Seite.

Manchmal wurden diese Schriftarten nicht einmal verwendet, aber trotzdem geladen. Wie Sie im folgenden Screenshot sehen können.

Die Schriftart Roboto wurde ausschließlich im Pop-up-Tooltip verwendet, der auf Mobilgeräten nicht sichtbar war, aber gleichzeitig wurde die Schriftart trotzdem geladen.

Wir verwendeten auch viele externe Schriftarten, wie Google Fonts, die außerhalb unseres Servers gespeichert waren.

Daher haben wir als Erstes alle externen Schriftarten eliminiert und auf Systemschriftarten (Arial, Helvetica, Verdana, Tahoma usw.) umgestellt. Diese einfache Lösung hat für uns außerordentlich gut funktioniert, und wir sahen eine große Verbesserung sowohl der LCP- als auch der CLS-Punktzahlen.

Uns wurde auch klar, dass es Fälle geben könnte, in denen wir Drittanbieter-Schriften verwenden müssten. Für solche Fälle machen wir die Schriftart auf unseren Servern selbst gehostet und laden sie im Head-Bereich des HTML einer Seite vorab. Als letzten Schliff haben wir auch sichergestellt, dass wir keine Symbolschriften verwenden. Dies sind Schriftarten, die verwendet werden, um schematische Bilder zu ersetzen, wie z. B. eine Lupe, die für Suchleisten verwendet wird. Solche Symbole wurden durch SVG-Bilder ersetzt, die auf unseren Servern gehostet werden, damit der Browser sie nicht jedes Mal von externen Quellen laden muss.

Wichtiger Hinweis

Das Selbst-Hosten von Webfonts kann die LCP-Verbesserung nicht unterstützen, wenn Ihre Website keine CDNs und kein HTTP/2 verwendet. Versuchen Sie, sowohl mit selbst gehosteten als auch mit Drittanbieter-Schriften zu experimentieren, um zu sehen, welche Lösung für Sie am besten funktioniert.

3. Extraktion von kritischem CSS und JS

– Betroffene Metriken: LCP –

CSS ist eine Rendering-blockierende Ressource, was bedeutet, dass eine Seite nicht gerendert werden kann, bis der Browser alle CSS-Dateien abgerufen und geparst hat. Wenn das CSS groß ist, dauert das Laden lange, was sich direkt auf die LCP-Punktzahl auswirkt.

In unserem Fall lag es nicht nur an der Größe des von uns verwendeten CSS. Vor Beginn der Optimierungsarbeiten hatten wir ein einziges CSS-Stylesheet für alle Seiten mit über 70.000 Zeilen. Das gleiche große CSS wurde für jede Seite geladen, auch wenn es dort tatsächlich nicht verwendet wurde.

Um dies zu beheben, haben wir zunächst den Abdeckungsbericht in den Chrome-Entwicklertools konsultiert. Wir haben dann den gesamten Inhalt dieser CSS-Datei durchgesehen und alle irrelevanten Zeilen entfernt. Dies ermöglichte es uns, die tatsächliche Größe und den Anteil ungenutzter Bytes erheblich zu reduzieren.

Hinweis

Um die Größe unserer CSS-Dateien weiter zu reduzieren und sicherzustellen, dass sie sich nicht negativ auf die LCP-Punktzahl auswirken, haben wir sie auch einem CSS-Minifizierungsverfahren unterzogen.

CSS-Stylesheets enthalten oft überflüssige Kommentare, Leerzeichen und Zeilenumbrüche, und das Entfernen all dieser kann oft dazu beitragen, die endgültige Dateigröße um bis zu 50 % zu reduzieren. Wir haben CSS Minifier verwendet, um die Größe unseres CSS zu reduzieren, und JSCompress, um dasselbe mit dem Rendering-blockierenden JavaScript zu tun.

Schließlich hat unser Entwicklungsteam ein spezielles Tool entwickelt, das die Minifizierung jetzt automatisch verwaltet.

Darüber hinaus gab es, genau wie bei JS, keinen Grund, das gleiche riesige CSS jedes Mal für jede Seite zu laden. Daher haben wir nur die für den Bereich über dem Knick einer bestimmten Seite benötigten Stile extrahiert und sie in die HTML-Datei dieser Seite eingefügt.

4. Komprimierung des HTTP-Inhalts

– Betroffene Metriken: LCP –

Die Komprimierung von HTTP-Inhalten ist eine hervorragende Praxis, um die Größe der zwischen Server und Browser übertragenen Dateien zu reduzieren. Dies kann die Seitenladezeiten erheblich verkürzen und die LCP-Punktzahl verbessern.

Um den HTTP-Inhalt zu komprimieren, haben wir die Gzip-Komprimierung auf unserem Server konfiguriert. Dies ermöglichte eine erhebliche Reduzierung der Dateigrößen, die an den Browser gesendet werden, und verbesserte so das LCP.

Die Gzip-Komprimierung ist eine Datendrucktechnik, die die Dateigröße reduziert, ohne Informationen zu verlieren. Dies ermöglicht eine schnellere Übertragung von Dateien und verbessert somit die Ladezeit von Seiten.

5. Optimierung von Bildern

– Betroffene Metriken: LCP –

Nicht optimierte Bilder können die Seitenladezeiten verlangsamen und sich negativ auf die LCP-Punktzahl auswirken. Daher haben wir besondere Aufmerksamkeit auf die Bildoptimierung gelegt, um die Leistung der Core Web Vitals zu verbessern.

Zur Optimierung von Bildern haben wir folgende Schritte unternommen:

• Wir haben die Bilder auf die tatsächlichen Abmessungen skaliert, in denen sie auf der Seite angezeigt werden sollen. Die Verringerung der physischen Abmessungen von Bildern kann ihre Dateigröße erheblich reduzieren und den Ladevorgang beschleunigen.
• Wir haben für jedes Bild ein geeignetes Komprimierungsformat verwendet. Zum Beispiel wurden Bilder mit wenigen Details und flachen Farben in Formate wie PNG oder SVG konvertiert, die für diese Art von Bildern eine bessere Komprimierung bieten. Bilder mit vielen Verläufen oder komplexen Details wurden in das JPEG-Format konvertiert, das für komplexe Bilder besser geeignet ist.
• Wir haben Bildkomprimierungstools verwendet, um die Dateigröße weiter zu reduzieren. Diese Tools reduzieren die Dateigröße, ohne visuelle Qualität zu verlieren.
• Wir haben eine progressive Bildkomprimierung implementiert, um die Benutzererfahrung während des Seitenladens zu verbessern. Die progressive Komprimierung ermöglicht die Anzeige einer Vorschau des Bildes, während es geladen wird, anstatt auf das vollständige Laden zu warten.

Die Optimierung von Bildern hatte einen erheblichen Einfluss auf die LCP-Punktzahl und die allgemeine Ladezeit von Seiten. Wir stellten eine deutliche Leistungsverbesserung fest, nachdem wir diese Optimierungen implementiert hatten.

6. Letzte Anpassungen

Nach Abschluss der vorherigen Schritte haben wir letzte Anpassungen vorgenommen, um die Core Web Vitals weiter zu optimieren.

Wir führten eine gründliche Analyse unserer Seiten durch, um weitere Probleme zu identifizieren, die sich auf die CWV-Punktzahl auswirken könnten. Zum Beispiel prüften wir, ob zusätzliche Skripte oder Ressourcen das Rendering blockierten oder die Interaktivität verzögerten.

Wir haben auch die Nutzung von Cookies auf unserer Website überprüft und die Anzahl der verwendeten Cookies minimiert, um Leistungseinbußen zu vermeiden.

Schließlich führten wir zahlreiche Tests durch und überwachten kontinuierlich die Leistung der Core Web Vitals mit Tools wie Google Search Console, PageSpeed Insights und Lighthouse.

Ergebnisse der Core Web Vitals-Optimierungen

Nachdem wir alle oben beschriebenen Optimierungen vorgenommen hatten, stellten wir eine deutliche Verbesserung der Core Web Vitals-Punktzahlen fest.

Die LCP-Punktzahl verbesserte sich erheblich mit einer Ladezeit von weniger als 2,5 Sekunden. Die FID-Punktzahl sank auf unter 100 Millisekunden, wodurch die Seite reaktionsfähiger auf Benutzereingaben wurde. Die CLS-Punktzahl blieb unter 0,1, was eine größere visuelle Stabilität gewährleistet.

Diese Verbesserungen hatten direkte Auswirkungen auf die Gesamtleistung der Seiten. Wir stellten eine deutliche Steigerung der organischen Klicks und Impressionen fest, was auf eine verbesserte Benutzererfahrung und eine bessere Platzierung im Google-Ranking hindeutet.

Die Optimierung von Core Web Vitals ist ein fortlaufender Prozess

Es ist wichtig zu betonen, dass die Optimierung der Core Web Vitals ein fortlaufender Prozess ist. Die Seitenperformance kann im Laufe der Zeit aufgrund neuer Änderungen oder Aktualisierungen beeinträchtigt werden. Daher ist es unerlässlich, die CWVs kontinuierlich zu überwachen und notwendige Korrekturen oder Verbesserungen vorzunehmen.

Wir werden die Core Web Vitals von link-assistant.com weiterhin im Auge behalten und bei Bedarf weitere Optimierungen implementieren. Eine gute Benutzererfahrung und ein hohes Google-Ranking sind entscheidend für den Erfolg unserer Website.

Schlussfolgerungen

Die Core Web Vitals sind zu einem wesentlichen Rankingfaktor für Google geworden. Die Optimierung der CWVs kann die Seitenperformance, die Benutzererfahrung und das Google-Ranking erheblich beeinflussen.

In unserer Fallstudie zu den Core Web Vitals haben wir gezeigt, wie wir die CWVs für link-assistant.com verbessert haben und wie uns dies geholfen hat, uns von einem plötzlichen Abfall im Ranking zu erholen.

Die von uns durchgeführten Optimierungen umfassen die Einrichtung geo-spezifischer Server und CDNs, das Verzögern von Drittanbieter-JS, die Optimierung der Schriftartenverwendung, das Extrahieren von kritischem CSS und JS, die Komprimierung von HTTP-Inhalten, die Bildoptimierung und die letzten Anpassungen.

Diese Optimierungen führten zu einer signifikanten Verbesserung der Core Web Vitals und wirkten sich positiv auf die Seitenperformance und die organischen Ergebnisse aus.

Denken Sie daran, dass die Optimierung der Core Web Vitals ein fortlaufender Prozess ist. Es ist wichtig, die Seitenperformance kontinuierlich zu überwachen, Korrekturen oder Verbesserungen vorzunehmen und sich über die neuesten Google-Richtlinien und Best Practices auf dem Laufenden zu halten, um eine optimale Benutzererfahrung und ein hohes Ranking zu gewährleisten.
Artikel von Link-Assistant

Pubblicato in Marketing, SEO