Vorlage für Core-Web-Vitals- und Seitengeschwindigkeits-Audit

Benchmark sowie Feld- vs. Labordaten

Legen Sie eine Baseline für jeden Core Web Vital fest, bevor Sie etwas ändern, und lernen Sie, welcher Datenquelle Sie für die Bewertung und welcher für die Fehlersuche vertrauen sollten.

Legen Sie Ihre Baseline fest

Bevor Sie etwas optimieren, halten Sie fest, wo jede Metrik heute für [Seiten-URL] steht. Google bewertet anhand von Felddaten (echte Chrome-Nutzer, der CrUX-Datensatz, ein rollierendes 28-Tage-Fenster), also ist das die Zahl, die für die Suche zählt. Labordaten (Lighthouse, ein einzelner simulierter Ladevorgang) dienen der Fehlersuche, weil sie wiederholbar sind und Ihnen umsetzbare Traces liefern.

• Feldquelle: Rufen Sie CrUX-Daten aus PageSpeed Insights oder dem Core-Web-Vitals-Bericht der Search Console für [Property] ab.
• Laborquelle: Führen Sie Lighthouse aus (Chrome DevTools oder PageSpeed Insights), um Probleme zu reproduzieren und zu verfolgen.
• Schwellenwerte festhalten: LCP gut <=2,5 s, INP gut <=200 ms, CLS gut <=0,1; notieren Sie Ihren aktuellen Wert und das Bestehen/Nicht-Bestehen am "75. Perzentil" für jede.

Feld- und Labordaten werden voneinander abweichen, und das ist zu erwarten. Der Labortest lädt auf einem Gerät und Netzwerk; das Feld aggregiert viele. Nutzen Sie das Labor, um die Ursache zu finden, und das Feld, um die Heilung zu bestätigen.

Ergebnis: eine Baseline-Tabelle mit jeder Metrik, ihrem aktuellen Feldwert, Laborwert und Bestanden/Durchgefallen-Status für [Datum].

Largest Contentful Paint (LCP) beheben

Diagnostizieren und beheben Sie einen langsamen LCP, damit das Hauptinhaltselement für die meisten Besucher innerhalb von 2,5 Sekunden gerendert wird.

Sorgen Sie dafür, dass der Hauptinhalt schnell erscheint

LCP misst, wann das größte sichtbare Element (meist ein Hero-Bild, ein Video-Poster oder ein Überschriftenblock) fertig gerendert ist. Das Ziel ist <=2.5s am 75. Perzentil. Identifizieren Sie das LCP-Element in Lighthouse und gehen Sie dann die vier Phasen an, die es verzögern.

1. Time to First Byte: Reduzieren Sie die Serverantwort für [Origin] durch Caching, einen schnelleren Host oder Edge-Rendering.
2. Render-blockierende Ressourcen: Verzögern Sie unkritisches CSS und JavaScript, damit der Browser früher zeichnen kann.
3. Verzögerung beim Laden der Ressource: Fügen Sie preload für das LCP-Bild hinzu und setzen Sie [fetchpriority=high] darauf, damit der Browser es früh abruft.
4. Verzögerung beim Rendern der Ressource: Stellen Sie sicher, dass das LCP-Bild nicht lazy-geladen wird und in einem modernen Format in der richtigen Größe ausgeliefert wird.

Vermeiden Sie es, das Hero-Bild per CSS-Hintergrund oder clientseitigem JavaScript zu laden, da der Browser es zu spät entdeckt. Ein direkt referenziertes, vorgeladenes, korrekt dimensioniertes Bild gewinnt fast immer.

Prüfen: Führen Sie Lighthouse erneut aus und bestätigen Sie, dass das LCP-Element und seine Ladezeitleiste für [Seiten-URL] unter 2,5 s gefallen sind.

Interaction to Next Paint (INP) beheben

Verbessern Sie die Reaktionsfähigkeit, damit die Seite schnell auf Klicks, Taps und Tastendrücke reagiert, und ersetzen Sie so die ältere Metrik FID.

Lassen Sie Interaktionen sofort wirken

INP ersetzte FID im März 2024 als Core Web Vital. Es misst die Latenz von Interaktionen über den gesamten Seitenbesuch hinweg und berichtet ungefähr die schlechteste. Das Ziel ist <=200ms. Schlechter INP lässt sich fast immer auf JavaScript zurückführen, das den Hauptthread blockiert, wenn der Nutzer agiert.

• Lange Tasks finden: Nutzen Sie das Performance-Panel der DevTools, um Hauptthread-Tasks über 50 ms während der Interaktion auf [Seiten-URL] aufzuspüren.
• JavaScript aufteilen: Zerlegen Sie lange Tasks in kleinere Stücke und geben Sie den Hauptthread frei, damit Eingaben verarbeitet werden können.
• Hauptthread-Arbeit reduzieren: Entfernen oder verzögern Sie ungenutzte Skripte, besonders schwere Drittanbieter-Tags wie [Tag-Name].
• Event-Handler optimieren: Entprellen (debounce) Sie aufwendige Arbeit und verschieben Sie nicht dringende Updates bis nach dem nächsten Paint.
• DOM-Größe und Layout-Kosten minimieren: Ein großes oder tief verschachteltes DOM macht jede Interaktion teurer.

Das Ziel ist, den Hauptthread frei zu halten, wenn Nutzer klicken und tippen, damit der Browser eine Reaktion innerhalb des 200-ms-Budgets zeichnen kann.

Prüfen: Testen Sie echte Interaktionen und bestätigen Sie, dass der Feld-INP für [Property] in Richtung gut tendiert.

Cumulative Layout Shift (CLS) beheben

Verhindern Sie, dass Inhalte während des Ladens herumspringen, damit das Layout unterhalb eines CLS von 0,1 visuell stabil bleibt.

Stoppen Sie das Springen des Layouts

CLS misst unerwartete Layoutverschiebungen sichtbarer Inhalte während der Lebensdauer der Seite. Das Ziel ist <=0.1. Verschiebungen frustrieren Nutzer und verursachen Fehlklicks, und sie kommen fast immer von Elementen, die ohne reservierten Platz laden.

• Medien dimensionieren: Setzen Sie immer width- und height-Attribute (oder ein CSS-aspect-ratio) bei Bildern, Videos und iframes, damit der Browser Platz reserviert, bevor sie laden.
• Platz für Einbettungen und Anzeigen reservieren: Geben Sie Slots für [Anzeige oder Embed] einen Container mit fester min-height, damit sie Inhalte nicht nach unten drücken.
• Niemals Inhalte über bestehende Inhalte einfügen: Vermeiden Sie das Einschieben von Bannern, Hinweisen oder Cookie-Leisten, die die Seite nach dem Rendern nach unten schieben.
• Font-Swap-Verschiebungen verhindern: Laden Sie Schlüsselschriften vor und nutzen Sie [font-display] mit Bedacht, um Reflow zu begrenzen.
• Platz für dynamische UI reservieren: Halten Sie Platz für per JavaScript hinzugefügte Elemente frei, damit sie sich in vorab zugewiesenen Raum ausdehnen.

Behandeln Sie jedes "Springen", das Sie beim Laden sehen, als Defekt, den es zu beseitigen gilt.

Prüfen: Beobachten Sie das Lade-Filmstreifen und bestätigen Sie, dass es keine sichtbaren Verschiebungen auf [Seiten-URL] gibt.

Asset- und Auslieferungs-Optimierung

Reduzieren und beschleunigen Sie die Ressourcen, die eine Seite ausliefert — Bilder, JavaScript, CSS, Caching und CDN — um alle Metriken auf einmal zu verbessern.

Weniger ausliefern, schneller ausliefern

Die meisten Seitengeschwindigkeits-Probleme laufen darauf hinaus, zu viele Bytes oder sie zu langsam zu senden. Die Optimierung der Auslieferung verbessert LCP, INP und CLS gemeinsam, weil der Browser weniger herunterladen, parsen und ausführen muss.

• Bilder: Liefern Sie moderne Formate (etwa WebP oder AVIF), dimensionieren Sie sie auf die angezeigten Maße und komprimieren Sie; lazy-laden Sie nur Bilder unterhalb des Falzes, niemals das LCP-Bild.
• JavaScript: Minifizieren, Tree-Shaking und Code-Splitting, damit jede Seite nur lädt, was sie braucht; verzögern oder async-en Sie unkritische Skripte.
• CSS: Minifizieren, ungenutzte Regeln entfernen und das kritische CSS für Above-the-fold-Inhalte auf [Template] inline einbetten.
• Caching: Setzen Sie lange Cache-Lebensdauern für statische Assets und nutzen Sie Fingerprint-Dateinamen, damit Updates den Cache sicher invalidieren.
• CDN: Liefern Sie Assets von Edge-Standorten nahe den Nutzern und aktivieren Sie Kompression (Brotli oder gzip) bei [CDN-Anbieter].

Prüfen Sie Drittanbieter-Skripte gnadenlos, da sie eine häufige, verborgene Ursache für langsames Laden und schlechte Reaktionsfähigkeit sind.

Prüfen: Vergleichen Sie die Gesamtübertragungsgröße und Anzahl der Requests vorher und nachher für [Seiten-URL].

Erneut testen und überwachen

Bestätigen Sie in den Felddaten, dass die Fixes gewirkt haben, und richten Sie eine laufende Überwachung ein, damit Regressionen früh erkannt werden.

Bestätigen Sie den Erfolg und halten Sie ihn

Ein Fix ist erst fertig, wenn Felddaten ihn bestätigen. Da CrUX ein rollierendes 28-Tage-Fenster verwendet, brauchen Verbesserungen echter Nutzer Zeit, um sichtbar zu werden, validieren Sie also in zwei Stufen: zuerst im Labor für sofortiges Feedback, dann im Feld über die folgenden Wochen.

1. Labortests erneut ausführen: Nutzen Sie Lighthouse oder PageSpeed Insights, um zu bestätigen, dass das Trace-Level-Problem auf [Seiten-URL] behoben ist.
2. Felddaten beobachten: Verfolgen Sie CrUX im Core-Web-Vitals-Bericht der Search Console und warten Sie, bis sich das 28-Tage-Fenster aktualisiert, bevor Sie den Erfolg erklären.
3. Ziele setzen: Halten Sie jede URL-Gruppe auf LCP <=2.5s, INP <=200ms, CLS <=0.1 am 75. Perzentil.
4. Kontinuierlich überwachen: Fügen Sie Real-User-Monitoring (RUM) oder geplante Audits für [Property] hinzu, damit Regressionen schnell auffallen.
5. Gegen Drift absichern: Auditieren Sie erneut nach großen Releases, neuen Drittanbieter-Tags oder Template-Änderungen.

Performance ist kein einmaliges Projekt; behandeln Sie sie als laufendes Budget, das Sie bei jedem Deploy verteidigen.

Ergebnis: ein Vorher/Nachher-Bericht und eine notierte Überwachungskadenz für [Datum].

Welche drei Core Web Vitals gibt es und wie lauten ihre guten Schwellenwerte?

Largest Contentful Paint (LCP) sollte 2,5 Sekunden oder weniger betragen, Interaction to Next Paint (INP) 200 Millisekunden oder weniger und Cumulative Layout Shift (CLS) 0,1 oder weniger. Jeder Schwellenwert muss am 75. Perzentil der Besuche echter Nutzer erreicht werden, um als gut zu gelten.

Was ist mit First Input Delay (FID) passiert?

INP ersetzte FID im März 2024 als Core Web Vital. FID maß nur die Verzögerung, bevor die erste Interaktion verarbeitet wurde, während INP die volle Latenz der Interaktionen über den gesamten Seitenbesuch misst und so ein vollständigeres Bild der Reaktionsfähigkeit liefert.

Was ist der Unterschied zwischen Felddaten und Labordaten?

Felddaten stammen von echten Chrome-Nutzern im CrUX-Datensatz über ein rollierendes 28-Tage-Fenster, und sie sind das, was Google fürs Ranking nutzt. Labordaten stammen aus einem einzelnen simulierten Ladevorgang in einem Tool wie Lighthouse; sie sind wiederholbar und ideal für die Fehlersuche, spiegeln aber nicht wider, was echte Nutzer erleben.

Warum weicht mein Lighthouse-Score vom CrUX-Feld-Score ab?

Lighthouse führt einen Ladevorgang auf einem bestimmten simulierten Gerät und Netzwerk aus, während CrUX viele echte Nutzer auf unterschiedlichen Geräten, Verbindungen und Cache-Zuständen aggregiert. Abweichung ist normal. Nutzen Sie Labordaten, um die Ursache zu finden und zu beheben, und Felddaten, um zu bestätigen, dass der Fix für echte Nutzer gewirkt hat.

Warum haben sich meine Core Web Vitals nicht sofort nach dem Deploy eines Fixes verbessert?

Felddaten aktualisieren sich langsam, weil CrUX ein rollierendes 28-Tage-Fenster verwendet, sodass Verbesserungen Wochen brauchen, um vollständig sichtbar zu werden. Bestätigen Sie den Fix in Labor-Tools wie Lighthouse für sofortiges Feedback und beobachten Sie dann den Feldbericht in der Search Console, während sich das Fenster nach und nach mit Daten nach dem Fix aktualisiert.

Was ist die häufigste Ursache für schlechten INP?

Lange JavaScript-Tasks, die den Hauptthread blockieren, wenn ein Nutzer interagiert. Wenn der Hauptthread beschäftigt ist, kann der Browser die Eingabe nicht verarbeiten und innerhalb des 200-ms-Budgets eine Reaktion zeichnen. Lange Tasks aufteilen, unkritische und Drittanbieter-Skripte verzögern und den Hauptthread freigeben sind die wirksamsten Fixes.