Kurze Antwort
Was sind Core Web Vitals, und welche Werte gelten als gut?
Website-Tempo wird an drei Metriken gemessen, deren Schwellen Google veröffentlicht: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Alle drei am 75. Perzentil der Seitenaufrufe, getrennt für Mobil und Desktop. In der Praxis bringt nicht das Aufräumen von Plugins die Verbesserung, sondern Bildgewicht, Schriftladereihenfolge und Server-Antwortzeit.
Das Wichtigste
- Googles Schwellen sind eindeutig: LCP 2,5 Sekunden, INP 200 Millisekunden, CLS 0,1 — alle am 75. Perzentil gemessen, nicht am Mittelwert.
- INP hat FID 2024 als stabilen Core Web Vital abgelöst; ein Angebot, das noch FID berichtet, ist veraltet.
- Labortest (die Simulation in PageSpeed Insights) und Felddaten sind zweierlei; entschieden wird mit Felddaten, weil nur sie die Geräte echter Nutzer abbilden.
- Das mit Abstand häufigste Problem ist ein unskaliertes Bild im sichtbaren Bereich — es allein kann LCP um Sekunden verzögern.
- Tempo ist weniger ein Ranking- als ein Conversion-Faktor: unter die Schwelle zu kommen genügt, eine 100 zu jagen ist nicht das Ziel.
Welche Zahlen werden gemessen?
„Die Site ist langsam“ ist keine Messung. Google veröffentlicht drei Metriken und drei Schwellen, und genau diese drei — nicht der PageSpeed-Score — sind das Ziel einer Tempo-Arbeit. Der Score ist eine aus einer Simulation abgeleitete Zusammenfassung; er ist nicht die Zahl, nach der entschieden wird.
Core-Web-Vitals-Schwellen und was jede wirklich misst
LCP
- Gut-Schwelle
- Unter 2,5 Sekunden
- Was sie misst
- Wie lange das größte Inhaltselement bis zur Anzeige braucht
- Häufigste Ursache
- Unskaliertes Hero-Bild, langsamer Server
INP
- Gut-Schwelle
- Unter 200 Millisekunden
- Was sie misst
- Wie lange der Bildschirm nach einer Interaktion braucht
- Häufigste Ursache
- Skripte, die den Hauptthread blockieren
CLS
- Gut-Schwelle
- Unter 0,1
- Was sie misst
- Wie stark Inhalte beim Laden verrutschen
- Häufigste Ursache
- Bilder ohne Maßangabe, spät eingefügte Banner
| Metrik | Gut-Schwelle | Was sie misst | Häufigste Ursache |
|---|---|---|---|
| LCP | Unter 2,5 Sekunden | Wie lange das größte Inhaltselement bis zur Anzeige braucht | Unskaliertes Hero-Bild, langsamer Server |
| INP | Unter 200 Millisekunden | Wie lange der Bildschirm nach einer Interaktion braucht | Skripte, die den Hauptthread blockieren |
| CLS | Unter 0,1 | Wie stark Inhalte beim Laden verrutschen | Bilder ohne Maßangabe, spät eingefügte Banner |
Alle drei werden am 75. Perzentil bewertet: dem Wert, den drei Viertel der Nutzer sehen. Ein Mittelwert verdeckt die Erfahrung auf den langsamsten Geräten und taugt hier deshalb nicht.
Labortest oder Felddaten?
PageSpeed Insights zeigt zwei verschiedene Dinge, und die meisten Diskussionen entstehen aus deren Verwechslung. Der obere Teil sind echte Nutzerdaten von Geräten realer Besucher. Der untere ist eine Simulation: ein Ladevorgang unter angenommenem Gerät und Anschluss. Der Score kommt von unten, die Entscheidung sollte von oben kommen.
Praktische Folge: Ein Angebot mit „Wir bringen Ihren Score auf 95“ misst die Simulation. Die richtige Zusage lautet, alle drei Metriken in den Felddaten unter die Schwelle zu bringen — und zwar in der Seitengruppe mit dem Traffic, nicht auf einer Einzelseite.
Was hilft tatsächlich?
- Bilder: Das Hero-Bild im sichtbaren Bereich muss korrekt dimensioniert, in modernem Format (AVIF/WebP) und mit Breite und Höhe ausgeliefert werden. Der größte LCP-Gewinn kommt von hier, und dieselbe Korrektur verbessert CLS.
- Schriften: Unsichtbarer Text während des Ladens einer Schrift verzögert LCP. Fontdateien von der eigenen Domain auszuliefern und das Ladeverhalten so zu setzen, dass Text sichtbar bleibt, ist wenig Arbeit.
- Drittanbieter-Skripte: Chat-Widget, Heatmap, drei Analytics-Tools und Werbe-Tags sind das, was INP zerstört. Zu fragen, ob jedes wirklich genutzt wird, bringt mehr als Code-Optimierung.
- Server-Antwortzeit: Ist die Seitenerzeugung langsam, macht kein Frontend das wett. Caching oder statische Generierung kürzt die erste Hälfte von LCP direkt.
- Layoutverschiebungen: Bilder ohne Maße, spät eingefügtes Cookie-Banner, Werbeplatz. Alle drei löst man, indem man Platz reserviert.
Hebt Tempo das Ranking?
Page-Experience-Signale fließen in Googles Bewertung ein, aber Tempo allein hebt keine schwache Seite auf einen guten Platz; es entscheidet zwischen zwei gleich starken Seiten. Der eigentliche Gewinn liegt anderswo: Auf einer mobilen Seite über der Schwelle gehen Besucher, bevor der Inhalt erscheint. Der Ertrag zeigt sich nicht in einer Ranking-Tabelle, sondern daran, wie viele das Formular ausfüllen.
Häufige Fragen
Welchen PageSpeed-Score sollte ich anstreben?
- Der Score ist kein Ziel. Ziel sind Felddaten mit LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Sind die drei erfüllt, steigt der Score ohnehin; den Score zu jagen führt zu kosmetischen Änderungen, die keine der drei Messgrößen verbessern.
Genügt ein Hosting-Wechsel für mehr Tempo?
- Ist die Server-Antwortzeit wirklich langsam, macht es etwas aus; auf den meisten Sites entsteht die größte Verzögerung aber im Browser, nicht auf dem Server: große Bilder, spät geladene Schriften, Drittanbieter-Skripte. Die Antwortzeit vor dem Wechsel zu messen verhindert ein überflüssiges Migrationsprojekt.
Beeinflusst ein Cookie-Banner das Tempo?
- Ja, und meist gleich an zwei Stellen. Lädt das Banner spät und schiebt die Seite nach unten, leidet CLS; und da die meisten Banner-Tools ein eigenes Skript laden, belastet es auch INP. Die Lösung ist nicht, das Banner zu entfernen: Platz reservieren und das Skript aus dem kritischen Ladepfad nehmen genügt.
Quellen
- 01Web Vitals — LCP, INP ve CLS eşikleri — web.dev, Google, 2026
- 02Understanding page experience in Google Search results — Google Search Central, 2026
Suchanfragen, die diese Seite beantwortet
- website geschwindigkeit verbessern
- core web vitals
- website zu langsam
- lcp verbessern