Mit Core Web Vitals will Google die Webleistung verbessern. Warum? Weil das Geschäft von Google überwiegend webbasiert ist – langsame Webseiten und Webanwendungen zwingen die Nutzerinnen und Nutzer dazu, auf native Apps zurückzugreifen.
Deine Platzierung in den Google-Suchergebnissen wird größtenteils durch die Schlüsselwörter des Suchbegriffs, die Verwendung dieser Schlüsselwörter auf deiner Seite und die Popularität deiner Seite anhand der Anzahl (und Qualität) der Links von anderen Seiten bestimmt. Ab August 2021 wird Google versuchen, Seiten auch nach ihrer Leistung zu bewerten.
Dieser Artikel zeigt dir, wie du deine Seite für die Core Web Vitals von Google optimieren kannst.
Warum Core Web Vitals?
Der Inhalt bleibt entscheidend. Aber wenn du zwei Webseiten mit ähnlichem Text und ähnlicher Popularität vergleichst, wird diejenige, die das beste Web-Erlebnis bietet, in den Google-Suchergebnissen höher eingestuft.
Neben einem verbesserten Page Rank können leistungsstarke Webseiten auch in das Karussell für die mobile Suche aufgenommen werden. Dies war bisher den Accelerated Mobile Pages (AMP) vorbehalten, für die du Inhalte auf eine separate, von Google gehostete Webseite portieren musstest. AMP hat Kritik auf sich gezogen, vor allem weil die Seiten nicht immer schneller sind als eine gut optimierte WordPress- oder statische Webseite. Das ist aber keine Voraussetzung mehr.
Egal, wofür du dich entscheidest, je schneller und reaktionsschneller deine Seite ist, desto größer sind die Chancen, dass sie in den Google-Suchergebnissen besser platziert wird.
Wenn du bedenkst, dass eine durchschnittliche Seite etwa 2 MB groß ist, mehr als 60 HTTP-Anfragen stellt und 16 Sekunden braucht, um auf einem mobilen Gerät vollständig dargestellt zu werden, wird dir klar, dass es einiges an Verbesserungsmöglichkeiten für deine Webseite gibt. Wir zeigen dir, wie du diese Verbesserungen am besten erreichen kannst.
Die wichtigsten Ranking-Faktoren von Google
Es gibt vier wichtige Ranking-Faktoren, die du prüfen solltest, bevor du mit der Leistungsbewertung beginnst:
- HTTPS: HTTPS ist unerlässlich. Stellt deine Webseite eine sichere Verbindung zwischen dem Browser des Nutzers und dem Webserver her?
- Mobilfreundlichkeit: Deine Webseite muss auf einem mobilen Gerät gut funktionieren. Ist deine Seite auch auf Geräten mit kleinen Bildschirmen nutzbar? Wird sie ohne Inhaltsüberlauf dargestellt? Ist der Text groß genug? Sind die klickbaren Bereiche groß genug für die Touch-Steuerung?
- Keine Interstitials: Vermeide aufdringliche Interstitials, die unangemessen viel Platz auf dem Bildschirm beanspruchen. Ist dein Inhalt immer lesbar? Wird er teilweise von Pop-up-Interstitials oder Bannern verdeckt? Erschweren deine Werbung oder Marketingaktionen die Nutzung der Webseite?
- Sicheres Surfen: Deine Webseite sollte frei von Malware, Viren, Phishing, Betrug und anderen Betrügereien sein.
Sobald du diese Anforderungen erfüllst, wird deine Webseite auf ihre Leistungsfähigkeit geprüft.
Wie bewertet Google die Webleistung?
Es ist wichtig, dass deine Webseite schnell lädt, schnell gerendert wird und schnell reagiert. Aber fühlt es sich für die Nutzer auch schnell an?
Anwendungen zur Leistungsmessung wie die Browser DevTools melden technische Messwerte wie:
- Blockierzeit: Die Zeit, die damit verbracht wird, auf den Start eines Downloads zu warten, in der Regel weil andere Inhalte wie Stylesheets und Skripte eine höhere Priorität haben.
- DNS-Auflösung: Die Zeit, die benötigt wird, um einen Hostnamen in eine IP-Adresse aufzulösen, um ein Asset abzurufen.
- Verbindungszeit: Die Zeit für die Initialisierung einer TCP-Verbindung.
- Zeit bis zum ersten Byte (TTFB): Die Gesamtzeit zwischen der Anfrage und dem ersten Byte der Antwort.
- Empfangszeit: Die Zeit, um das gesamte Asset abzurufen.
- DOM-Ladezeit: Die Zeit für das Herunterladen und Rendern des HTML Document Object Model. Dies ist normalerweise der erste Zeitpunkt, an dem Skripte, die das DOM analysieren oder verändern, zuverlässig ausgeführt werden können.
- Seitenladezeit: Die Zeit, die benötigt wird, um die Seite und alle Assets wie Bilder, Stylesheets, Skripte und so weiter herunterzuladen.
- Gesamtgewicht der Seite: Die Gesamtgröße aller Assets. Sie wird oft sowohl als komprimierte (Download) als auch als unkomprimierte Größe angegeben.
- Die Anzahl der DOM-Elemente: Die Gesamtzahl der HTML-Elemente auf der Seite. Je mehr Elemente, desto länger dauert es, die Seite zu verarbeiten.
- First Contentful Paint (FCP): Die Zeit, die vergeht, bis der Browser das erste Inhaltspixel rendert.
- Erstes aussagekräftiges Bild (FMP): Die Zeit, die vergeht, bis der primäre Seiteninhalt für den Nutzer sichtbar wird.
- Time to Interactive (TTI): Die Zeit, die vergeht, bis eine Seite vollständig interaktiv ist und zuverlässig auf Benutzereingaben reagieren kann.
- Erste CPU-Ladezeit: Die Zeit, die die CPU benötigt, um die Seite zu rendern und alle Initialisierungsskripte auszuführen und auf weitere Eingaben zu warten.
- CPU-Nutzung: Die Verarbeitungsaktivität, die erforderlich ist, um die Seite zu rendern und auf Benutzereingaben zu reagieren.
- Layouts pro Sekunde: Die Rate, mit der der Browser Stile und Seitenlayouts neu berechnen muss.
Mit ihnen lassen sich bestimmte Engpässe wie Serverlast, CMS-Caching, Browser-Caching, Download-Geschwindigkeiten und JavaScript-Effizienz ermitteln. Aber sie können nicht feststellen, ob eine Seite ein gutes oder schlechtes Nutzererlebnis bietet. Ein Beispiel:
- Eine App kann schnell heruntergeladen und angezeigt werden, aber nach der ersten Interaktion nicht mehr reagieren, weil sie eine große Menge an nicht optimiertem JavaScript-Code ausführt.
- Eine Chat-Anwendung könnte ständig Daten herunterladen, während die Nutzer Nachrichten schreiben. Ein Bewertungstool könnte annehmen, dass der Ladevorgang nie abgeschlossen wurde, obwohl die Seite ansprechbar ist.
Core Web Vitals ist Googles Versuch, dieses Dilemma zu lösen.
Was sind Core Web Vitals?
Die Core Web Vitals (CWV) von Google sind drei Leistungskennzahlen, die das reale Nutzererlebnis bewerten:
- Largest Contentful Paint (LCP): Ladeleistung
- Erste Eingabeverzögerung (FID): Interaktivitätsleistung
- Kumulative Layout-Verschiebung (CLS): Leistung der visuellen Stabilität
Dieses neue Google-Algorithmus-Update wird ab Ende August 2021 weltweit ausgerollt. Die Core Web Vitals-Kennzahlen wirken sich in erster Linie auf die mobilen Suchergebnisse aus, aber die Desktop-Äquivalente werden folgen, wenn das Experiment erfolgreich ist.
Die LCP-, FID- und CLS-Werte einer Seite basieren auf den echten Nutzermessungen der letzten 28 Tage, die anonym über den Chrome-Browser gesammelt wurden. Diese Messwerte können aufgrund des Geräts, der Verbindung und anderer gleichzeitiger Aktivitäten des Nutzers variieren, daher wird das 75ste Perzentil und nicht der Durchschnitt berechnet.
Mit anderen Worten: Die Messwerte aller Nutzer/innen werden vom besten zum schlechtesten sortiert, und der Wert am Dreiviertelpunkt wird genommen. Drei von vier Website-Besuchern werden also dieses Leistungsniveau oder mehr erreichen.
Jede Seite, die bei allen drei Core Web Vitals-Kennzahlen einen guten (grünen) Wert erreicht, wird in den Suchergebnissen höher eingestuft und in das Karussell der „Top Stories“ in der Google News-App aufgenommen.
In den folgenden Abschnitten beschreiben wir den Algorithmus, der zur Berechnung einer Kennzahl verwendet wird, die Tools, mit denen du den Wert einer Seite ermitteln kannst, typische Ursachen für niedrige Werte und die Schritte, die du unternehmen kannst, um Leistungsprobleme zu beheben.
Largest Contentful Paint (LCP)
Largest Contentful Paint misst die Ladeleistung. Im Wesentlichen geht es darum, wie schnell nutzbare Inhalte auf der Seite gerendert werden.
LCP analysiert, wie lange es dauert, bis das größte Bild oder der größte Textblock innerhalb des Browserfensters (above the fold) sichtbar wird. In den meisten Fällen ist das prominenteste Element ein Hero-Bild, ein Banner, eine Überschrift oder ein großer Textblock.
Jedes der folgenden Elemente kommt für die Analyse von Largest Contentful Paint in Frage:
- Bilder (
<img>-Element) - Bilder in Vektorgrafiken (ein
<image>eingebettet in eine<svg>) - Video-Thumbnails (ein Poster-Attribut, das auf eine Bild-URL innerhalb eines
<video>-Elements gesetzt ist) - Elemente mit Hintergrundbildern (typischerweise mit der CSS-Eigenschaft
background-image url()geladen) - Block-Level-Elemente, die Text enthalten
Seiten, bei denen das Largest Contentful Paint innerhalb der ersten 2,5 Sekunden nach dem Laden der Seite abgeschlossen ist, gelten als gut (grün). Seiten, die länger als 4,0 Sekunden dauern, gelten als schlecht (rot):
Largest Contentful Paint Analyse Tools
LCP ist die am einfachsten zu verstehende Metrik von Core Web Vital, aber es ist vielleicht nicht offensichtlich, welches Element für die Analyse ausgewählt wird.
Das DevTools Lighthouse Panel wird in Chromium-basierten Browsern wie Chrome, Edge, Brave, Opera und Vivaldi bereitgestellt. Öffne DevTools über das Browsermenü – normalerweise über Mehr Tools > Entwicklertools oder die Tastaturkürzel Strg | Cmd + Shift + i oder F12 – und navigiere dann zur Registerkarte Lighthouse (in älteren Versionen heißt sie vielleicht Audit).
Erstelle einen Bericht über die mobile Leistung und untersuche den daraus resultierenden Leistungsabschnitt. Die größte inhaltsreiche Paint-Time wird mit einem erweiterbaren Abschnitt angezeigt, der das ausgewählte Element identifiziert:
Du kannst die gleichen Informationen mit den Online-Tools PageSpeed Insights und web.dev Measure generieren, wenn du keinen Zugang zu einem Chromium-basierten Browser hast:
Das DevTools Performance Panel zeigt auch eine LCP-Anzeige an. Klicke zum Starten auf das runde Aufzeichnungssymbol, lade deine Seite neu und klicke dann auf die Schaltfläche Stopp, um den Bericht anzuzeigen. Klicke auf das LCP-Symbol im Abschnitt Timings, um das Element zu identifizieren und eine Zusammenfassung der Statistiken anzuzeigen.
Die Web Vitals Erweiterung ist für Google Chrome verfügbar, kann aber auf den meisten Chromium-basierten Browsern installiert werden. Sie berechnet die Core Web Vitals-Kennzahlen für jede Webseite, die du besuchst, und ihr Symbol wird je nach Ergebnis grün, orange oder rot. Du kannst auch auf das Symbol der Erweiterung klicken, um weitere LCP-Details anzuzeigen:
In der Google Search Console gibt es jetzt einen Abschnitt Core Web Vitals, wenn deine Webseite als Eigenschaft hinzugefügt wurde. Der Bericht zeigt, wie sich die CWV-Kennzahlen im Laufe der Zeit verändert haben. Beachte, dass er keine spezifischen LCP-Kennzahlen enthält und dass nur Webseiten mit relativ hohem Traffic verfügbar sind:
Mit dem Chrome User Experience Report kannst du echte Nutzungsstatistiken, einschließlich LCP über verschiedene Länder, Verbindungen und Geräte hinweg, für eine bestimmte URL abfragen. Da es sich um ein öffentliches Projekt auf Google BigQuery handelt, musst du dich für ein Google Cloud Platform-Konto anmelden und deine Rechnungsdaten angeben. Auch hier ist der Bericht nur dann nützlich, wenn eine URL ein relativ hohes Verkehrsaufkommen hat.
Die web-vitals JavaScript-Bibliothek schließlich ist ein kleines 1 kB großes Skript, das LCP und andere Core Web Vital-Kennzahlen für echte Nutzer/innen auf deiner Live-Site berechnen kann. Da es von einem CDN heruntergeladen werden kann, kannst du das folgende Skript in deinen HTML <head> einfügen:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() ist eine asynchrone Funktion, der ein Callback übergeben wird, der ausgelöst wird, wenn der LCP-Wert berechnet wurde (obwohl er möglicherweise nie ausgelöst wird, wenn die Seite in einem Hintergrund-Tab geladen wird). Der Callback-Funktion wird ein Objekt übergeben, das Folgendes enthält:
name: der Name der Metrik („LCP“ in diesem Fall)Wert: der berechnete Wertid: eine eindeutige ID, die diese Metrik für die aktuelle Seite repräsentiertdelta: das Delta zwischen dem aktuellen Wert und dem zuletzt gemeldeten WertEinträge: ein Array von Einträgen, die bei der Wertberechnung verwendet werden
Das obige Skript gibt das Objekt in der Konsole aus, obwohl es praktischer ist, die Daten zur weiteren Analyse an einen Server oder Google Analytics zu senden.
Häufige Ursachen für schlechte Largest Contentful Paint Scores
Schlechte LCP-Bewertungen werden in der Regel durch langsam ladende Seiten verursacht, die verhindern, dass der größte Block schnell angezeigt wird:
- Die Antwort des Servers könnte langsam sein, weil er überlastet ist oder zu viel Arbeit hat, um eine Seite zu berechnen. Das muss nicht unbedingt die Schuld deiner Webseite sein – es kann auch an Serverbeschränkungen liegen, wenn du einen Shared Hosting Service
- CSS und JavaScript, die das Rendering blockieren, können das Laden der Seite verzögern, wenn sie im HTML-Code oberhalb des Hauptinhalts referenziert werden.
- Andere Ressourcen wie große Bilder und Videos können die verfügbare Bandbreite reduzieren und das Rendern verlängern.
- Auch Seiteninhalte, die auf dem Client und nicht auf dem Server erstellt werden, brauchen länger, um zu erscheinen.
Wie man den größten Contentful Paint Scores verbessert
Eine gründliche Prüfung kann Ladeprobleme aufdecken, aber in der Regel geht es darum, die Menge der an den Browser gesendeten Daten zu reduzieren. Die folgenden Tipps helfen dir, deinen LCP-Wert zu verbessern:
- Aktualisiere deinen Server und/oder Hosting-Service. Stelle sicher, dass die Download-Geschwindigkeiten auch in Zeiten hoher Auslastung schnell bleiben.
- Aktiviere die Serverkomprimierung und HTTP/2+. Es gibt keinen Grund, es nicht zu tun!
- Reduziere den Serveraufwand. Entferne ungenutzten Code und CMS-Plugins und aktiviere dann effektives Caching.
- Stelle sicher, dass der Browser Dateien effektiv zwischenspeichern kann. Setze geeignete Expires, Last-Modified und/oder ETag-Hashes in den HTTP-Header, damit Dateien nicht erneut angefordert werden.
- Nutze ein Content Delivery Network (CDN), um die Last zu verteilen und die Dateien auf Servern zu hosten, die geografisch näher bei den Nutzern liegen.
- Optimiere deinen Code, indem du die im Dashboard von MyKinsta integrierte Funktion zur Minimierung des Codes nutzt.
- Optimiere deine Bilder. Verkleinere sie auf ihre kleinsten Abmessungen und verwende ein geeignetes Format, um die Dateigröße zu minimieren. Stelle sicher, dass jedes Bild im größten Inhaltsblock so früh wie möglich angefordert wird; ein Preload kann dabei helfen.
- Füge ein
loading="lazy"-Attribut hinzu, um das Laden von Bildern zu verzögern. Füge Attribute für Breite und Höhe hinzu, um sicherzustellen, dass ein angemessener Platz auf der Seite reserviert wird, bevor das Bild fertig geladen ist. - Minimiere die Anfragen von Drittanbietern und ziehe in Erwägung, Assets auf deine Hauptdomain zu verschieben, um unnötige DNS-Abfragen zu vermeiden.
- Minimiere die Anzahl und Größe der angeforderten Dateien, besonders am Anfang deiner HTML-Seite.
- Achte darauf, dass du nur die erforderlichen Webschriften lädst. Wechsle zu websicheren Schriftarten für maximale Leistung.
- Entferne ungenutzte JavaScript- und CSS-Dateien.
- Verkette und minimiere deine JavaScript- und CSS-Dateien.
- Vermeide CSS @import-Anweisungen – sie blockieren den Rendervorgang und laden Stile nacheinander.
- Vermeide Base64-Kodierung – sie erhöht die Dateigröße und erfordert zusätzliche Verarbeitung.
- Berücksichtige kritisches Inline-CSS. Binde wichtige „above-the-fold“-CSS in einen
<link>-Block am Anfang der Seite ein und lade dann weitere Stylesheets asynchron. - Verwende asynchrones, zeitversetztes oder ES-Modul-JavaScript, um Skripte später auszuführen. Führe langlaufende JavaScript-Prozesse in einem Service Worker aus.
Erste Eingabeverzögerung (FID)
Die erste Eingabeverzögerung misst die Reaktionsfähigkeit deiner Seite. Im Wesentlichen geht es darum, wie schnell sie auf Benutzeraktionen wie Klicken, Tippen und Scrollen reagiert.
Die FID-Kennzahl wird als die Zeit zwischen der Benutzerinteraktion und der Verarbeitung der Anfrage durch den Browser berechnet. Sie misst nicht die Zeit für die Ausführung der Handler-Funktion, die normalerweise die Eingaben verarbeitet und das DOM aktualisiert.
Seiten mit einer FID-Zeit von 100 Millisekunden oder weniger werden als gut (grün) eingestuft. Seiten, die 300 Millisekunden überschreiten, gelten als schlecht (rot):
First Input Delay Analyse-Tools
Die erste Eingabeverzögerung kann nicht simuliert werden, da sie nur gemessen werden kann, wenn die Seite einem tatsächlichen Benutzer angezeigt wird, der mit der Seite interagiert. Das Ergebnis ist daher abhängig von der Prozessorgeschwindigkeit und den Fähigkeiten des jeweiligen Geräts.
Die FID wird weder im DevTools Lighthouse Panel noch in PageSpeed Insights berechnet. Sie können jedoch die Total Blocking Time (TBT) ermitteln. Dies ist ein guter Näherungswert für die erste Eingabeverzögerung. Sie misst die Differenz der Zeit zwischen:
- der First Contentful Paint (FCP), d. h. der Zeitpunkt, an dem der Seiteninhalt zu rendern beginnt, und
- Die Time to Interactive (TTI), d.h. die Zeit, in der die Seite auf Benutzereingaben reagieren kann. Die TTI wird angenommen, wenn keine langwierigen Aufgaben aktiv sind und weniger als drei HTTP-Anfragen noch nicht abgeschlossen sind.
Die Web Vitals-Erweiterung für Google Chrome kann auch eine FID-Metrik anzeigen, nachdem du mit der Seite durch Scrollen oder Klicken interagiert hast. Klicke auf das Symbol der Erweiterung, um mehr Informationen zu erhalten:
Wie LCP ermöglicht auch der Chrome User Experience Report die Abfrage echter FID-Statistiken, die über verschiedene Länder, Verbindungen und Geräte für eine bestimmte URL aufgezeichnet wurden.
Die JavaScript-Bibliothek von web-vitals kann auch FID-Metriken für echte Nutzer/innen auf deiner Live-Site berechnen. Du kannst das folgende Skript in deinen HTML <head> einfügen, um FID-Metriken an eine Callback-Funktion auszugeben:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Häufige Ursachen für schlechte First Input Delay Scores
Schlechte FID- und TBT-Werte werden in der Regel durch clientseitigen Code verursacht, der den Prozessor auslastet, wie z. B:
- Erhebliche Mengen an CSS und JavaScript, die den Rendering-Prozess blockieren und das Laden der Seite aufhalten, während der Code heruntergeladen und analysiert wird
- Große, prozessintensive Skripte, die sofort ausgeführt werden, wenn die Seite geladen wird
- Langwierige oder schlecht optimierte JavaScript-Aufgaben
Standardmäßig laufen Browser auf einem einzigen Thread, der immer nur eine Aufgabe auf einmal bearbeiten kann. Wenn eine JavaScript-Funktion eine Sekunde für die Ausführung braucht, werden alle anderen Rendering-Prozesse während dieser Sekunde blockiert. Die Seite kann nicht auf Benutzereingaben reagieren, das DOM nicht aktualisieren, keine Animationen anzeigen usw. Selbst GIF-Animationen können in älteren Browsern blockiert werden.
Wie du die Werte für die erste Eingabeverzögerung verbesserst
Ein clientseitiger JavaScript-Audit kann Probleme aufdecken, aber im Allgemeinen geht es darum, überflüssigen Code zu entfernen und sicherzustellen, dass Aufgaben schnell ausgeführt werden.
Die folgenden Tipps helfen dir, deinen FID-Wert zu verbessern:
- Erstelle so viele statische HTML-Inhalte wie möglich auf dem Server und speichere sie ab. Versuche, dich nicht auf clientseitige JavaScript-Frameworks zu verlassen, um das gleiche HTML für alle zu rendern.
- Stelle sicher, dass der Browser Dateien effektiv zwischenspeichern kann. Setze geeignete Expires-, Last-Modified– und/oder ETag-Hashes in den HTTP-Header, damit Dateien nicht erneut angefordert werden.
- Setze Techniken zur progressiven Verbesserung ein, damit die Oberfläche in HTML und CSS nutzbar ist, bevor JavaScript ausgeführt wird.
- Entferne ungenutzte JavaScript- und CSS-Dateien.
- Verkette und minimiere deine JavaScript- und CSS-Dateien.
- Vermeide die übermäßige Verwendung von teuren CSS-Eigenschaften wie box-shadow und filter.
- Verwende asynchrones, zeitversetztes oder ES-Modul-JavaScript, um Skripte später auszuführen.
- Minimiere die JavaScript-Anfragen von Drittanbietern für Analysen, Social Media Widgets, Diskussionsforen usw. Diese können sich schnell zu mehreren Megabyte JavaScript summieren.
- Lasse JavaScript-Komponenten bei Bedarf nachladen, z. B. Chat-Widgets, Video-Player usw.
- Verzögere das Laden von weniger wichtigen Skripten wie Analysen, Werbung und Social-Media-Tools.
- Unterteile langlaufende JavaScript-Aufgaben in eine Reihe kleinerer Jobs, die nach einer kurzen requestIdleCallback-, setTimeout– oder requestAnimationFrame-Verzögerung ausgeführt werden.
- Erwäge, lang laufende JavaScript-Prozesse in einem Webworker auszuführen, der einen Hintergrund-Thread verwendet.
Kumulative Layout-Verschiebung (CLS)
CLS misst die visuelle Stabilität der Seite. Im Wesentlichen geht es darum, ob sich der Seiteninhalt unerwartet bewegt oder springt, vor allem beim ersten Laden?
CLS berechnet eine Punktzahl, wenn sich Elemente ohne Vorwarnung oder Benutzerinteraktion bewegen. Du hast das sicher schon erlebt, wenn du einen Artikel auf einem mobilen Gerät liest – der Text springt plötzlich aus dem Bildschirm und du verlierst deinen Platz. In den schlimmsten Fällen klickst du auf einen falschen Link.
CLS-Probleme treten vor allem dann auf, wenn ein großes Bild oder eine Werbung oberhalb der aktuellen Scroll-Position geladen wird und eine Null-Höhe-Fläche sofort um mehrere hundert Pixel wächst.
Cumulative Layout Shift Scores werden berechnet, indem die folgenden Kennzahlen miteinander multipliziert werden:
- Die impact fraction: Dies ist die Gesamtfläche aller instabilen Elemente im Ansichtsfenster, d. h. derjenigen, die „springen“ werden. Wenn Elemente, die 60 % des Sichtfensters einnehmen, während des Ladens der Seite verschoben werden, beträgt der Auswirkungsanteil 0,6. Beachte, dass die Elemente, die diese Verschiebung verursacht haben, wie z. B. ein Bild oder eine Anzeige, als stabil gelten, da sie sich nach dem Rendern nicht unbedingt bewegen.
- Die distance fraction: Dies ist die größte Entfernung, die von einem einzelnen instabilen Element im Ansichtsfenster verschoben wurde. Wenn die größte Verschiebung bei einem Element auftritt, das sich von 0,100 auf 0,800 bewegt, hat es sich um 700 vertikale Pixel verschoben. Wenn der Viewport des Geräts 1.000 px hoch ist, beträgt der Abstandsanteil 700 px / 1000 px = 0,7. Der berechnete Wert für die kumulative Layoutverschiebung ist also 0,6 x 0,7 = 0,42.
Google hat Änderungen an der CLS-Metrik vorgenommen, um die folgenden Situationen zu berücksichtigen:
- Layoutverschiebungen werden in „Sitzungen“ zusammengefasst, die fünf Sekunden dauern und nach einer Sekunde enden, wenn keine weiteren Layoutverschiebungen auftreten. Treten zwei oder mehr Verschiebungen innerhalb einer Sekunde auf, werden ihre Werte addiert.
- Layoutverschiebungen werden erst 500 ms nach einer Benutzerinteraktion, wie z. B. einem Klick, aufgezeichnet. In manchen Fällen löst dies DOM-Aktualisierungen aus (z. B. Öffnen eines Menüs, Anzeigen einer Fehlermeldung, Anzeigen eines modalen Dialogs usw.).
- Einseitige Anwendungen, die länger geöffnet bleiben und zahlreiche DOM-Aktualisierungen vornehmen, werden nicht beeinträchtigt.
Seiten mit einem CLS-Wert von 0,1 oder weniger werden als gut (grün) eingestuft. Seiten, die einen Wert von 0,25 überschreiten, gelten als schlecht (rot):
Tools zur Analyse der kumulativen Layoutverschiebung
CLS-Metriken werden im DevTools Lighthouse-Panel, in PageSpeed Insights und in den web.dev Measure-Tools berechnet:
Die Web Vitals-Erweiterung für Google Chrome zeigt auch die CLS-Kennzahl an:
Wie bei LCP und FID kannst du mit dem Chrome User Experience Report echte CLS-Statistiken abfragen, die über verschiedene Länder, Verbindungen und Geräte für eine bestimmte URL aufgezeichnet wurden.
Die JavaScript-Bibliothek von web-vitals kann auch CLS-Metriken für echte Nutzer/innen auf deiner Live-Site berechnen, genau wie bei LCP und FID. Das folgende Skript kann in deinen HTML <head> eingefügt werden, um CLS-Metriken an eine Callback-Funktion auszugeben:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Häufige Ursachen für schlechte Cumulative Layout Shift Scores
Schlechte CLS-Werte werden in der Regel durch langsam ladende Seiteninhalte und dynamische oder nicht dimensionierte DOM-Elemente verursacht:
- Der Platz auf der Seite ist nicht für Bilder, Iframes, Werbung usw. reserviert.
- Die Inhalte werden dynamisch in das DOM eingefügt, in der Regel nach einer Netzwerkanfrage für Werbung, Social Media Widgets usw.
- Das Laden von Webschriften verursacht einen auffälligen Flash of Invisible Text (FOIT) oder Flash of Unstyled Text (FOUT).
Wie du die kumulativen Layoutverschiebungswerte verbesserst
Eine clientseitige Prüfung kann Probleme aufdecken, aber im Allgemeinen geht es darum, sicherzustellen, dass Platz für Inhalte reserviert wird, bevor sie heruntergeladen werden. Die Tipps zur Serveroptimierung, die für Largest Contentful Paint vorgeschlagen wurden, werden einen gewissen Nutzen haben, aber es sind noch weitere Verbesserungen möglich:
- Füge Breite- und Höhe-Attribute zu HTML
<img>– und<iframe>-Tags hinzu oder verwende die neue CSS-Eigenschaft aspect-ratio, um sicherzustellen, dass vor dem Herunterladen von Inhalten der entsprechende Platz auf der Seite reserviert wird. - Lege angemessene Maße für Containerelemente fest, die langsam ladende Inhalte von Drittanbietern wie Werbung und Widgets einschließen.
- Sorge dafür, dass Bilder und andere Inhalte, die im oberen Bereich der Seite erscheinen, so früh wie möglich angefordert werden – ein Preload könnte sich als hilfreich erweisen.
- Minimiere die Verwendung von Web-Schriften und verwende nach Möglichkeit allgemein verfügbare OS-Schriften.
- Lade Web-Schriftarten und setze die CSS-Schriftanzeige auf optional oder swap. Vergewissere dich, dass du eine ähnlich große Ausweichschrift verwendest, um die Layoutverschiebung zu minimieren.
- Vermeide es, Elemente am oberen Rand der Seite einzufügen, es sei denn, sie reagieren auf eine Benutzeraktion wie einen Klick.
- Achte darauf, dass die Benutzerinteraktion innerhalb von 500 Millisekunden nach dem Auslösen der Eingabe abgeschlossen ist.
- Verwende CSS-Transformation und Deckkraft für effizientere Animationen, die kein neues Layout erfordern.
- Berücksichtige kritisches Inline-CSS. Binde wichtige „above-the-fold“-CSS in einen
<link>-Block am Anfang der Seite ein und lade dann zusätzliche Stylesheets asynchron. - Berücksichtige bei Bedarf Containment, eine neue CSS-Funktion, mit der du isolierte Teilbäume einer Seite identifizieren kannst. Der Browser kann die Verarbeitung optimieren, indem er bestimmte DOM-Inhaltsblöcke rendert – oder nicht rendert.
Zusammenfassung
Entwickler/innen tanzen nicht immer gern nach Googles Pfeife. Das Unternehmen hat viel Macht, und kleine Updates der Suchmaschine können sich negativ auf die Produktivität und Rentabilität von webbasierten Unternehmen auswirken.
Dennoch verfolgt Core Web Vitals eher den Ansatz „Zuckerbrot“ als „Peitsche“. Gut optimierte, benutzerfreundliche Webseiten, die auf dunkle Muster verzichten, haben eine bessere Chance auf Erfolg als aufgeblähte, pop-up-intensive Webseiten, die eine schlechte mobile Benutzeroberfläche bieten.
Core Web Vitals bietet eine messbare Möglichkeit, die Nutzererfahrung zu bewerten, damit du dich auf die wichtigsten Verbesserungen konzentrieren kannst. Die Änderungen an deinen Vitalwerten erhöhen vielleicht nicht den Umsatz, aber deine Nutzer/innen werden zufriedener und loyaler sein.
Hast du weitere Tipps zur Verbesserung der Core Web Vitals? Teile sie im Kommentarbereich mit!
Schreibe einen Kommentar