Core Web Vitals und Ladezeit: So verbessern Sie Ihr Google-Ranking

11. März 2026, 10:30 Uhr  ·  9 Min. Lesezeit
Core Web Vitals – Ladezeit und Google-Ranking systematisch verbessern

Seit Google die Core Web Vitals im Mai 2021 als offiziellen Rankingfaktor eingeführt hat, haben viele Website-Betreiber einen Begriff gelernt, den sie bis dahin nicht kannten. Aber das Wissen, dass diese Metriken existieren, und das Wissen, wie man sie konkret verbessert, liegen in der Praxis weit auseinander. Die meisten Unternehmenswebsites im deutschen Mittelstand bestehen nicht alle drei Tests – und verlieren damit täglich Ranking-Potenzial gegenüber Wettbewerbern, die ihre technische Performance ernst nehmen.

Dieser Artikel erklärt nicht nur, was hinter LCP, INP und CLS steckt, sondern welche Maßnahmen den stärksten messbaren Effekt haben – priorisiert nach Aufwand und Wirkung.

48 %
aller Websites weltweit bestehen den LCP-Test (Largest Contentful Paint unter 2,5 Sekunden). Die Hälfte aller Websites verliert damit aktiv Ranking-Punkte. (Chrome User Experience Report)

Was Core Web Vitals wirklich messen

Core Web Vitals sind keine abstrakten technischen Messwerte – sie messen konkrete Nutzerwahrnehmungen. Google hat sie entwickelt, weil klassische Ladezeit-Metriken wie „Time to First Byte" oder „DOMContentLoaded" wenig darüber aussagen, wie eine Seite sich für den Menschen anfühlt, der sie benutzt.

Die drei Core Web Vitals – was sie messen
  • LCP – Largest Contentful Paint: Wie schnell lädt das größte sichtbare Element (meist Bild oder Headline)? Misst die wahrgenommene Ladegeschwindigkeit. Ziel: unter 2,5 Sek.
  • INP – Interaction to Next Paint: Wie schnell reagiert die Seite auf Klicks, Tippen oder andere Eingaben? Misst die Reaktionsfähigkeit über die gesamte Nutzungsdauer. Ziel: unter 200 ms.
  • CLS – Cumulative Layout Shift: Wie sehr springen Elemente auf der Seite während des Ladens? Misst visuelle Stabilität. Ziel: unter 0,1.

Wichtig zu verstehen: Google misst diese Werte nicht in einem Labor unter idealen Bedingungen. Die Bewertung basiert auf realen Nutzerdaten aus dem Chrome-Browser – dem sogenannten Chrome User Experience Report (CrUX). Das bedeutet, ein langsames Mobilgerät in einem schlechten Netzwerk zählt genauso wie ein schnelles Desktop-System.

LCP verbessern: Die größten Hebel

Der Largest Contentful Paint ist für die meisten Websites die kritischste der drei Metriken, weil er direkt mit der Ladegeschwindigkeit zusammenhängt – dem Faktor, der Nutzer am schnellsten zum Abspringen bringt.

Die häufigsten Ursachen für einen schlechten LCP-Wert und ihre Lösungen:

  1. Unoptimierte Bilder. Das LCP-Element ist in 70–80 Prozent aller Fälle ein Bild. JPEGs mit 2 MB Dateigröße als Hero-Bild sind der häufigste Einzelgrund für schlechten LCP. Lösung: WebP-Format, Komprimierung auf unter 200 KB, korrekte Bildgrößen per srcset.
  2. Kein Preload für das LCP-Element. Wenn der Browser das Hero-Bild erst entdeckt, nachdem er CSS und JavaScript geparst hat, entsteht eine unnötige Verzögerung. Lösung: <link rel="preload"> für das LCP-Bild im HTML-Head.
  3. Langsamer Server / kein CDN. Time to First Byte (TTFB) über 600 ms macht einen guten LCP-Wert fast unmöglich. Lösung: Upgrade auf einen schnelleren Hosting-Anbieter oder Einsatz eines CDN wie Cloudflare.
  4. Render-blockierendes CSS und JavaScript. Dateien, die im Head der Seite eingebunden sind und vor dem ersten Render geladen werden müssen, verzögern den LCP. Lösung: kritisches CSS inline einbinden, nicht-kritisches CSS und JS defer/async laden.

INP verbessern: Der neue blinde Fleck

INP (Interaction to Next Paint) ersetzte im März 2024 den alten FID (First Input Delay) als dritten Core Web Vital. Während FID nur die erste Interaktion auf einer Seite maß, bewertet INP die Reaktionsfähigkeit über die gesamte Nutzungsdauer. Das macht es anspruchsvoller zu verbessern.

12 %
aller Websites weltweit haben einen schlechten INP-Wert (über 500 ms). Das klingt wenig – bei WordPress-Sites mit vielen Plugins liegt die Rate deutlich höher. (HTTP Archive 2025)

Die häufigsten INP-Probleme:

  • Zu viele JavaScript-Bundles. Jedes Plugin, jedes Analytics-Tool, jeder Chat-Widget lädt JavaScript, das den Haupt-Thread blockiert. Wenn der Haupt-Thread beschäftigt ist, reagiert die Seite auf Nutzereingaben nicht.
  • Lange Tasks im JavaScript-Haupt-Thread. Tasks, die länger als 50 ms dauern, gelten als „Long Tasks" und blockieren Interaktionen. Lösung: Code aufteilen, nicht-kritisches JS lazy loaden.
  • Third-Party-Scripts ohne Management. Google Tag Manager mit 15 eingebundenen Tags, einem Heatmap-Tool, einem Chat-Widget und einem Retargeting-Pixel summieren sich zu erheblicher JavaScript-Last. Lösung: regelmäßiges Audit und Entfernung nicht genutzter Tags.

CLS verbessern: Elemente, die springen

Ein schlechter CLS-Wert – also Elemente, die beim Laden der Seite ihre Position verändern – ist nicht nur ein Ranking-Problem. Er ist ein direkt erlebbares Ärgernis: Der Nutzer tippt auf einen Button, der eine Zeile nach unten springt, bevor der Finger aufkommt – und klickt versehentlich auf etwas anderes.

Die häufigsten Ursachen für CLS und ihre direkten Fixes:

  • Bilder ohne definierte Breite und Höhe. Wenn der Browser die Größe eines Bildes nicht kennt, bevor es geladen ist, reserviert er keinen Platz – und verschiebt den umliegenden Inhalt, sobald das Bild erscheint. Fix: immer width und height Attribute in <img> Tags setzen.
  • Dynamisch nachgeladene Inhalte ohne reservierten Platz. Banner, Cookie-Hinweise, Anzeigenblöcke, die nach dem ersten Render injiziert werden, verschieben alles darunter. Fix: Mindesthöhe für den Container reservieren.
  • Web Fonts mit FOUT (Flash of Unstyled Text). Wenn eine Schriftart zu spät lädt, zeigt der Browser zunächst eine Fallback-Schrift an – die andere Maße hat und den Text neu umbricht. Fix: font-display: optional oder Schriftarten vorladen.

Wie Sie Ihre Werte korrekt messen

Es gibt zwei Arten von Core Web Vitals Messungen, die unterschiedliche Aussagen machen:

Labor- vs. Felddaten – der Unterschied
  • Labordaten (Synthetic) – gemessen in einer kontrollierten Umgebung. Tools: Google PageSpeed Insights (Lighthouse), WebPageTest. Schnelle Diagnose, nicht repräsentativ für echte Nutzer.
  • Felddaten (Field Data / CrUX) – aggregierte reale Nutzerdaten aus Chrome. Diese Werte verwendet Google für das Ranking. Abrufbar über: Google Search Console → Core Web Vitals-Bericht, PageSpeed Insights (oberer Bereich), CrUX Dashboard.

Wichtig: Labordaten können grün sein, während Felddaten rot sind – weil echte Nutzer ältere Geräte und schwächere Verbindungen haben. Google wertet ausschließlich Felddaten. Das Lab-Ergebnis ist nur ein Diagnosewerkzeug, kein Rankingfaktor.

Die Reihenfolge der Optimierungsmaßnahmen

Wer seine Core Web Vitals verbessern möchte, sollte in dieser Reihenfolge vorgehen – priorisiert nach Aufwand und typischer Wirkung:

  1. Bilder optimieren. Höchste Wirkung auf LCP mit geringstem Entwicklungsaufwand. WebP-Format, Komprimierung, korrekte Dimensionierung, Lazy Loading für nicht-sichtbare Bilder.
  2. Server und Hosting prüfen. TTFB über 600 ms? Hosting wechseln oder Caching aktivieren. Cloudflare kostenlos einbinden spart oft 30–50 % TTFB.
  3. Render-blockierende Ressourcen entfernen. CSS und JS im Head-Bereich prüfen. Kritisches CSS inline, Rest defer/async.
  4. Bildgrößen in HTML definieren. Alle img-Tags mit width und height Attributen versehen – CLS-Fix mit fünf Minuten Aufwand pro Seite.
  5. Third-Party-Scripts ausdünnen. Tag Manager Audit: welche Tags werden aktiv genutzt? Nicht genutzte Tags sofort entfernen.
  6. Ergebnisse in Search Console überwachen. CrUX-Daten aktualisieren sich monatlich. Nach Optimierungen mindestens 28 Tage warten, bevor eine Neubewertung sinnvoll ist.
Core Web Vitals sind kein technisches Hobby für Entwickler. Sie sind der direkte Zusammenhang zwischen Servergeschwindigkeit und Anfragevolumen – messbar, verbesserbar, und für jedes Unternehmen relevant, das online Kunden gewinnen möchte.

Wer heute in der Google Search Console seinen Core Web Vitals-Bericht öffnet und einen roten oder orangenen Status für mobile Geräte sieht, hat einen konkreten Handlungsauftrag. Nicht weil Google es verlangt – sondern weil jede Sekunde Ladezeit messbar Nutzer kostet, die nie wiederkommen.