Core Web Vitals verbessern: Was messbar wirkt und was nur Aufwand ist
LCP, INP und CLS sind seit Jahren Rankingfaktoren. Dieser Beitrag zeigt, welche Maßnahmen in echten Projekten den größten Effekt hatten – mit Messwerten aus einem Relaunch.
Burak Kaya · Gründer und technischer Leiter
Veröffentlicht am · aktualisiert am
Kurz beantwortet
Core Web Vitals umfassen drei Messwerte: Largest Contentful Paint (Ziel unter 2,5 Sekunden), Interaction to Next Paint (unter 200 Millisekunden) und Cumulative Layout Shift (unter 0,1). Den größten Effekt erzielen in der Praxis serverseitiges Rendering, Bildoptimierung in AVIF oder WebP sowie das Reduzieren von JavaScript im Auslieferungspfad.
Inhalt · 5 Abschnitte
Core Web Vitals sind seit 2021 ein offizieller Rankingfaktor. Wichtiger als das Ranking ist aber ein anderer Effekt: Schnelle Seiten verkaufen mehr. In unserem Shop-Relaunch für einen Laborhändler stieg die Conversion-Rate um 41 Prozent – bei unverändertem Sortiment und unverändertem Design.
Das Wichtigste in Kürze
- Interaction to Next Paint (INP) hat im März 2024 den früheren Wert First Input Delay als offiziellen Core-Web-Vital abgelöst.
- Die Zielwerte lauten: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1 – jeweils für 75 Prozent der Seitenaufrufe.
- Bilder sind in den meisten Projekten die häufigste Ursache eines schlechten LCP; die Umstellung auf AVIF oder WebP mit korrekten Größenangaben halbiert die Ladezeit oft.
- Layoutsprünge entstehen meistens durch Bilder ohne Größenangabe, nachgeladene Werbung und Schriften ohne passenden Ersatzwert.
- Google bewertet Felddaten aus dem Chrome User Experience Report, nicht die Laborwerte aus Lighthouse – ein Lighthouse-Score von 100 garantiert keine guten Felddaten.
Die drei Werte#
Largest Contentful Paint (LCP)#
Wann ist das größte sichtbare Element geladen? Meistens ein Bild oder eine Überschrift.
Ziel: unter 2,5 Sekunden.
Interaction to Next Paint (INP)#
Wie lange dauert es, bis die Seite sichtbar auf eine Eingabe reagiert? INP hat im März 2024 den früheren First Input Delay abgelöst – und ist strenger, weil er alle Interaktionen misst, nicht nur die erste.
Ziel: unter 200 Millisekunden.
Cumulative Layout Shift (CLS)#
Wie stark verschiebt sich das Layout während des Ladens? Der Wert misst das Ärgernis, auf einen Knopf zu tippen, der im selben Moment wegspringt.
Ziel: unter 0,1.
Was in echten Projekten wirkt#
Die folgenden Zahlen stammen aus dem erwähnten Shop-Relaunch. Ausgangslage: LCP 5,8 Sekunden, INP 340 Millisekunden, CLS 0,24.
Serverseitiges Rendering – größter Einzeleffekt#
Die alte Seite lieferte ein leeres Grundgerüst aus, das der Browser erst mit JavaScript füllte. Bis der Besucher etwas sah, mussten JavaScript geladen, ausgeführt und Daten nachgefordert werden.
Mit serverseitigem Rendering kommt die fertige Seite an. Der Browser zeigt sie sofort.
Effekt: LCP von 5,8 auf 2,1 Sekunden.
Bilder in modernen Formaten und richtiger Größe#
Die alte Seite lieferte Produktbilder als JPEG in 2000 Pixel Breite aus – auch dann, wenn sie mit 400 Pixeln dargestellt wurden.
Drei Maßnahmen: AVIF mit WebP als Rückfallebene, mehrere Größen über das srcset-Attribut, und loading="lazy" für alles unterhalb des sichtbaren Bereichs.
Wichtig: Das LCP‑Bild bekommt kein Lazy Loading, sondern fetchpriority="high". Ein häufiger Fehler, der die Ladezeit verschlechtert, obwohl er nach Optimierung aussieht.
Effekt: LCP von 2,1 auf 1,3 Sekunden, Seitengewicht von 3,4 MB auf 680 KB.
JavaScript reduzieren#
Die alte Seite lud 1,1 MB JavaScript, davon rund 400 KB für einen Bildbetrachter, der auf 90 Prozent der Seiten gar nicht verwendet wurde.
Maßnahmen: Aufteilen des Codes nach Route, Nachladen selten genutzter Komponenten erst bei Bedarf, und das Ersetzen zweier Bibliotheken durch wenige Zeilen eigenen Code.
Effekt: INP von 340 auf 120 Millisekunden.
Layoutsprünge beseitigen#
CLS von 0,24 kam aus drei Quellen: Bilder ohne Größenangabe, ein nachgeladenes Hinweisband und ein Schriftwechsel beim Laden.
Lösungen: width und height an allen Bildern, fester Platz für das Hinweisband, und font-display: swap mit einem Ersatzfont, dessen Metriken zur Zielschrift passen.
Effekt: CLS von 0,24 auf 0,02.
Schriften selbst ausliefern#
Schriften von Google-Servern kosten eine zusätzliche DNS‑Auflösung, einen Verbindungsaufbau und einen TLS‑Handshake – rund 300 Millisekunden auf Mobilgeräten. Selbst ausgeliefert entfällt das vollständig.
Nebeneffekt: Das Problem aus Punkt 1 unserer DSGVO-Checkliste löst sich gleich mit.
Effekt: LCP von 1,3 auf 0,9 Sekunden.
Was wenig gebracht hat#
Ehrlichkeit gehört dazu. Diese Maßnahmen kosteten Zeit und brachten kaum messbaren Gewinn:
- Kritisches CSS einbetten. Theoretisch richtig, praktisch bei modernen Bündelwerkzeugen unter 30 Millisekunden Unterschied.
- HTTP/3. Nett, aber der Effekt lag im Messrauschen.
- Aggressives Vorladen. Zu viele
preload-Anweisungen konkurrieren um Bandbreite und verschlechtern den LCP, statt ihn zu verbessern.
Richtig messen#
Felddaten (maßgeblich für das Ranking): Google Search Console, Bereich „Core Web Vitals“. Zeigt echte Nutzerdaten der letzten 28 Tage.
Labordaten (zum Debuggen): Lighthouse in den Chrome-Entwicklerwerkzeugen oder PageSpeed Insights.
Ein Lighthouse-Score von 100 bei gleichzeitig schlechten Felddaten ist ein häufiger Fall. Die Ursache sind meist ältere Android-Geräte im Mobilfunknetz – Ihr MacBook im WLAN ist nicht Ihre Zielgruppe.
Die Reihenfolge, die wir empfehlen#
- Felddaten in der Search Console ansehen. Welcher Wert ist tatsächlich rot?
- Bilder prüfen – bei schlechtem LCP ist das in vier von fünf Fällen die Ursache.
- JavaScript messen, nicht schätzen. Der Reiter „Coverage“ in Chrome zeigt ungenutzten Code.
- Layoutsprünge im Lighthouse-Bericht einzeln durchgehen.
- Erst danach über serverseitiges Rendering nachdenken – das ist die größte Maßnahme und oft ein Relaunch.
Und die unbequeme Wahrheit: Wenn Ihre Seite auf einem System läuft, das Geschwindigkeit strukturell nicht kann, sind die ersten vier Punkte Symptombehandlung. Dann rechnet sich der Neubau schneller, als es zunächst aussieht.
Über den Autor
Burak Kaya
Gründer und technischer Leiter
Entwickelt seit über zehn Jahren Webanwendungen und Unternehmenssoftware. Schwerpunkt: Systeme, die im Mittelstand tatsächlich benutzt werden.
- Next.js und React
- TypeScript
- PostgreSQL und Datenmodellierung
- ERP- und Schnittstellenanbindung
- Festpreiskalkulation
- Technisches SEO
Passende Leistung
Von der Unternehmensseite bis zum Kundenportal – gebaut mit Next.js, gehostet in Deutschland.
Einstieg, Festpreis netto
ab 3.900 €
Website · 3–5 Wochen
Häufige Fragen
Was Leser zu diesem Thema fragen
Die Fragen, die uns zu diesem Beitrag am häufigsten gestellt werden.
Was sind gute Core-Web-Vitals-Werte?
Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden, Cumulative Layout Shift unter 0,1. Diese Werte müssen für 75 Prozent der tatsächlichen Seitenaufrufe erreicht werden – nicht im Durchschnitt.
Wie stark beeinflussen Core Web Vitals das Ranking?
Sie sind ein bestätigter Rankingfaktor, aber ein nachrangiger. Bei ähnlich relevanten Inhalten geben sie den Ausschlag; ein schneller Text ohne Substanz schlägt keinen langsamen mit Substanz. Der wirtschaftlich größere Effekt liegt ohnehin in der Conversion-Rate: Jede Sekunde weniger Ladezeit erhöht sie messbar.
Warum zeigt Lighthouse 100, die Search Console aber Probleme?
Lighthouse misst unter Laborbedingungen auf Ihrem Rechner. Die Search Console zeigt Felddaten aus dem Chrome User Experience Report – echte Nutzer, echte Geräte, echte Verbindungen. Maßgeblich sind die Felddaten. Ein häufiger Grund für die Abweichung sind ältere Android-Geräte im Mobilfunknetz.
Lohnt sich Optimierung auch ohne Relaunch?
Ja. Bildoptimierung, das Entfernen ungenutzter Skripte und das Setzen fester Größen für Bilder und eingebettete Inhalte lassen sich in bestehenden Systemen umsetzen und bringen oft schon die Hälfte des möglichen Gewinns. Ein Relaunch lohnt sich, wenn das System selbst die Ursache ist.