Core Web Vitals optimieren: Leitfaden zu LCP, INP, CLS

Core Web Vitals optimieren heißt nicht, an Microsekunden zu feilen. Es heißt, drei klare Schwellenwerte zu treffen: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Laut HTTP Archive Web Almanac 2024 erfüllen das auf Mobilgeräten nur 43 Prozent der Origins, auf Desktop 54 Prozent. Wer die Werte sauber misst und priorisiert vorgeht, holt sich einen messbaren Ranking- und Conversion-Vorteil.

Was sind Core Web Vitals 2026 wirklich?

Core Web Vitals sind drei nutzerzentrierte Performance-Metriken, mit denen Google die reale Erfahrung auf einer Seite misst. Stand 2026 sind das LCP, INP und CLS. INP ersetzt seit dem 12. März 2024 offiziell den älteren FID-Wert. Die Daten stammen aus dem Chrome User Experience Report, also aus echten Browsersessions, nicht aus Laborwerten.

Wichtig: Google bewertet das 75. Perzentil. Das heißt, drei von vier Ihrer Besucher müssen die Schwellenwerte erleben, nicht nur der Durchschnitt. Diese Definition steht so in den offiziellen web.dev-Artikeln zu LCP. Sie erklärt, warum gute Laborwerte trotzdem zu einem roten PageSpeed-Bericht führen können.

Die Vitals sind außerdem Teil des umfassenderen Page-Experience-Signals von Google. Sie wirken also nicht isoliert. Sicheres HTTPS, Mobilfreundlichkeit und intrusive Interstitials zählen mit.

Welche drei Kennzahlen Sie kennen müssen

Drei Werte, drei Fragen.

LCP, kurz für Largest Contentful Paint, beantwortet: Wann sieht der Nutzer den Hauptinhalt? Meist ist das ein Hero-Bild, eine Headline oder ein Banner. Zielwert: 2,5 Sekunden oder schneller.

INP, Interaction to Next Paint, misst die Reaktionszeit über die gesamte Sitzung. Klick, Tap, Tastatureingabe. Maximalziel: 200 Millisekunden.

CLS, Cumulative Layout Shift, prüft visuelle Stabilität. Springt der Button beim Laden weg? Verschiebt sich Text durch nachladende Werbung? Akzeptiert sind Werte ≤ 0,1, dokumentiert auf web.dev: CLS.

Wie messe ich Core Web Vitals richtig?

Die belastbarste Quelle sind Felddaten aus dem Chrome User Experience Report (CrUX). Sie spiegeln, was echte Nutzer in den letzten 28 Tagen erlebt haben, ausgewertet am 75. Perzentil. Lab-Tools wie Lighthouse simulieren dagegen ein einzelnes Gerät unter Standardbedingungen. Beide gehören zusammen, doch entscheidend für Google ist das CrUX-Feld inklusive der dokumentierten 28-Tage-Methodik.

In meinen Performance-Audits bei Evelan sehe ich häufig den gleichen Fehler: Teams optimieren so lange, bis Lighthouse grün ist, und wundern sich, dass die Search Console weiterhin "verbesserungsbedürftig" meldet. Der Grund ist das 75. Perzentil über reale Geräte, nicht ein einziger Test auf einem schnellen Laptop.

Welche Tools nutze ich konkret?

Eine pragmatische Stack-Auswahl für den Mittelstand:

• PageSpeed Insights für die schnelle Diagnose. Liefert Feld- und Labordaten in einer Ansicht.
• Search Console, Bereich "Core Web Vitals". Hier sehen Sie aggregierte URL-Gruppen mit Status "schlecht", "verbesserungsbedürftig", "gut".
• Lighthouse oder DevTools-Performance-Panel im Chrome für die Tiefenanalyse einer einzelnen Seite.
• CrUX Dashboard oder das CrUX-API für Trendverläufe über mehrere Monate.

Wichtig ist, dass Sie nicht ständig zwischen Tools wechseln. Wählen Sie eine Quelle als "Single Source of Truth", in der Regel die Search Console, und nutzen Sie Lighthouse nur, um konkrete Hypothesen zu testen. Wer tiefer in die Wirkung von Geschwindigkeit auf Conversions einsteigen möchte, findet im Beitrag Blitzschnelle Website verwandelt Besucher in Käufer zusätzliche Fallzahlen aus unserer Praxis.

Welche Werte sind 2026 wirklich gut?

Die offizielle Schwellenwert-Tabelle hat sich seit dem INP-Launch im März 2024 nicht verändert. Google differenziert drei Bewertungsstufen pro Metrik und prüft das 75. Perzentil getrennt für Mobile und Desktop. Quelle: web.dev/articles/lcp, web.dev/articles/inp, web.dev/articles/cls.

Eine Seite muss in allen drei Werten "gut" liegen, damit Google die URL-Gruppe insgesamt als "gut" markiert. Das macht die Disziplin anspruchsvoll. Laut HTTP Archive Web Almanac 2024 erfüllen mit der INP-Metrik nur 43 Prozent der mobilen Origins alle drei Werte, auf Desktop sind es 54 Prozent.

Was viele übersehen: Der Wert "verbesserungsbedürftig" ist kein neutrales Mittelfeld. Google behandelt ihn in den Berichten der Search Console wie eine Warnung. Wer dauerhaft in dieser Zone landet, verliert in kompetitiven Keywords Boden gegen schneller optimierte Mitbewerber. Praktisch heißt das: Streben Sie konsequent das grüne Feld an, nicht das gelbe.

Warum belohnt Google schnelle Seiten überhaupt?

Google möchte Nutzer schnell zum Ergebnis bringen. Eine Seite, die drei Sekunden braucht, verliert spürbar Klicks und Conversions. Die offiziellen PageSpeed-Insights-Dokumente zeigen, wie eng Ladezeit, Absprungrate und Sichtbarkeit zusammenhängen. Eine langsame Seite verliert nicht erst nach Sekunden, sondern bereits in den ersten Bruchteilen davon. Das verändert das Sucheinkommen direkt.

Daraus folgt eine doppelte Wirkung. Erstens fließen die Core Web Vitals in das Page-Experience-Signal ein, das ein dokumentierter Ranking-Hinweis ist. Zweitens beeinflussen schnelle Seiten Verweildauer, Bounce und Conversion. Beide Effekte verstärken sich, sind aber unabhängig voneinander messbar.

Was bedeutet das für mittelständische Websites?

Aus über 60 Mittelstands-Projekten weiß ich: Wer LCP um eine Sekunde drückt, sieht in der Regel sofort eine bessere Klickrate aus Google Discover und Mobile Search. Die Effekte sind einzeln betrachtet nicht spektakulär, summieren sich aber über Quartale. Besonders B2B-Seiten mit langem Sales-Zyklus profitieren, weil Wiederbesucher die schnellere Seite als "wertiger" wahrnehmen.

Hinzu kommt ein Aspekt, den viele unterschätzen. Performance ist eine Stellvertretergröße für Sorgfalt. Eine Seite, die mit Hero-Bild, sauberer Typografie und ohne Layout-Sprünge lädt, vermittelt Kompetenz, bevor das erste Wort gelesen wird. Das wirkt sich in B2B besonders stark aus, weil hier die Entscheidung selten beim ersten Besuch fällt.

Was sind die häufigsten Ursachen schlechter Core Web Vitals?

Drei Ursachen tauchen in meinen Audits immer wieder oben auf: unoptimierte Bilder, JavaScript-Overhead und ein langsamer Server. Wer an diesen drei Stellen ansetzt, deckt im typischen Fall die größten Engpässe ab, bevor man sich an Detail-Tuning macht. Die offiziellen Optimierungs­leitfäden LCP optimieren und INP optimieren auf web.dev nennen dieselben Hauptthemen: Time to First Byte, render-blockierende Skripte, große Bilder und lange Main-Thread-Tasks.

Wie wirken sich Bilder und Medien aus?

Unoptimierte Hero-Bilder sind der häufigste LCP-Killer. Eine 3-MB-JPEG-Datei aus der DSLR-Kamera blockiert das Rendering messbar. Lösung: moderne Formate wie AVIF oder WebP, korrekte srcset-Anweisungen, Lazy-Loading für Bilder unterhalb des Folds und das fetchpriority-Attribut auf "high" für das LCP-Element.

Auch Video-Embeds wirken sich aus. Ein eingebetteter YouTube-Player lädt mehrere hundert Kilobyte JavaScript, bevor irgendetwas Sichtbares passiert. Eine Lite-Embed-Variante mit Klick-zum-Laden ist meist die bessere Wahl.

Wie viel Schaden richten Skripte und Plugins an?

JavaScript ist der größte Faktor für INP. Jedes nicht genutzte Tracking-Skript, jeder Chat-Widget-Loader, jeder A/B-Test-Snippet blockiert den Main-Thread. Folge: Klicks reagieren träge, INP rutscht über 200 Millisekunden.

Konkrete Hebel: Third-Party-Skripte auf das Minimum reduzieren, Consent-Layer so bauen, dass nicht-essentielle Skripte erst nach Zustimmung laden, und schwere Komponenten per Code-Splitting nachladen. Wir messen den Effekt fast immer am gleichen Tag im Search-Console-Bericht. Wer technisch tiefer einsteigen will, findet im Vergleich Headless CMS vs. klassisches CMS eine Übersicht, warum moderne Architekturen die INP-Kontrolle vereinfachen.

Welche Rolle spielt das Hosting?

Eine langsame Server-Antwort wirkt sich direkt auf LCP aus, weil der Browser nichts rendern kann, bevor das HTML eintrifft. Ein TTFB (Time to First Byte) über 800 Millisekunden ist ein Warnsignal. Häufige Ursachen: günstiges Shared-Hosting, fehlendes CDN, kein HTTP/2 oder HTTP/3, kein serverseitiger Cache. Hier hilft oft schon der Wechsel zu einem Edge-Hosting wie Vercel, Netlify oder einem dedizierten Cloud-Server mit Cloudflare davor.

Warum unterscheidet Google Mobile und Desktop?

Google bewertet beide Geräte­klassen getrennt im Search-Console-Bericht. Das ist kein Detail. Der Anteil mobiler Origins, die alle drei Vitals bestehen, ist laut HTTP Archive Web Almanac 2024 deutlich niedriger als auf Desktop. Mobile Hardware ist langsamer, Mobilfunknetze schwanken, und Touch-Interaktionen sind anders zu beurteilen als Mausklicks.

Praktisch heißt das: Eine Seite kann auf Desktop grün leuchten und auf Mobile durchfallen. In meiner Audit-Praxis ist das die Regel, nicht die Ausnahme. Wer die CWV ernst nimmt, optimiert grundsätzlich mobile-first und nutzt die Desktop-Werte nur als Plausibilitäts­check.

Welche Geräte berücksichtigt der CrUX-Datensatz?

Der Chrome User Experience Report aggregiert anonymisierte Felddaten von Chrome-Nutzern, die der Telemetrie zugestimmt haben. Aufgeteilt wird nach Form-Factor (Phone, Tablet, Desktop) und Verbindungsgeschwindigkeit. Wer ein primär B2B-orientiertes Angebot hat, sollte trotzdem die Mobile-Werte nicht ignorieren. Recherche und Erstkontakt finden in zunehmender Zahl auf dem Smartphone statt, auch wenn die finale Conversion am Desktop liegt.

Wie optimiere ich Core Web Vitals schrittweise?

Es gibt eine bewährte Reihenfolge, die ich jedem Mittelständler empfehle: messen, priorisieren, größten Hebel zuerst, danach kontrollieren. Ohne Baseline-Messung optimieren Sie blind. Ohne Priorisierung verzetteln Sie sich. Ohne Kontrolle wissen Sie nicht, ob die Maßnahme tatsächlich gewirkt hat. Als Diagnose-Werkzeug nutze ich dabei standardmäßig PageSpeed Insights als ersten Anlaufpunkt, weil das Tool Feld- und Labordaten in einer Ansicht zusammenführt.

Schritt 1: Baseline ehrlich aufnehmen

Notieren Sie pro Seitentyp (Startseite, Produktseite, Kategorie, Blog) den aktuellen LCP-, INP- und CLS-Wert im 75. Perzentil. Quelle: Search Console oder CrUX-Dashboard, nicht Lighthouse. Diese Baseline ist Ihr Bezugspunkt für jede Änderung.

Schritt 2: Bilder und LCP-Element fixen

Der LCP-Hebel ist meistens am größten und am schnellsten umgesetzt. Hero-Bild komprimieren, in AVIF oder WebP konvertieren, korrekte Dimensionen ausliefern, das fetchpriority-Attribut auf "high" setzen, Web-Fonts mit der font-display-Strategie "swap" ausliefern. Eine Woche Arbeit, oft eine Sekunde Gewinn beim LCP.

Schritt 3: JavaScript-Last reduzieren

Inventarisieren Sie alle Third-Party-Skripte. Streichen Sie alles, was nicht aktiv genutzt wird. Verschieben Sie Tracking hinter den Consent-Layer. Lazy-Loaden Sie schwere Komponenten wie Chat-Widgets, Karten oder Tabs. Erwartbarer Effekt: INP fällt häufig um 100 bis 300 Millisekunden.

Schritt 4: CLS-Quellen abdichten

Reservieren Sie Platz für Bilder über width- und height-Attribute, für Werbung per CSS-Aspect-Ratio und für eingebettete Inhalte über einen festen Container. Die meisten CLS-Probleme verschwinden mit drei bis fünf gezielten CSS-Änderungen.

Schritt 5: Monitoring etablieren

Optimierung ohne Monitoring führt verlässlich zu Rückfall. Plugins werden ergänzt, Tracking wird nachgerüstet, ein neues Bild rutscht ins Hero. Schon nach drei Monaten sind die alten Werte zurück. Mein Vorschlag: Wöchentlicher Blick in den Core-Web-Vitals-Bericht der Search Console und ein monatlicher Vergleich der CrUX-Werte je Seitentyp.

Bei größeren Sites lohnt sich ein automatisiertes Real-User-Monitoring (RUM), das Felddaten direkt aus dem eigenen Tag erfasst. Damit haben Sie eine Frühwarn­funktion, die nicht erst mit 28 Tagen Verzögerung anschlägt. Wer fundierte SEO-Grundlagen kombinieren möchte, findet im Beitrag SEO Grundlagen: So wird Ihre Website sichtbar die strategische Einordnung.

Welche Maßnahmen bringen wenig oder gar nichts?

Gerade weil Performance-Beratung ein eigener Markt ist, kursieren Empfehlungen, die im Mittelstand mehr Aufwand als Wirkung erzeugen. Drei Beispiele aus Audits, die mir regelmäßig begegnen.

Erstens: Generische "Speed-Plugins" für WordPress. Sie bündeln oft viele Funktionen, die einzeln betrachtet sinnvoll sind, in Summe aber zusätzliche Komplexität und Konfliktpotenzial bringen. Ohne klare Diagnose, welcher Hebel überhaupt drückt, wird Aktionismus zur Falle.

Zweitens: HTTP/3 als alleinige Lösung. Modernes Protokoll-Tuning bringt im Mittel wenige Millisekunden TTFB, ist also kein Ersatz für strukturelle Maßnahmen an Bildern oder Skripten. Es ist die Kirsche auf der Torte, nicht das Fundament.

Drittens: Vorzeitige Server-Aufrüstungen. Wer auf einem schwachen Plan klemmt, sollte zwar wechseln. Doch wer das LCP-Problem mit "größerer Maschine" lösen will, ohne Hero-Bild und JavaScript anzufassen, kauft sich oft nur ein paar Prozent Verbesserung für viel Geld. Die Reihenfolge bleibt: Inhalt prüfen, Code optimieren, dann erst Infrastruktur skalieren.

Verwandte Evelan-Artikel

• Blitzschnelle Website verwandelt Besucher in Käufer
• SEO Grundlagen: So wird Ihre Website sichtbar
• SEO-Fehler erkennen und die Website wirksam optimieren
• Headless CMS vs. klassisches CMS

Quellen

• Google web.dev: Largest Contentful Paint (LCP) (2024)
• Google web.dev: Interaction to Next Paint (INP) (2024)
• Google web.dev: Cumulative Layout Shift (CLS) (2024)
• Google web.dev: INP is now a Core Web Vital (2024, Blog)
• Google Search Central: Page Experience (2024)
• HTTP Archive: Web Almanac 2024, Performance Chapter (2024)
• Chrome for Developers: CrUX Methodology (2024, Dokumentation)
• Google: PageSpeed Insights (2024, Tool)