Core Web Vitals optimieren: Praxisleitfaden für bessere LCP-, INP- und CLS-Werte

Eine Seite kann fachlich stark sein und trotzdem schlecht performen. Wenn der sichtbare Hauptinhalt zu spät kommt, Buttons erst verzögert reagieren oder das Layout beim Laden springt, merken Nutzer das sofort. Suchmaschinen inzwischen auch.

Core Web Vitals sind deshalb kein Nebenthema für Entwickler. Sie sitzen direkt an der Schnittstelle zwischen SEO, UX und Conversion.

Dashboard mit Leistungswerten wie FCP, LCP, TTFB, INP und CLS

Was Core Web Vitals eigentlich messen

Die drei Kennzahlen decken unterschiedliche Teile des Seitenerlebnisses ab:

1. LCP (Largest Contentful Paint)

LCP misst, wann das größte sichtbare Element im Viewport erscheint. Das ist oft das Hero-Bild, ein Banner, ein Video oder der große erste Textblock.

Als guter Richtwert gelten 2,5 Sekunden oder weniger. Alles darüber wirkt für Nutzer oft schon träge.

2. INP (Interaction to Next Paint)

INP misst, wie schnell eine Seite nach einer echten Interaktion reagiert, also nach Klick, Tap oder Eingabe.

Zielwert: 200 ms oder weniger. Wenn INP schlecht ist, fühlt sich die Seite zäh an, auch wenn sie längst geladen ist.

3. CLS (Cumulative Layout Shift)

CLS misst unerwartete Layout-Verschiebungen während des Ladens oder Nachladens.

Gut ist 0,1 oder niedriger. Ein hoher Wert sorgt für Fehlklicks, unruhiges Lesen und wenig Vertrauen.

So misst du sinnvoll statt planlos

Bevor du optimierst, musst du erst wissen, wo das Problem wirklich liegt.

1. Search Console und PageSpeed Insights

Der Core-Web-Vitals-Bericht in der Google Search Console zeigt dir, welche URL-Gruppen im Feld auffällig sind. Für einzelne Seiten ist PageSpeed Insights ein guter Einstieg, um Ursachen zu erkennen.

2. Lighthouse in Chrome

Lighthouse bleibt das schnellste Werkzeug für die erste technische Diagnose. Achte vor allem auf:

welches Element als LCP erkannt wird
welche Skripte den Main Thread blockieren
welche CSS- oder Font-Dateien das Rendering aufhalten
wo Layout Shifts ausgelöst werden

3. RUM-Daten

Labordaten helfen, aber echte Nutzerbedingungen sind oft härter. Langsame Mobilfunknetze, alte Geräte, Cookie-Banner, Drittanbieter-Skripte: All das siehst du sauber erst in RUM-Daten.

Wenn du die SEO-Priorisierung parallel prüfen willst, kannst du betroffene Seiten zusätzlich im SEO Analyzer gegenchecken und so schneller priorisieren.

LCP verbessern: Erst die großen Hebel ziehen

Bei schwachem LCP liegt die Ursache meist nicht in zehn kleinen Details, sondern in zwei oder drei dicken Bremsen.

1. Das wichtigste Bild zuerst in Ordnung bringen

In vielen Fällen ist das LCP-Element ein Bild. Dann helfen vor allem diese Punkte:

moderne Formate wie WebP oder AVIF
responsive Auslieferung per srcset oder <picture>
saubere Komprimierung
kein loading="lazy" für das wahrscheinliche LCP-Bild
feste width- und height-Werte

1<picture>
2  <source
3    srcset="hero-1200.webp 1200w, hero-800.webp 800w, hero-400.webp 400w"
4    type="image/webp"
5    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
6  >
7  <source
8    srcset="hero-1200.jpg 1200w, hero-800.jpg 800w, hero-400.jpg 400w"
9    type="image/jpeg"
10    sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
11  >
12  <img src="hero-800.jpg" alt="Homepage hero image" width="1200" height="800" loading="eager">
13</picture>

2. Server-Antwort beschleunigen

Ist der TTFB zu hoch, kommt der Browser gar nicht erst sauber ins Rendern.

Page- und Object-Caching aktivieren
statische Assets über CDN ausliefern
langsame Datenbankabfragen prüfen
schwere Serverlogik aus dem kritischen Pfad nehmen

3. Render-Blocker reduzieren

Zu viel CSS, Fonts und JavaScript im kritischen Pfad machen jede Seite zäher als nötig.

Critical CSS inline oder sehr früh laden
nicht zwingende Skripte mit defer
unabhängige Drittanbieter-Skripte mit async
nicht benötigte Bibliotheken aus dem Initial-Load werfen

1<head>
2  <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
3  <script src="/js/main.js" defer></script>
4  <script src="https://analytics.example.com/script.js" async></script>
5</head>

4. Preload gezielt einsetzen

preload ist stark, aber nur für wirklich kritische Ressourcen. Wer alles priorisiert, priorisiert am Ende gar nichts.

INP verbessern: Reaktionszeit statt Ladezeit denken

Schlechter INP bedeutet fast immer: Der Main Thread ist überlastet.

1. JavaScript konsequent entschlacken

große Bundles aufteilen
Features per Dynamic Import später laden
ungenutzten Code entfernen
interaktive Komponenten nicht unnötig früh hydratisieren

1document.querySelector('.open-chart').addEventListener('click', async () => {
2  const { renderChart } = await import('./chart-module.js');
3  renderChart();
4});

2. Drittanbieter-Skripte hart prüfen

Consent-Manager, Chat, Tracking, Heatmaps, Ads, Video-Embeds. Genau hier steckt oft der meiste unnötige Ballast.

Fragen, die sich lohnen:

Welches Script bringt wirklich Geschäftswert?
Was kann erst nach Scroll oder Interaktion geladen werden?
Was kann komplett weg?

3. Lange Tasks aufbrechen

Alles, was den Main Thread länger blockiert, verschlechtert INP spürbar.

große Berechnungen in kleinere Schritte teilen
requestIdleCallback für Nebenaufgaben nutzen
rechenintensive Arbeit in Web Worker auslagern

CLS senken: Stabilität sichtbar machen

CLS wirkt oft wie ein kleines Problem, bis Nutzer ständig daneben tippen.

1. Platz für Medien reservieren

Bilder, Videos und iframe-Elemente brauchen von Anfang an definierte Maße.

width und height setzen
für responsive Blöcke aspect-ratio nutzen
Embeds in Container mit stabiler Höhe legen

2. Unerwartete Einblendungen vermeiden

Banner, Cookie-Hinweise, Promo-Leisten oder nachgeladene Empfehlungen verursachen gerne Sprünge.

Platz vorab reservieren
Overlays verwenden, wenn nichts verschoben werden soll
Ad-Slots mit Mindesthöhe anlegen

3. Fonts sauber laden

Auch Fonts können Layout Shifts auslösen.

wichtige Fonts preladen
font-display: swap einsetzen
Fallback-Font mit ähnlichen Metriken wählen

Praxisbeispiel: Weniger Reibung, mehr Umsatz

Ein E-Commerce-Projekt mit viel Mobile-Traffic startete mit diesen Werten:

LCP: 4,8 s
INP: 180 ms
CLS: 0,25
Conversion Rate: 1,2 %
Bounce Rate: 65 %

Umgesetzt wurden unter anderem:

Produkt- und Hero-Bilder auf WebP umgestellt.
Bild- und Werbeslots mit festen Größen versehen.
Analyse- und Werbe-Skripte verzögert geladen.
Kritische Hero-Bilder vorgeladen.
Critical CSS gestrafft.
CDN für statische Assets eingeführt.
Webfont-Strategie mit font-display: swap überarbeitet.

Das Ergebnis:

LCP: 1,9 s
INP: 65 ms
CLS: 0,08
Conversion Rate: 2,8 %
Bounce Rate: 42 %

Der Unterschied kam nicht von einem großen Wurf, sondern von sauber gesetzten Prioritäten.

Der wichtigere Teil: Die Werte halten

Core Web Vitals verschlechtern sich gern schleichend. Ein neues Script hier, ein Widget da, ein schweres Bild auf der Startseite, und das Thema ist zurück.

1. Kontinuierlich beobachten

Search Console, RUM und die wichtigsten Seitentypen sollten fest auf dem Radar liegen.

2. Performance-Budgets definieren

Setze Grenzen für:

Gesamtgröße von JavaScript
maximale Bildgewichte
Anzahl von Webfonts
Zahl der Drittanbieter-Skripte

3. Performance in den Release-Prozess aufnehmen

Neue Landingpages, Relaunches und Kampagnen brauchen vor dem Livegang einen kurzen Performance-Check. Sonst merkst du Probleme erst, wenn Traffic und Leads schon leiden.

4. Wissen im Team verteilen

Nicht nur Entwickler beeinflussen Core Web Vitals. Design, Content und Marketing tun das genauso.

Kurz zusammengefasst

Worauf es ankommt:

LCP verbessert sich über Hauptressource, Server-Antwort und kritischen Render-Pfad.
INP verbessert sich über weniger Main-Thread-Last und schlankeres JavaScript.
CLS verbessert sich über reservierte Flächen und kontrollierte Einblendungen.
Labordaten sind nützlich, Felddaten entscheiden.
Es geht nicht um hübsche Scores, sondern um Seiten, die schneller laden und besser konvertieren.

Wenn du zuerst sehen willst, welche URLs am meisten durch Performance verlieren, starte mit einem Check im SEO Analyzer und gehe dann mit Lighthouse und Felddaten tiefer.