Core Web Vitals optimieren: Drei Hebel zuerst prüfen

Nur 48 Prozent der mobilen Websites erreichen 2025 gute Core Web Vitals, auf dem Desktop sind es 56 Prozent. Nach diesem Ratgeber wissen Sie, welcher der drei Werte bei Ihrer Website zuerst dran ist, wie Sie ihn belastbar messen und wann ein Relaunch die falsche Antwort ist. Die Reihenfolge ersetzt die Maßnahmenliste.

Wie wichtig sind Core Web Vitals für SEO?

Core Web Vitals sind ein Ranking-Signal, kein Rang-Garant. Google führt sie in der Search-Central-Dokumentation als Teil der Nutzerfreundlichkeit, die die Ranking-Systeme berücksichtigen. Googles John Mueller nennt sie zugleich keine großen Ranking-Faktoren: Bei zwei ähnlich relevanten Seiten geben sie den Ausschlag, bei schwachem Inhalt retten sie nichts.

Seit dem Page Experience Update von 2021 gehören die drei Werte zum Ranking-System. Ihr Gewicht liegt hinter der inhaltlichen Relevanz, und genau das ist für die Priorisierung wichtig. Wer auf Position acht steht und der Wettbewerber auf drei, findet die Ursache selten im Ladewert.

Die Verbreitung guter Werte steigt trotzdem langsam. Laut Web Almanac 2025 stieg der Anteil mobiler Websites mit guten Core Web Vitals von 36 Prozent im Jahr 2023 über 44 Prozent auf 48 Prozent. Eine Website, die heute alle drei Werte besteht, gehört mobil noch zur Minderheit.

Der zweite Grund liegt außerhalb des Rankings. Die Google-Studie Milliseconds Make Millions aus dem Jahr 2020, durchgeführt mit Deloitte, maß, was 0,1 Sekunden schnellere mobile Ladezeit bewirken: Auf Lead-Generierungs-Seiten sank die Absprungrate um 8,3 Prozent. Für Anfrageformulare im B2B ist das der relevante Wert, nicht die Retail-Conversion.

Der übliche Leitfaden versagt an genau dieser Stelle. Er listet zwanzig Maßnahmen von Bildkompression bis Server-Push, gewichtet sie nicht und lässt offen, welche davon ohne Entwickler auskommt. Das Ergebnis ist ein Plugin-Stapel, der den Labor-Score hebt und den Feldwert unverändert lässt.

Welcher der drei Werte diese Reihenfolge anführt und warum, zeigt der nächste Abschnitt.

Core Web Vitals optimieren in der richtigen Reihenfolge: LCP vor INP vor CLS

In B2B-Industrie-Mandaten zeigt sich typischerweise dasselbe Bild wie in der Gesamtstatistik: Der Ladewert LCP fällt zuerst. Laut Web Almanac 2025 bestehen mobil 62 Prozent der Websites den LCP, 77 Prozent den INP und 81 Prozent den CLS. Die Reihenfolge ist ein Mehrheitswert über Millionen Websites, keine Diagnose Ihrer Seite. Ob das auch für Ihre URLs gilt, zeigt erst die Messung.

Die Schwellen definiert Google in derselben Dokumentation: Ein LCP innerhalb von 2,5 Sekunden gilt als gut, ein INP unter 200 Millisekunden, ein CLS unter 0,1. Bewertet wird das 75. Perzentil der Feldwerte, also der Aufruf, den drei von vier Besuchern mindestens erreichen.

Die Pass-Raten zeigen, wo die Mehrheit scheitert, und sie unterscheiden sich nach Gerät.

Anteil der Websites mit guten Werten je Metrik (2025)

Kernaussage: Mobil erreichen laut Web Almanac 2025 nur 62 Prozent der Websites einen guten LCP, bei CLS sind es 81 Prozent. Auf dem Desktop bestehen 97 Prozent den INP, aber nur 72 Prozent den CLS. Der Ladewert ist mobil der häufigste Fehlwert, das Layout ist es auf dem Desktop.

Daraus folgt die Reihenfolge. LCP steht vorn, weil er am häufigsten fällt und weil seine Ursachen fast ausnahmslos an einem einzigen Element hängen: dem größten Bild oder Textblock im sichtbaren Bereich. INP folgt, weil seine Ursachen in Skripten liegen, die meist außerhalb des eigenen Codes entstehen. Größenangaben und reservierter Platz sind die schnellsten Korrekturen, deshalb steht CLS am Ende.

Der einfachste Fix zuerst klingt verlockend, hebt aber häufig einen Wert, der die Schwelle schon erfüllt.

Es ist nicht die Menge der Maßnahmen. Es ist die Reihenfolge. Wer mit dem Wert beginnt, der bei der eigenen Seite am weitesten von der Schwelle entfernt ist, verändert die Bewertung in der Search Console, statt an drei Fronten gleichzeitig zu arbeiten.

Wie kann ich die Core Web Vitals messen?

Core Web Vitals messen Sie in zwei Datenquellen, und nur eine zählt für Google. Felddaten aus dem Chrome User Experience Report (CrUX) stammen von echten Besuchern und speisen den Core-Web-Vitals-Bericht der Google Search Console. Labordaten aus Lighthouse oder dem unteren Teil von PageSpeed Insights simulieren einen Aufruf. Google bewertet laut Dokumentation ausschließlich die Feldwerte am 75. Perzentil.

PageSpeed Insights und Lighthouse beantworten ähnliche Fragen, aber auf verschiedenen Ebenen. Der Labor-Score misst einen simulierten Aufruf unter festen Bedingungen: ein gedrosseltes Gerät, eine feste Leitung, kein Consent-Banner. Der Feldwert misst, was Ihre Besucher auf ihren Geräten und in ihren Netzen erleben. Nur der zweite Wert steht in der Search Console.

Wer Core Web Vitals testen will, braucht deshalb beide Ansichten in dieser Reihenfolge. PageSpeed Insights zeigt oben die Felddaten der letzten 28 Tage und darunter den Laborlauf mit den konkreten Ursachen. Die Search Console zeigt, welche URL-Gruppen betroffen sind. Erst die Kombination sagt, wo Sie ansetzen.

Wie interpretiere ich die Ergebnisse?

Die häufigste Frage in der Google Search Central Community lautet wörtlich: „Why are my ‘Core Web Vitals’ bad in Search Console but not on pagespeed.web.dev?“ (Google Search Central Community, 2022).

Die Antwort ist die Datenquelle. Die Search Console zeigt Feldwerte, und im Labor fehlen genau die drei Dinge, die im Feld den Wert bestimmen: das Consent-Banner, das langsame Mobilfunknetz und die Skripte, die erst nach einem Klick nachladen.

Hinzu kommt die Stichprobe: Laut CrUX-Methodik stammen die Felddaten ausschließlich von Chrome-Nutzern. Websites mit hohem Safari-Anteil, etwa durch Entscheider auf Firmen-iPhones, sehen in der Search Console nur einen Teil ihrer Besucher abgebildet.

Der zweite Fall betrifft Websites mit wenig Traffic. CrUX braucht eine Mindestzahl an Aufrufen je URL und je Origin, sonst zeigt die Search Console dauerhaft „nicht genügend Daten“. Bei Katalog- und Nischenseiten im B2B ist das der Normalfall, nicht die Ausnahme. Dann bleiben Labordaten die einzige Diagnose, und die Seite wird über diesen Wert weder belohnt noch bestraft.

Der dritte Fall erzeugt die meiste Unruhe. Der Bericht bündelt ähnliche URLs zu Gruppen und rechnet im selben rollierenden Fenster von 28 Tagen wie oben. Kippt eine Vorlage über die Schwelle, kippt die ganze Gruppe.

So entsteht der Befund aus der Shopify Community: „my sites good URLS’s dropped from 77 to 0“ (Shopify Community, Thread „Core Web Vitals showing 0 Good URLS“). Die Seite wurde nicht über Nacht schlechter. Eine Vorlage überschritt einen Grenzwert, und die Gruppe folgte.

Diese drei Fälle decken den größten Teil der Interpretationsfehler ab. Wer sie kennt, liest den Bericht als das, was er ist: eine Aussage über Vorlagen und Besucher, keine Note für die Website.

Wie kann ich die Core Web Vitals verbessern?

Core Web Vitals optimieren Sie in der Reihenfolge der Fehlwerte: zuerst das LCP-Element, meist das größte Bild, dann die JavaScript-Last hinter dem INP, zuletzt die Layoutverschiebungen. Google nennt in seiner Liste der wirksamsten Maßnahmen je Metrik drei Hebel. Die Hebel unten sind diese drei, ergänzt um die Frage, welche davon ohne Entwickler auskommen.

LCP verbessern: Bild, Server, Render-Pfad

Die Frage, wie sich die PageSpeed einer Website verbessern lässt, meint in aller Regel den LCP. Laut web.dev ist bei 73 Prozent der mobilen Seiten ein Bild das LCP-Element. Nur 15 Prozent der infrage kommenden Seiten setzen das Attribut fetchpriority="high", und bei 35 Prozent steht die Bildquelle nicht im ursprünglichen HTML, weil ein Skript sie nachlädt.

Drei Maßnahmen decken den Großteil der Fälle ab. Erstens: Das LCP-Bild steht als normales <img> mit src oder srcset im HTML und bekommt fetchpriority="high". Zweitens: Genau dieses Bild trägt kein loading="lazy", auch wenn das Theme das für alle Bilder setzt.

Drittens: Die Serverantwort (Time to First Byte, TTFB) wird beschleunigt, denn laut derselben Quelle laufen nur 33 Prozent der HTML-Anfragen über ein CDN.

Ein vierter Hebel liegt in der Navigation: Der Back-Forward-Cache (bfcache) liefert Seiten beim Zurückspringen aus dem Speicher, sofern keine Cache-Control: no-store-Direktive ihn blockiert.

Der Ladewert hängt eng mit dem Page Speed der gesamten Seite zusammen, ist aber enger gefasst. Er misst nur, wann das größte sichtbare Element steht. Ein kleineres Bildformat und eine kürzere Serverantwort wirken deshalb direkt. Ein Cache-Plugin für die Unterseiten dagegen nicht.

INP optimieren: Long Tasks, Third-Party-Skripte, Consent-Banner

Der häufigste Stolperstein bei diesem Schritt ist ein Skript, das niemand im Haus bestellt hat: der Tag-Manager-Container, das Chat-Widget, das Consent-Banner, das A/B-Test-Tool. Seit dem 12. März 2024 misst INP die Reaktionszeit auf jede Interaktion und hat den First Input Delay abgelöst. Was vorher nur beim ersten Klick zählte, zählt jetzt bei jedem.

Die Ursache ist fast immer der Hauptthread. Aufgaben über 50 Millisekunden gelten laut web.dev als lange Aufgaben und blockieren jede Eingabe, bis sie fertig sind. Laut Web Almanac 2025 liegt die mittlere Total Blocking Time mobil bei 1.916 Millisekunden, nach 1.209 Millisekunden im Vorjahr. Die Seiten werden schwerer, nicht leichter.

Die Reihenfolge der Hebel: Erst das Skript-Inventar aufstellen und jedes Skript streichen, dessen Zweck niemand mehr benennen kann. Dann das Consent-Skript so laden, dass es nur beim Erstbesuch synchron läuft und bei gespeicherter Einwilligung asynchron. Zuletzt lange Aufgaben im eigenen Code aufteilen, etwa mit der Scheduler-API. Der erste Schritt braucht keinen Entwickler, die beiden anderen schon.

Hängen Vertrieb oder Marketing an einem Skript, das niemand streichen darf, bleibt als Kompromiss die Verzögerung bis nach dem Erstbesuch.

CLS verbessern: Größenangaben, Fonts, Banner

Layoutverschiebungen entstehen, wenn ein Element ohne reservierten Platz erscheint. Laut web.dev haben 66 Prozent der Seiten mindestens ein Bild ohne Größenangabe. Seiten, die margin oder border animieren, landen fast doppelt so häufig im schlechten Bereich wie Seiten insgesamt; transform löst dieselbe Bewegung ohne Layoutarbeit.

Die Korrekturen sind die schnellsten der drei Metriken. Jedes Bild und jedes Video bekommt width und height oder ein aspect-ratio. Web-Fonts laden mit font-display: swap und einer Fallback-Schrift mit ähnlicher Laufweite. Cookie-Hinweise, Banner und nachgeladene Produktkacheln bekommen einen festen Platz mit min-height, bevor sie erscheinen.

Bei Katalogseiten liegt die häufigste Verschiebung in der Produktliste: Die Kacheln laden ohne Höhe, das Filtermenü springt, der Besucher klickt daneben. Eine reservierte Höhe pro Kachel löst das ohne Änderung am Shop-System.

Mit diesen drei Hebeln ist die Reihenfolge gesetzt, und der Abschnitt danach zeigt, was beim Umsetzen trotzdem schiefgeht.

Typische Fehler, wenn Sie Core Web Vitals optimieren

Vier Fehler tauchen bei der Arbeit an Core Web Vitals immer wieder auf, und jeder hat eine konkrete Korrektur.

1. Der Labor-Score wird zum Ziel. Ein Wert von 100 in PageSpeed Insights beschreibt einen simulierten Aufruf, nicht die Feldwerte, die Google heranzieht. Die Zielgröße gehört deshalb in die Search Console, als Feldwert je URL-Gruppe. Der Labor-Score dient der Ursachensuche.

2. Das zweite Muster ist der Plugin-Stapel. Ein Cache-Plugin, ein Bild-Plugin, ein Skript-Verzögerungs-Plugin, jedes hebt den Labor-Score um ein paar Punkte, und das unkomprimierte Hero-Bild bleibt, wie es ist. Wer die Ursache im Labor-Bericht unter „Diagnose“ liest, braucht meist ein einziges Bildformat statt drei Erweiterungen.

3. Häufig übersehen wird das lazy geladene LCP-Bild. Manche Themes setzen loading="lazy" global, also auch auf das Hero-Bild, das der Browser sofort bräuchte. Die Korrektur besteht aus einer Ausnahme für genau dieses Element.

4. Und schließlich die Messung an der falschen Seite. Die Startseite ist optimiert, die Katalog- und Produktvorlagen tragen aber den Traffic und die Fehlwerte. Die Korrektur: Die Arbeit beginnt bei den Vorlagen hinter den URL-Gruppen aus dem Mess-Check oben.

Die Vorlage entscheidet vor der Metrik

Die vier Fehler haben eine gemeinsame Wurzel, und sie liegt vor der Technik.

Die Einschätzung stammt aus eigenen Mandaten, keine Studie. Sie beschreibt, warum die meisten Anleitungen zu Core Web Vitals bei WordPress-Themes beginnen und bei Katalog-Vorlagen mit Konfigurator aufhören. Wer die falsche Vorlage optimiert, misst am Ende den falschen Wert.

Optimieren oder Relaunch? Der Entscheidungsrahmen

Die Frage nach dem Relaunch stellt sich bei schlechten Core Web Vitals früher, als der Befund es rechtfertigt. Es ist nicht die Frage, ob der Relaunch die Werte verbessert. Es ist die Frage, ob er die Rankings überlebt. Wer die Entscheidung am Befund festmacht, kommt in den meisten Fällen bei gezielten Fixes heraus.

Zwei Konstellationen trennen die Fälle. Wer ein Bild- und Skriptproblem hat, fährt mit gezielten Fixes in Wochen ins Ziel und riskiert keine URL-Struktur. Wer eine Vorlage mit Render-Blocking im Kern und einem Seitenaufbau aus verschachtelten Skripten hat, zahlt jeden Einzelfix doppelt und erreicht die Schwelle trotzdem nicht.

Trifft die rechte Spalte in zwei oder mehr Zeilen zu, ist die Vorlage das Problem, und ein Relaunch wird zur Option. Dann gilt die Reihenfolge aus dem Vergleich Relaunch oder Optimierung: erst die Rankings sichern, dann die Technik wechseln. Wie das Redirect-Konzept und die Messung davor aussehen, steht unter Rankings beim Relaunch sichern.

Trifft die linke Spalte zu, ist der Relaunch der teurere Weg zu demselben Ergebnis. Die drei Hebel aus dem Abschnitt oben greifen dann innerhalb einer Vorlage, und die Search Console zeigt die Wirkung nach dem nächsten Messfenster. Einen Relaunch allein wegen eines roten Laborwerts empfehlen wir nicht, unabhängig davon, wie deutlich der Score rot ist.

Wie stark die Vorlage dabei im technischen Mittelstand wiegt, zeigt der letzte Abschnitt vor dem Fazit.

Core Web Vitals im technischen B2B-Mittelstand: Kataloge, Konfiguratoren, Bildlast

Im technischen Mittelstand verschiebt sich der Fokus typischerweise weg von der Startseite und hin zu den Vorlagen, die den Katalog tragen. Produkt- und Kategorieseiten mit vielen Bildern, technischen Zeichnungen und Datenblatt-Vorschauen ziehen den LCP nach oben. Konfiguratoren und Anfrageformulare mit Live-Validierung ziehen den INP nach oben. Beides entsteht in einer Vorlage und wiederholt sich über hunderte URLs.

Genau diese Vervielfachung macht die Reihenfolge im B2B so wirksam. Eine Korrektur an der Katalogvorlage verbessert jede Produktseite, die daraus gebaut ist. Umgekehrt schlägt ein Fehler in der Vorlage auf die gesamte URL-Gruppe durch, während die Startseite grün bleibt. Das ist der Grund, warum der Mess-Check oben nach Vorlagen fragt und nicht nach Einzelseiten.

Drei Fragen helfen bei der Einordnung: Ob das größte Bild auf der Katalogseite ein Produktfoto oder ein dekoratives Hintergrundbild ist. Ob das PIM- oder Shop-System die Produktdaten im HTML ausliefert oder erst per Skript nachlädt. Und ob der Konfigurator bei jeder Eingabe den ganzen Seitenbereich neu rendert. Ist eine Antwort ungünstig, ist das die nächste Aufgabe.

Die richtige Ausgangshaltung zeigt ein Beitrag aus der Shopify Community: „My site is performing well, but needs some technical tweaks to hit Google’s ‘Good’ thresholds“ (Shopify Community). Diese Formulierung zeigt, dass es um Schwellen je Vorlage geht und nicht um einen neuen Auftritt.

Für Websites mit vielen Produktseiten gehört diese Prüfung in jedes technische SEO und in jeden SEO-Audit, bevor ein Relaunch überhaupt diskutiert wird.

Fazit & Takeaways

• Felddaten entscheiden. Prüfen Sie den Wert je URL-Gruppe in der Search Console am 75. Perzentil, bevor Sie eine Maßnahme beauftragen. Ein grüner Labor-Score allein ändert an der Bewertung nichts.
• LCP zuerst. LCP-Bild im HTML mit fetchpriority="high", kein Lazy Loading auf dem Hero, kürzere Serverantwort.
• INP danach. Skript-Inventar aufstellen, jedes Skript ohne benennbaren Zweck streichen, Consent-Banner und Tag-Manager entschlacken, lange Aufgaben unter 50 Millisekunden halten.
• CLS zuletzt. Größenangaben setzen, Platz für Banner reservieren.
• Relaunch nur bei Stack-Befund. Trifft die rechte Spalte des Entscheidungsrahmens in zwei Zeilen zu, kommt der Relaunch in Frage, und dann mit Redirect-Konzept.

Wir vergeben pro Quartal vier Projektplätze für technisches SEO im technischen B2B-Mittelstand. Der erste Schritt ist eine Erstdiagnose, in der wir prüfen, wo Ihre Feldwerte stehen, welcher der drei Hebel zuerst greift und ob gezielte Fixes reichen oder die Vorlage das Problem ist. Ergebnis ist eine Einschätzung der Reifegrade, keine Pauschal-Roadmap.

Autor: Daniel Neubauer, Geschäftsführer RED RAM MEDIA. Seit 2010 als Agenturinhaber im SEO tätig, mit Schwerpunkt auf technischem SEO für Industrie- und Katalog-Websites im B2B-Mittelstand.

Häufige Fragen (FAQ)

Was sind die Core Web Vitals?

Core Web Vitals sind drei von Google definierte Messwerte für Ladezeit (LCP), Reaktionszeit (INP) und visuelle Stabilität (CLS) einer Seite, erhoben an echten Besuchern. Die Definitionen, Schwellen und Messgrundlagen stehen im Lexikon-Eintrag zu Core Web Vitals.

Warum sind Core Web Vitals wichtig?

Core Web Vitals beeinflussen das Ranking als Signal für Nutzerfreundlichkeit und die Conversion über die Ladezeit. Google zieht sie in den Ranking-Systemen heran, die inhaltliche Relevanz wiegt schwerer.

Wie lange dauert es, bis bessere Werte in der Search Console sichtbar sind?

Verbesserte Werte erscheinen in der Search Console nach bis zu 28 Tagen, weil der Chrome User Experience Report ein rollierendes 28-Tage-Fenster auswertet. Der Laborwert in PageSpeed Insights reagiert sofort, der Feldwert erst mit neuen Besucherdaten.

Reicht ein guter PageSpeed-Score?

Ein guter PageSpeed-Score reicht nicht, weil Google die Felddaten am 75. Perzentil bewertet und der Labor-Score einen einzelnen simulierten Aufruf zeigt. Welche Hebel den Page Speed im Feld verbessern, hängt vom LCP-Element und der Skriptlast ab.