Core Web Vitals - grundlegende Web-Kennzahlen LCP, FID, CLS

Core Web Vitals sind ein neuer Google-Rankingfaktor. Er wurde Mitte 2020 bekannt gegeben und wird voraussichtlich ähnliche Auswirkungen auf die Suchergebnisse haben wie der Google-Pinguin-Algorithmus im Jahr 2012, der Spam aus dem Netzwerk entfernte. Warum erwähne ich das? Weil Core Web Vitals als Rankingfaktor gut optimierte, schnelle, effiziente, sichere und stabile Websites belohnen werden, während schlecht optimierte technische Websites mit schlechter Benutzererfahrung und überflüssigem Code bestraft werden. 

*Klarstellend geht es hier um große Websites oder extrem schlecht optimierte Seiten. Eine typische Seite mit "site:100" auf WordPress und Page Speed-Werten von 60:80 wird wahrscheinlich keine Änderung spüren. 

Ich denke, es ist an der Zeit, darüber nachzudenken, wo Ihre eigene Domain und Ihr Server gehostet werden (dies wurde ausführlich im Artikel "Wie man überprüft, wo eine Domain registriert ist und auf wen sie registriert ist" erläutert). Warum? Weil es ziemlich häufig vorkommt, dass jemand eine Rechnung nicht bezahlt und seine Seite deshalb gesperrt wird. Dies kann zu plötzlichen Abstürzen führen, denn für Googles Algorithmen ist Stabilität einer der wichtigsten Rankingfaktoren.

Core Web Vitals - Was ist das?

Core Web Vitals sind im Wesentlichen eine Reihe von Kennzahlen:

• Ladezeit: Largest Contentful Paint (LCP) 
• Interaktivität: First Input Delay (FID) 
• Visuelle Stabilität: Cumulative Layout Shift (CLS)

Noch einmal zur Frage, was sind Core Web Vitals? Es sind Faktoren, die Benutzererfahrungen und richtige, optimale Techniken zur Erstellung von Websites kombinieren, um das Surfen auf Websites angenehmer zu gestalten. Dies beinhaltet auch die Bestrafung für aufdringliche Werbung oder "flüchtige" Inhalte. Die Einführung von Core Web Vitals sollte nicht überraschend sein, denn in der SEO-Branche wird seit Jahren über "Mobile-Friendly" gesprochen, was nicht nur Responsive Design bedeutet, sondern auch die Verwendung optimaler Techniken zur Minimierung der Ladezeiten und Reduzierung des Datenverbrauchs. Warum? 

Das Internet auf Mobilgeräten ist heutzutage schnell, die Rechenleistung ist auch nicht niedrig, aber man darf einen sehr wichtigen Aspekt nicht vergessen, der die andere Seite der Medaille bei der Implementierung von Core Web Vitals ist... das sogenannte Crawl Budget 🙂 Sie fragen sich wahrscheinlich, was das miteinander zu tun hat? Ich erkläre es gleich. Man muss aus globaler Perspektive auf das Netzwerk schauen (am 2. Januar 2021 gab es über 1,83 Milliarden Websites). Das wird uns leicht verstehen lassen, dass eine schnelle und optimierte Website ein Geschenk für die Benutzer ist, aber auf ihre Weise versucht Google, seine Server zu entlasten, die tagsüber Milliarden von Daten verarbeiten. Angenommen, 10% des Internets optimieren ihre Websites gemäß den Richtlinien - die Einsparungen für Google wären astronomisch. Man darf auch nicht vergessen, dass Core Web Vitals-Kennzahlen in der Google Search Console verfügbar sind.

Search Page Experience - Zusammenfassung

Largest Contentful Paint (LCP) - Schlüsselwert 2,5 Sekunden - Core Web Vitals-Kennzahlen

LCP, das Laden des größten Inhalts der Website. Die Kennzahl scheint offensichtlich zu sein: Man öffnet eine Seite, wartet auf das Laden - am besten mit einem Stoppuhr 😉 - und hat die gemessene Ladezeit. 🙂 Nun, so einfach ist es nicht. Eine Website besteht nicht nur aus dem Front-End, sondern auch aus verschiedenen Skripten (z. B. JavaScript- oder jQuery-Bibliotheken), die oft auf unsichtbare Weise das vollständige Laden der Seite verzögern. Beachten Sie auch Websites, die Infinite Scroll verwenden. Es ist schwer hier von vollständigem Laden zu sprechen. 

In der Praxis misst LCP die Zeit bis zum Laden des größten Elements der Website. Das kann ein Bild, ein Video, Text usw. sein. Dabei sind die ersten 2,5 Sekunden entscheidend. In dieser Zeit sollte die Website bereit sein, vom Benutzer angenommen zu werden, ohne dass sich die Elemente verschieben. Die oben genannten Gründe erklären, warum dies die wahrscheinlichsten Szenarien sind.

Largest Contentful Paint - Core Web Vitals-Faktoren

Viele Menschen könnten auf die Idee kommen, einen besseren Hosting-Service zu wählen, anstatt teure technische Optimierung zu betreiben oder eine neue Website erstellen zu lassen. Wird diese Lösung funktionieren? Wahrscheinlich nicht. Zum Zeitpunkt des Schreibens dieses Artikels haben wir noch keine eindeutigen Tests durchgeführt. Ich kann mit ziemlicher Sicherheit sagen, dass diese Maßnahme sichtbare Ergebnisse in Form einiger Punkte bringen kann. Wenn jedoch Skripte von externen Websites mit überlasteten Bibliotheken geladen werden, nützt ein schneller Server nicht viel, da ein externer Faktor eine Rolle spielt. Um das etwas anschaulicher auszudrücken, könnten wir sagen: "Das Einsetzen eines Motors aus einem Kleinwagen in einen Porsche wird den Porsche nicht schneller machen, auch wenn er aerodynamisch geformt ist." Besondere Aufmerksamkeit sollte darauf gerichtet sein, komplexe Bibliotheken nur zu implementieren, um beispielsweise einen Slider oder ein Bild zu erstellen, das beim Klicken vergrößert wird, oder in WordPress 20 oder mehr Plugins zu installieren.

Auswirkungen des Servers/Hostings auf LCP

In dem Abschnitt, der sich direkt auf LCP bezieht, habe ich geschrieben, dass ein besserer Server eine schlechte Website nicht retten wird, und das behaupte ich mit voller Verantwortung, aber es gibt besondere Fälle, in denen ein Serverwechsel das Problem weitgehend lösen kann. Ihr denkt wahrscheinlich: "Wie kann das sein?" Dies gilt insbesondere für Websites, bei denen die technische Optimierung ordnungsgemäß durchgeführt wurde, aber die Ergebnisse immer noch unbefriedigend sind. In einem solchen Fall sollte man sich den technischen Lösungen des Servers zuwenden und sich fragen: Nutze ich ein Shared Hosting oder habe ich einen eigenen Server? Wahrscheinlich lautet die Antwort: Shared Hosting. Damit kommen wir zum Kern der Sache. Wenn jemand innerhalb eines Servers seinen Service intensiv nutzt, Spam versendet usw., dann belastet er einerseits den Server stark und provoziert andererseits Google dazu, eine Strafe auf die IP-Adresse zu setzen, was zu plötzlichen drastischen Abstürzen führen kann. Eine optimale Lösung ist die Nutzung eigener dedizierter Server, aber das bringt hohe Kosten mit sich, sowohl für den Kauf als auch für die Wartung.

Merkmale eines guten Hostings

Vor allem sollte man ein Hosting wählen, "mit dem man in Kontakt steht", und sicher sein, dass es mit zahlreichen Meinungen unterstützt wird, die besagen, dass es technische Probleme bewältigen und vor allem DDoS-Hackerangriffe abwehren kann. Derzeit erstellen Hostinganbieter häufig Backups der Daten ihrer Kunden und verfügen über beschleunigende Tools zum Laden von Daten wie LiteSpeed oder REDIS in WordPress sowie das HTTP/2-Protokoll, das die Leistung von Websites deutlich beschleunigen kann.

DDoS-Angriff

Wie optimiert man LCP:

• Volle Optimierung von Grafiken, Verwendung moderner und empfohlener Formate wie WebP 
• Optimierung der Serverantwortzeit
• Optimierung und Minimierung von CSS- und JS-Stilen.

First Input Delay (FID) - Aktion Reaktion - Core Web Vitals-Kennzahlen

First Input Delay, das bedeutet die Verzögerung der ersten Interaktion. In der Praxis ist dies die Zeit, die benötigt wird, damit eine Website nach einer Interaktion durch den Benutzer, z. B. dem Klicken auf eine URL, reagiert. Es wird die Zeit von der Interaktion bis zum vollständigen Laden der Seite gemessen.

First Input Delay - Core Web Vitals-Faktoren

Wie misst man FID:

• Ein guter FID-Wert liegt unter oder gleich 100 ms. 
• Ein FID-Wert, der verbessert werden muss: 101-300 ms. 
• Ein schlechter FID-Wert, der sofortige Reparatur erfordert: über 300 ms.

Laut Google wird ein niedriger FID-Wert durch schlecht optimierten und überladenen JavaScript-Code beeinflusst. Dies betrifft weitgehend vorgefertigte Lösungen, bei denen für die Implementierung einer einzigen Lösung eine ganze Bibliothek verwendet wird. Der Browser wird durch die Analyse des JavaScript-Codes blockiert, was zu Verzögerungen bei der Reaktion auf Benutzerinteraktionen führt.

Wie optimiert man FID:

• Aufteilung des Codes in kleinere Aktionen, insbesondere des JavaScript-Codes 
• Nutzung der Asynchronität 
• Festlegung und Implementierung der Prioritäten für das Laden von Inhalten 
• Verlagerung von Aktionen, die nicht mit der Benutzeroberfläche zusammenhängen, aus dem Hauptthread heraus.

Cumulative Layout Shift (CLS) - visuelle Stabilität - Core Web Vitals-Kennzahlen

Cumulative Layout Shift - kumulierte Layoutverschiebung. CLS ist eines der interessanteren Elemente des CWV, das auf den Benutzer ausgerichtet ist. Dieser Indikator bestimmt, inwieweit sich das Layout der Seite aufgrund unerwarteter Ereignisse und Verhaltensweisen auf dem Bildschirm verschoben hat. Es geht um Verschiebungen, die nicht mit der Benutzerinteraktion zusammenhängen und die auf programmierungsbedingte Probleme zurückzuführen sind. 

Oft kann bereits nach dem Aktualisieren der Seite festgestellt werden, was Probleme mit der Verschiebung auf der Seite verursacht. Eine genauere Analyse ist mit Hilfe von Debugging-Tools für die Website möglich.

Cumulative Layout Shift - Core Web Vitals-Faktoren

Die CLS-Werte werden wie folgt bewertet:

Ein Wert kleiner oder gleich 0,1 wird als gut bewertet, über 0,25 als schlecht.

Anzeige der CLS in der Google Search Console

Häufige Ursachen für CLS-Probleme:

• Bewegliche Anzeigen, die schwer zu deaktivieren sind 
• Bilder ohne Abmessungen (width; height) - häufig ein Programmierkonflikt, da in den aktuellen Standards des Responsive Web Design (RWD) die Raster proportional angepasst werden, und die Bilder selbst das <div>-Element ausfüllen sollen, das in Media Queries oder z. B. im Bootstrap-Raster eine bestimmte Größe hat. Meiner Meinung nach ist dies ein Rückschritt, da Google lineare Größen bevorzugt, da es das Bild und den CSS-Code nicht analysieren muss - es hat alles "auf dem Tablett", 
• dynamische Inhalte, die mit JavaScript-Code generiert werden.

Wie man CLS optimiert:

• Vermeide Inline-Styles 
• Wenn deine Website Anzeigen enthält - verschiebe sie von der Oberseite der Seite in die Mitte oder nach unten 
• des Inhalts IFrame-Elemente in Divs oder Abschnitten mit festen Abmessungen einbetten 
• Verwende Bilder mit im Code angegebenen Abmessungen.

Core Web Vitals-Simulator - Lighthouse Scoring Calculator

Unter dieser Adresse steht das Lighthouse Scoring Calculator-Tool zur Verfügung, das die Simulation von Daten zur Seitengeschwindigkeit und den CWV ermöglicht.

Lighthouse Scoring Calculator

PageSpeed Insights - Messdaten

PageSpeed Insights misst folgende Daten:

• First Contentful Paint (Erstes Inhaltsrendering)
• Speed Index (Geschwindigkeitsindex)
• Largest Contentful Paint (Größtes Inhaltsrendering)
• Time to Interactive (Zeit bis zur vollständigen Interaktivität)
• Total Blocking Time (Gesamte Blockierungszeit)
• Cumulative Layout Shift (Kumulierte Layoutverschiebung)

PageSpeed Insights - Messdaten

First Contentful Paint (Erstes Inhaltsrendering) - FCP 

FCP misst die Zeit, die der Browser benötigt, um das erste Fragment des DOM-Inhalts nach dem Betreten der Seite durch den Benutzer anzuzeigen. Das erste Inhaltsrendering umfasst:

• Serverantwortzeit (TTFB) 
• Ladezeit des Inhalts und Renderzeit

Speed Index (Geschwindigkeitsindex)

Der Geschwindigkeitsindex dient zur Messung der Anzeige des Seiteninhalts während des Ladevorgangs. Lighthouse zeichnet ein Video mit dem Laden der Website auf und berechnet den Fortschritt zwischen den Frames.

Möglichkeiten zur Verbesserung des Geschwindigkeitsindex:

• Optimierung des JavaScript-Codes 
• Optimierung von Bildern und Anzeige im "Lazy Loading"- Modus
• Cache-Nutzung

Time to Interactive (Zeit bis zur vollständigen Interaktivität) (TTI)

Dies ist die Zeit, die benötigt wird, um die Seite so zu laden, dass der Benutzer sie verwenden und mit den sichtbaren Elementen interagieren kann.

Total Blocking Time (Gesamte Blockierungszeit) - TBT

Dies ist die Gesamtzeit, die die geladenen Ressourcen blockiert haben. Es wurde durch FID ersetzt. 

Time to first byte (Zeit bis zum ersten Byte) - TTFB 

Time to first byte ist ein Wert, der in Mikrosekunden angegeben wird und ursprünglich auf Engpässe im Ladevorgang der Seite hinweisen sollte. TTFB misst die Zeit vom Zeitpunkt der Anfrage an den Server bis zum Erhalt der ersten Datenbytes. In der Praxis ist dies eine der beliebtesten Methoden zur Messung der Ladegeschwindigkeit einer Seite, aber sie enthält einige Feinheiten, die diesen Prozess erheblich verlangsamen können und nicht zwangsläufig auf den Server selbst zurückzuführen sind, sondern auf eine fehlerhafte Architektur der Anwendung / Seite. TTFB ist definitiv keine angemessene Methode zur Messung der Serverleistung, es passt viel besser als ein Tool zur Messung der Website-Optimierung.

Möglichkeiten zur Verbesserung von TTFB

• Optimierung und Verkürzung der Serverreaktionszeit (TTFB) 
• Optimierung der Architektur 
• der Website Implementierung einer CDN 
• Vermeidung von mehrfachen Umleitungen.

Messwerkzeuge für Core Web Vitals und die Ladegeschwindigkeit von Websites

• Google PageSpeed Insights - Einfach die URL der Seite einfügen und auf "ANALYSIEREN" klicken, um einen Geschwindigkeitsbericht der Seite und technische Probleme im Zusammenhang mit schlechter Codeoptimierung zu erhalten.
• Test My Site mit Think with Google - Dieses Tool dient zur Analyse der Geschwindigkeit der Seite auf Mobilgeräten. Einfach den Link einfügen und Enter drücken. Eine interessante Funktion ist die Möglichkeit, die Ladegeschwindigkeit unserer Website mit der Website der Konkurrenz zu vergleichen.
• web.dev - ein Tool, das Page Speed und Lighthouse sehr ähnelt. Es misst die Interaktionszeit, die Serverantwort und "Leistung", "Barrierefreiheit", "Best Practices" und "SEO". Web.Dev gibt auch Hinweise zur Beschleunigung des Seitenladens. Lighthouse - funktioniert im Chrome-Browser (Rechtsklick -> Untersuchen -> Lighthouse). Um dieses Tool zu nutzen, müssen Sie die Seite aufrufen, die Sie überprüfen möchten. Google Analytics -> Bericht "Seitengeschwindigkeit"
• WebPage Test - ermöglicht die Auswahl des Standorts und des Browsertyps, mit dem Tests durchgeführt werden sollen.
• Pingdom Website Speed Test - ein übersichtliches Tool, das die Ladezeit, Blockierung, DNS-Antwortzeit anzeigt und die Möglichkeit bietet, den Standort auszuwählen.
• Load Impact - ermöglicht die Überprüfung der Geschwindigkeit einer Website je nach Anzahl der Benutzer, die die Website besuchen.
• GTMetrix - ein äußerst funktionsreiches Analysetool. Ein Pluspunkt ist die Möglichkeit, PDF-Berichte zu erstellen.
• DotCom - führt Messungen für verschiedene Standorte durch. Super! Monitoring - kombiniert Daten von Page Speed und Lighthouse.
• Sucuri Load Time Tester - zeigt Informationen zur Verbindungsgeschwindigkeit und zum Zeitpunkt des ersten Datenbytes. Es ermöglicht Messungen von verschiedenen Standorten.
• Website Speed Test Uptrends - zeigt Informationen zur Gesamtladezeit der Seite.

Page Speed Inside - typische Mitteilungen

1. Entfernen Sie ungenutzten CSS-Code 
2. Minimieren Sie CSS 
3. Verzögern Sie das Laden von Bildern außerhalb des Bildschirms 
4. Zeigen Sie Bilder in neuen Formaten
5. Sie keine passiven Detektoren zur Verbesserung des Scrollens 
6. Ändern Sie die Größe von Bildern 
7. Vermeiden Sie mehrfache Umleitungen 
8. Beseitigen Sie blockierende Ressourcen 
9. Entfernen Sie ungenutztes JavaScript 
10. Vermeiden Sie sehr große Netzwerklasten 
11. Verwenden Sie effiziente Bildcodierung 
12. Minimieren Sie die Aktivität des Hauptthreads 
13. Stellen Sie Text während des Ladens von Webfonts sichtbar 
14. Vorladen wichtiger Anfragen 
15. Zeigen Sie statische Ressourcen mit effizienten Cache-Richtlinien an 
16. Verkürzen Sie die Ausführungszeit von JavaScript
17. Vermeiden Sie ein zu großes DOM 
18. Vermeiden Sie das Erstellen von langen Ketten von kritischen Anfragen Die Anzahl der Anfragen und die übertragenen Daten sollten gering sein 
19. Minimieren Sie JavaScript 
20. Aktivieren Sie die Textkompression 
21. Bauen Sie zuvor Verbindungen zu erforderlichen Quellen auf 
22. Verwenden Sie Videoformate für Animationen 
23. Verwenden Sie keine Anweisungen document.write()

Fazit

Core Web Vitals sind ein klares Signal an Website-Besitzer, was sie verbessern sollten. Mit Hilfe von Messinstrumenten wie Page Speed oder Lighthouse erhalten sie praktisch alle Informationen. Google fördert auf diese Weise indirekt die Optimierung von Websites durch Verbesserung des Codes, Optimierung von Grafiken und Verwendung nur notwendiger Skripte auf der Seite. Mit hoher Wahrscheinlichkeit wird dies zu einer größeren Beteiligung von SEO-Spezialisten am Prozess der Website-Erstellung führen. Derzeit wurden sie oft übergangen, und als Ergebnis haben die Entwickler eine bequeme und leistungsstarke Lösung verwendet, die nicht unbedingt für Suchmaschinen optimiert ist. Der Kunde erhielt eine Website, die einerseits funktionierte, aber deren Optimierungsergebnisse wie ein Anker waren, der die Website außerhalb der Top 10 in den Suchergebnissen hielt. Natürlich kann man hier ein zweites Gesicht sehen - nicht optimierte Websites müssen in Google Ads-Kampagnen investieren - und dies sind wahrscheinlich größere Beträge als bei der optimierten Konkurrenz (Qualitätsfaktor). Infolgedessen gleicht Google die zusätzliche Zeit für die Indizierung aus. Schließlich werden Websites für Kunden erstellt, um zu verkaufen, und nicht nur, um im Internet zu sein. CWV sollte bereits bei der Gestaltung berücksichtigt werden, wenn wir davon ausgehen, dass unser Geschäft sichtbar und die Konversionsrate maximal niedrig sein soll.

[Aktualisierung] Die Daten zur Bewertung der Core Web Vitals-Kennzahlen wurden gemäß den Richtlinien von Google vom 17.02.2021 aktualisiert.

Autor: Łukasz Pietruszka