Core Web Vitals im Jahr 2026: Vollständiger Leitfaden für LCP, CLS, INP

Core Web Vitals (CWV) sind Googles standardisierte Kennzahlen zur Seitenerfahrung, die messen, wie schnell, stabil und responsiv sich eine Webseite für einen echten Nutzer anfühlt. Im Jahr 2026 lauten die drei Metriken Largest Contentful Paint (LCP, Ziel 2,5 Sekunden oder weniger), Cumulative Layout Shift (CLS, Ziel 0,1 oder weniger) und Interaction to Next Paint (INP, Ziel 200 ms oder weniger, nachdem First Input Delay im März 2024 ersetzt wurde). CWV sind bestätigte Google-Ranking-Signale als Teil des Page Experience-Signalclusters und korrelieren stark mit der Konversion: Branchendaten zeigen durchweg, dass die Konversionsrate von 1 auf 3 Sekunden um 5 bis 25 Prozent gestiegen ist. Das ehrliche Bild von CWV im Jahr 2026: Sie sind notwendig, aber nicht ausreichend. Websites mit schlechtem CWV werden Schwierigkeiten haben, in kommerziellen Kategorien wettbewerbsfähig zu werden, aber Websites mit perfektem CWV, aber schwachem Inhalt, geringer Autorität oder schlechtem UX werden auch nicht ranken. Betrachte CWV als die technische Grundlage, auf der deine Inhalte und deine Autorität funktionieren, nicht als magischen SEO-Hebel. Die größten praktischen Probleme im Jahr 2026 sind JavaScript-lastige Frontends, die INP-Fehler verursachen, Seitenersteller (Elementor, Divi), die Layoutänderungen verursachen, Skripte von Drittanbietern (Analysen, Chat-Widgets, Anzeigen-Tags), die den Hauptthread blockieren, und unoptimierte Bilder, die LCP dominieren. Die Problembehebungen sind allgemein bekannt: Bildoptimierung, Eliminierung von Inhalten, die das Rendern blockieren, Skriptverwaltung von Drittanbietern über verzögertes Laden oder Fassadenmuster und ein CDN. Dieser Leitfaden behandelt, was die einzelnen Metriken messen, die Schwellenwerte von 2026, warum sie für Rankings und Konversionen wichtig sind, häufige Fehlermodi pro Metrik, plattformspezifische Muster (Webflow, WordPress, Shopify, Next.js), Messwerkzeuge, mobile Realität, Implementierungsfahrplan und Warnsignale in allen Anbieterangeboten.

Was sind Core Web Vitals im Jahr 2026

Core Web Vitals sind eine Untergruppe von Web Vitals, einer umfassenderen Google-Initiative zur Standardisierung der Messung von Seitenleistung und Nutzererlebnis. Bei den Core Web Vitals handelt es sich um drei Metriken, die ausgewählt wurden, weil sie die wichtigsten Aspekte der tatsächlichen Nutzererfahrung erfassen: Ladegeschwindigkeit (LCP), visuelle Stabilität (CLS) und Reaktionsfähigkeit auf Nutzerinteraktionen (INP).

Largest Contentful Paint (LCP) misst, wie schnell das größte sichtbare Inhaltselement beim ersten Laden der Seite im Viewport gerendert wird. Das Element ist in der Regel ein Hero-Bild, ein Hero-Videoposter oder ein großer Textblock. Der Schwellenwert liegt bei 2,5 Sekunden oder weniger, gemessen am 75. Perzentil der realen Benutzerdaten. Langsames LCP fühlt sich langsam an, weil die Seite leer oder hängen bleibt, während der Benutzer darauf wartet, dass der Hauptinhalt erscheint.

Cumulative Layout Shift (CLS) misst die visuelle Stabilität, indem es quantifiziert, wie stark sich Elemente beim Laden der Seite und während der Benutzerinteraktion bewegen. Ein Wert von 0,1 oder weniger ist gut. Dieser Wert wird berechnet, indem der Wirkungsanteil (wie stark das Viewport betroffen ist) mal der Entfernungsanteil (wie weit sich die Elemente bewegen) berechnet wird. Ein hoher CLS-Wert fühlt sich fehlerhaft an, weil der Benutzer versucht, auf etwas zu klicken, und das Layout sich ändert, sodass er auf das falsche Objekt klickt.

Interaction to Next Paint (INP) misst die Reaktionsfähigkeit, indem es die Zeit von der Interaktion eines Benutzers (Klicken, Tippen, Tastendruck) bis zu dem Zeitpunkt, an dem die Seite sichtbar reagiert, erfasst. INP ersetzte im März 2024 die First Input Delay (FID), da es die Reaktionsfähigkeit aller Interaktionen erfasst, nicht nur bei der ersten. Der gute Schwellenwert liegt bei 200 ms oder weniger. Ein hoher INP fühlt sich verzögert an: Der Benutzer klickt, nichts passiert, er klickt erneut, dann wird die Aktion zweimal ausgelöst.

Neben den Core Web Vitals sind zwei unterstützende Metriken von Bedeutung: Time to First Byte (TTFB, Ziel 800 ms oder weniger) misst die Antwortgeschwindigkeit des Servers, und First Contentful Paint (FCP, Ziel 1,8 Sekunden oder weniger) misst, wann Inhalte zum ersten Mal erscheinen. TTFB ist LCP vorgeschaltet, daher hilft es LCP in der Regel, TTFB zu korrigieren. FCP wird manchmal als Proxy für die wahrgenommene Ladegeschwindigkeit verwendet.

Alle Core Web Vitals werden mit dem 75. Perzentil der tatsächlichen Nutzerdaten gemessen, was bedeutet, dass mindestens 75 Prozent der Seitenzugriffe den Schwellenwert erreichen müssen, damit die Seite als bestanden gilt. Das ist es, worauf Google beim Ranking achtet, nicht auf Labordaten aus synthetischen Tests. Labordaten (Lighthouse, WebPageTest) sind nützlich für das Debuggen und Testen vor der Bereitstellung. Das Ranking-Signal stammt jedoch aus den CruX-Daten (Chrome User Experience Report), die von echten Nutzern gesammelt wurden.

Warum Core Web Vitals wichtig sind: Ranking und Konversion

CWV wirken sich auf zwei Geschäftsergebnisse aus, die sich verstärken: Suchrankings und Konversionsrate. Die Mechanismen sind unterschiedlich, verstärken sich aber.

Suchrankings: CWV sind seit Juni 2021 im Rahmen des Page Experience-Updates bestätigte Google-Ranking-Signale und werden dies auch 2026 bleiben. Das Signal ist kein Unentschieden zwischen zwei gleichwertig relevanten Seiten; es ist ein bedeutsamer Faktor für Grenzfälle und ein signifikanterer Faktor für Websites mit weit verbreiteten CWV-Ausfällen. Google hat erklärt, dass CWV nicht der wichtigste Faktor sind (Relevanz und Autorität dominieren), aber sie sind real, insbesondere bei kommerziellen Suchanfragen, bei denen viele Websites ähnlich relevant sind. Websites, die bei vielen URLs bei CWV durchfallen, haben es schwerer, in diesen Wettbewerbskategorien zu ranken.

Steigerung der Konversionsrate: Branchendaten zeigen durchweg eine Verbesserung der Konversionsrate von 1 bis 3 Sekunden um 5 bis 25 Prozent. Walmart meldete einen Anstieg der Konversionsrate um 2 Prozent pro Sekunde der Geschwindigkeitsverbesserung. Vodafone meldete eine Umsatzsteigerung von 8 Prozent, da das LCP um 31 Prozent verbessert wurde. Das Muster gilt für E-Commerce-, B2B-SaaS-, Lead-Generierung- und Content-Websites. Der Mechanismus ist einfach: Schnellere Seiten reduzieren die Absprungrate, erhöhen die Anzahl der Seiten pro Sitzung und reduzieren die Reibung an Entscheidungspunkten.

Auswirkungen auf die Absprungrate: Seiten, die in 1 bis 3 Sekunden geladen werden, haben 32 Prozent höhere Absprungraten als Seiten unter einer Sekunde; im Bereich von 3 bis 5 Sekunden sind 90 Prozent höhere Absprungraten zu verzeichnen. Die Verluste werden im Laufe der Zeit immer größer, da immer mehr Nutzer die Seite verlassen, bevor die Seite vollständig geladen ist.

Die Crawling-Effizienz ist wichtig für große Websites: Der Googlebot verteilt das Crawling-Budget auf der Grundlage der Reaktionsfähigkeit der Website. Langsame Websites werden weniger gecrawlt, was bedeutet, dass weniger Seiten indexiert werden und der Index nach Inhaltsänderungen langsamer aktualisiert wird. Bei Websites mit Tausenden oder Zehntausenden von Seiten führen CWV-Fehler direkt zu Indexierungsproblemen.

Korrelation der Sichtbarkeit von KI-Engines: KI-Engines (Anthropic Claude, Perplexity, ChatGPT-Suchtools) zitieren bevorzugt schnellere Websites, da ihre Crawler Inhalte zuverlässiger extrahieren können. Langsame Websites mit Rendering-Problemen werden seltener zitiert. Da die Sichtbarkeit der KI-Engine zu einem wichtigen Entdeckungskanal wird, wird CWV auch Teil von AEO, nicht nur von herkömmlicher Suchmaschinenoptimierung.

Largest Contentful Paint (LCP): häufig auftretende Probleme und Problembehebungen

LCP ist in der Regel das sichtbarste Core Web Vital, da es direkt mit der Wahrnehmung des Benutzers korreliert, „wie schnell diese Seite geladen wird“. Es ist auch die Metrik, bei der die größte Lücke zwischen den besten und den schlechtesten Ergebnissen besteht. Gut optimierte Websites erreichen 1,5 Sekunden, während schlecht optimierte Websites über 8 Sekunden lang sein können.

Die häufigsten LCP-Probleme sind vorhersehbar. Das zu große Hero-Bild ist die häufigste Ursache; unkomprimierte JPGs über 500 KB oder übergroße Bilder, die mit voller Auflösung in kleinen Viewports angezeigt werden, dominieren LCP. Die Lösung besteht darin, in WebP oder AVIF zu konvertieren, für typische Hero-Bilder auf 80 bis 120 KB zu komprimieren und ansprechende Größen über srcset bereitzustellen.

Das Lazy-Loading des LCP-Elements ist eine sich selbst zugefügte Wunde, die entsteht, wenn Teams wahllos loading="lazy“ anwenden. Bilder, die ohne Scrollen angezeigt werden, sollten nicht verzögert geladen werden. Verwende loading="eager“ oder entferne das Attribut vollständig auf dem LCP-Element. Viele CMS und Frameworks erledigen das jetzt automatisch, aber ältere Websites haben oft das Problem.

JavaScript und CSS, die das Rendern blockieren, sind die zweithäufigsten LCP-Probleme. Synchrones JS im Head verzögert das Rendern, bis das Skript heruntergeladen und ausgeführt wird. Große CSS-Dateien blockieren das Rendern, bis der Download abgeschlossen ist. Die Korrekturen beziehen kritisches CSS ein, verzögern unkritisches JS, entfernen ungenutzte Skripte und minimieren alles.

Eine langsame Serverantwort (TTFB über 800 ms) kaskadiert in LCP, da nichts gerendert werden kann, bis der Server reagiert. Häufige Ursachen sind langsames Shared Hosting, fehlendes Seiten-Caching, Datenbankengpässe auf dynamischen CMS und fehlendes CDN. Die Lösung besteht aus Hosting-Upgrade plus Caching plus CDN; normalerweise alle drei zusammen.

Synchron geladene Webschriften blockieren das Rendern von Text. Verwenden Sie die Schriftanzeige: Tauschen Sie wichtige Schriftarten aus, laden Sie sie vorab herunter und nehmen Sie die benötigten Glyphen in Untergruppen vor. Bei markenkritischer Typografie vermeidet font-display: optional Layoutverschiebungen, zeigt aber bei langsamen Verbindungen möglicherweise Ersatzschriften an.

Skripte von Drittanbietern (Analysen, Chat-Widgets, Anzeigen-Tags) werden häufig vor dem Hauptinhalt geladen, da sie bei synchroner Ausführung in den Kopf injiziert werden. Die Lösung besteht darin, das Laden zu verschieben oder asynchron zu laden. Insbesondere Chat-Widgets sollten erst nach einer Benutzerinteraktion geladen werden.

Cookie-Banner, die das LCP-Element sind, treten auf, wenn das Banner groß, animiert oder so gestaltet ist, dass es das größte sichtbare Element ist. Optimieren Sie das Banner selbst, stellen Sie sicher, dass es das Rendern des zugrunde liegenden Inhalts nicht blockiert, und überlegen Sie, ob ein weniger aufdringliches Design die Einhaltung der Richtlinien erfüllt.

Hero Video Autoplay kann das LCP-Element unter die Falte drücken oder es komplett ersetzen. Verwende ein Posterbild, lade das Video selbst im Lazy-Modus und überlege, ob ein statisches Hero-Bild besser funktionieren würde als das Autoplay-Video.

Cumulative Layout Shift (CLS): häufig auftretende Probleme und Problembehebungen

CLS ist das am besten reparierbare Core Web Vital. Die Probleme sind vorhersehbar, die Problembehebungen sind allgemein bekannt und die meisten Websites können innerhalb weniger Stunden konzentrierter Arbeit ein gutes CLS erreichen. Die Herausforderung besteht darin, CLS auf dem neuesten Stand zu halten, wenn neue Inhalte und Funktionen hinzugefügt werden.

Bilder ohne Abmessungen sind die häufigste CLS-Ursache. Wenn ein IMG-Tag keine Breiten- und Höhenattribute hat, weiß der Browser nicht, wie viel Speicherplatz reserviert werden muss, bevor das Bild geladen wird. Daher ändern sich andere Inhalte, wenn das Bild ankommt. Die Lösung besteht darin, für jedes img-Element Breiten- und Höhenattribute (oder CSS für das Seitenverhältnis) festzulegen. Dies ist ein einmaliges standortweites Audit.

Wenn Webschriftarten ausgetauscht werden, fließt der Text neu, wenn die benutzerdefinierte Schriftart das Fallback ersetzt. Der Text ändert seine Breite oder Zeilenhöhe, wodurch alles, was darunter liegt, verschoben wird. Verwenden Sie font-display: optional, um den Austausch zu vermeiden, oder passen Sie die Metriken für Ersatzschriftarten mithilfe der CSS-Eigenschaften zur Größenanpassung an die benutzerdefinierte Schriftart an, oder laden Sie die Schrift vorab herunter, damit sie vor dem Rendern ankommt.

Anzeigen oder Iframes, die spät geladen werden, sind ein Problem für Medienseiten und Websites mit eingebettetem Inhalt. Reservieren Sie Platz mit CSS für Mindesthöhe oder Seitenverhältnis auf Anzeigen- und Iframe-Containern, damit sich das Layout nicht ändert, wenn der Inhalt ankommt.

Cookie-Banner, die Inhalte nach unten drängen, sind ein häufiges Problem. Das Banner erscheint oben auf der Seite und verschiebt alles nach unten, wenn es geladen wird. Dann verschiebt es alles wieder nach oben, wenn der Benutzer zustimmt oder ablehnt. Verwenden Sie ein Overlay oder ein Modal mit fester Position, anstatt es in den Dokumentenfluss einzufügen.

Das dynamische Einfügen von Inhalten über JavaScript, das Elemente über sichtbaren Inhalten hinzufügt, führt zu Verschiebungen. Fügen Sie nach Möglichkeit unter dem aktuellen Viewport ein, oder reservieren Sie Platz für das Element, damit kein anderer Inhalt übertragen wird.

Eingebettete Videos und Beiträge in sozialen Netzwerken (YouTube, Twitter, Instagram) werden asynchron ohne reservierten Speicherplatz geladen, was zu Verschiebungen führt, wenn sie ankommen. Richten Sie explizite Container für das Seitenverhältnis der Einbettungen ein, bevor sie geladen werden.

Animationen, die oben, links oder breit verwenden, lösen Layout-Reflows aus, die für CLS angerechnet werden. Verwenden Sie Transformation und Opazität für Animationen. Diese werden auf dem GPU-Compositor ausgeführt, ohne das Layout auszulösen, sodass sie sich nicht auf CLS auswirken.

Interaktion mit Next Paint (INP): häufig auftretende Probleme und Problembehebungen

INP ist das am schwierigsten zu optimierende Core Web Vital. Es ersetzte First Input Delay im März 2024, da INP die Reaktionsfähigkeit für alle Interaktionen erfasst, nicht nur für die erste. INP misst die längste Verzögerung bei typischen Interaktionen (Klicks, Tippen, Tastendruck) und meldet die langsamste Interaktion mit 98. Perzentil.

Langanhaltendes JavaScript beim Klicken ist das häufigste INP-Problem. Event-Handler, die umfangreiche Logik ausführen, blockieren synchron den Haupt-Thread und verhindern so, dass die Seite aktualisiert wird. Die Lösung besteht darin, die Arbeit mit setTimeout oder QueueMicrotask in kleinere Aufgaben aufzuteilen, Web Workers für umfangreiche Berechnungen zu verwenden oder den Algorithmus selbst zu optimieren.

Große Pakete, die bei der ersten Interaktion analysiert und ausgeführt werden, sind in JavaScript-lastigen Frameworks üblich. Dutzende MB JavaScript, das asynchron heruntergeladen wird, wurden möglicherweise zum Zeitpunkt der Benutzerinteraktion noch nicht analysiert. Code-Splitting, dynamische Importe, das Aufschieben unkritischer JS-Dateien und das Entfernen ungenutzter Bibliotheken helfen dabei.

Starke Event-Listener im Dokument (Scrollen, Größenänderung, Eingabe) mit teuren Logikblock-Interaktionen. Drosseln oder entprellen Sie Listener, verschieben Sie die Logik nach requestAnimationFrame und verwenden Sie IntersectionObserver anstelle von Scroll-Listenern, wenn möglich.

Erzwungenes synchrones Layout (auch Layout-Thrashing genannt) tritt auf, wenn JavaScript Layouteigenschaften (offsetWidth, getBoundingClientRect) liest und Stile in derselben Aufgabe schreibt. Der Browser muss das Layout synchron ausführen, um genaue Messungen zu erhalten. Batch-DOM-Lese- und Schreibvorgänge, verwenden Sie nach Möglichkeit ResizeObserver und IntersectionObserver.

Skripte von Drittanbietern, die den Hauptthread blockieren, sind das hartnäckigste INP-Problem. Bei Analysen, Tag-Managern, Chat-Widgets und Kundensupport-Tools wird im Hauptthread viel JavaScript ausgeführt. Die Lösung besteht darin, auf die Zeit nach der ersten Interaktion zu setzen und in modernen Frameworks eine teilweise Hydratation zu verwenden, oder bei Fassadenmustern, bei denen ein leichter Platzhalter angezeigt wird, bis der Benutzer mit dieser speziellen Funktion interagiert.

Große React- oder Vue-Renderings verursachen INP-Probleme, wenn der Komponentenbaum bei einer kleinen Zustandsänderung vollständig neu gerendert wird. Verwenden Sie React.memo, useMemo, useCallback für teure Komponenten; überprüfen Sie den React DevTools Profiler, um unnötige erneute Renderings zu identifizieren.

Lange Aufgaben von Iframes von Drittanbietern (YouTube-Einbettungen, soziale Widgets) führen zu Konflikten im Hauptthread, auch wenn der Nutzer nicht mit ihnen interagiert. Verwende Fassadenmuster: leichte Platzhalter, bis der Nutzer auf Abspielen klickt oder mit dem eingebetteten Objekt interagiert.

So messen Sie Core Web Vitals richtig

Bei der CWV-Messung gibt es zwei verschiedene Typen: Labordaten und Felddaten. Labordaten stammen aus synthetischen Tests unter kontrollierten Bedingungen (Lighthouse, WebPageTest); Felddaten stammen von echten Benutzern (CruX, RUM-Tools). Beides ist wichtig, aber sie beantworten unterschiedliche Fragen.

Felddaten sind das Ranking-Signal. Google verwendet Daten aus dem Chrome User Experience Report (CruX), in denen reale Nutzerdaten von Chrome-Nutzern zusammengefasst werden, die sich für den anonymen Austausch von Leistungsdaten entscheiden. CruX-Daten sind das, was die Search Console meldet, was in PageSpeed Insights als „Felddaten“ angezeigt wird und was die Rankings beeinflusst. CruX wird monatlich aktualisiert und ist nur für Websites mit ausreichendem Chrome-Traffic verfügbar.

Labordaten sind das Debugging-Tool. Lighthouse führt synthetische Tests mit kontrollierter CPU- und Netzwerkdrosselung durch und liefert so reproduzierbare Ergebnisse. Labordaten sind nützlich, um Änderungen vor der Bereitstellung zu testen, alternative Implementierungen zu vergleichen und spezifische Engpässe zu identifizieren. Laborergebnisse wirken sich jedoch nicht direkt auf die Rankings aus. Sie sind ein Indikator dafür, was echte Benutzer erleben.

PageSpeed Insights kombiniert beides: Es zeigt Labordaten (Lighthouse) und Felddaten (CruX) für jede URL. Dies ist der schnellste Weg, um eine einzelne Seite zu bewerten. Verwenden Sie den Core Web Vitals-Bericht der Search Console, in dem URLs nach Mustern gruppiert und Trends im Zeitverlauf angezeigt werden, um den Status der Website zu ermitteln.

Real User Monitoring (RUM) -Tools liefern kontinuierliche Felddaten von Ihren spezifischen Besuchern. Zu den Tools gehören New Relic, Datadog RUM, SpeedCurve und werden über die Web-Vitals JavaScript-Bibliothek selbst gehostet. RUM ist unverzichtbar für Websites, auf denen CruX-Daten spärlich sind (geringer Chrome-Traffic) oder auf denen Sie CWV nach Benutzersegmenten, Regionen oder Geräten verfolgen müssen.

Mit der Web-Vitals JavaScript-Bibliothek können Sie Felddaten an Ihre eigenen Analysen senden (normalerweise GA4). Auf diese Weise erhalten Sie CWV-Daten für echte Benutzer für jede Seite Ihrer Website, segmentiert nach Ihren Wünschen. Das Setup besteht aus einem kleinen JS-Snippet plus GA4-Konfiguration. Der Gesamtaufwand beträgt für eine typische Site 2 bis 4 Stunden.

Bei der CWV-Messung gibt es zwei verschiedene Typen: Labordaten und Felddaten. Labordaten stammen aus synthetischen Tests unter kontrollierten Bedingungen (Lighthouse, WebPageTest); Felddaten stammen von echten Benutzern (CruX, RUM-Tools). Beides ist wichtig, aber sie beantworten unterschiedliche Fragen.

Felddaten sind das Ranking-Signal. Google verwendet Daten aus dem Chrome User Experience Report (CruX), in denen reale Nutzerdaten von Chrome-Nutzern zusammengefasst werden, die sich für den anonymen Austausch von Leistungsdaten entscheiden. CruX-Daten sind das, was die Search Console meldet, was in PageSpeed Insights als „Felddaten“ angezeigt wird und was die Rankings beeinflusst. CruX wird monatlich aktualisiert und ist nur für Websites mit ausreichendem Chrome-Traffic verfügbar.

Labordaten sind das Debugging-Tool. Lighthouse führt synthetische Tests mit kontrollierter CPU- und Netzwerkdrosselung durch und liefert so reproduzierbare Ergebnisse. Labordaten sind nützlich, um Änderungen vor der Bereitstellung zu testen, alternative Implementierungen zu vergleichen und spezifische Engpässe zu identifizieren. Laborergebnisse wirken sich jedoch nicht direkt auf die Rankings aus. Sie sind ein Indikator dafür, was echte Benutzer erleben.

PageSpeed Insights kombiniert beides: Es zeigt Labordaten (Lighthouse) und Felddaten (CruX) für jede URL. Dies ist der schnellste Weg, um eine einzelne Seite zu bewerten. Verwenden Sie den Core Web Vitals-Bericht der Search Console, in dem URLs nach Mustern gruppiert und Trends im Zeitverlauf angezeigt werden, um den Status der Website zu ermitteln.

Real User Monitoring (RUM) -Tools liefern kontinuierliche Felddaten von Ihren spezifischen Besuchern. Zu den Tools gehören New Relic, Datadog RUM, SpeedCurve und werden über die Web-Vitals JavaScript-Bibliothek selbst gehostet. RUM ist unverzichtbar für Websites, auf denen CruX-Daten spärlich sind (geringer Chrome-Traffic) oder auf denen Sie CWV nach Benutzersegmenten, Regionen oder Geräten verfolgen müssen.

Mit der Web-Vitals JavaScript-Bibliothek können Sie Felddaten an Ihre eigenen Analysen senden (normalerweise GA4). Auf diese Weise erhalten Sie CWV-Daten für echte Benutzer für jede Seite Ihrer Website, segmentiert nach Ihren Wünschen. Das Setup besteht aus einem kleinen JS-Snippet plus GA4-Konfiguration. Der Gesamtaufwand beträgt für eine typische Site 2 bis 4 Stunden.

Plattformspezifische CWV-Muster

Verschiedene Plattformen haben unterschiedliche CWV-Standardeinstellungen und unterschiedliche häufige Engpässe. Die Kenntnis der Muster spart Zeit bei Audits.

Webflow ist sofort einsatzbereit (Lighthouse 85 bis 95 auf Mobilgeräten, 85 bis 95 Prozent CWV-Erfolgsquote). Die häufigsten Engpässe sind benutzerdefinierte Code-Einbettungen (Skripte von Drittanbietern, die über eingebettete Elemente eingefügt werden), große Hero-Videos und Widgets von Drittanbietern (Chat, Kalender, soziale Netzwerke). Zu den Problembehebungen gehören die Überprüfung der Codeeinbettungen, die Optimierung der Videobereitstellung und das verzögerte Laden von Widgets, die sich im unteren Bereich befinden.

WordPress mit einem benutzerdefinierten Theme und minimalen Plugins funktioniert gut (Lighthouse 80 bis 92, 60 bis 80 Prozent CWV-Erfolgsrate). Die häufigsten Engpässe sind der Plugin-Overhead (jedes aktive Plugin fügt JS und CSS hinzu), Theme-Bloat (Page Builder sind besonders schlecht) und nicht optimierte Bilder. Bei den Korrekturen handelt es sich um minimale Plugin-Sets, ein benutzerdefiniertes Theme, ein Image-Plugin, Caching und CDN.

WordPress mit Page Buildern (Elementor, Divi, Beaver Builder) schneidet in der Regel schlecht ab (Lighthouse 40 bis 70, 15 bis 35 Prozent CWV-Erfolgsquote). Seitenersteller generieren umfangreiches DOM, renderblockierendes CSS und übermäßiges JavaScript. Die Lösung besteht in der Regel in der Migration zu einem blockbasierten oder benutzerdefinierten Theme. Aggressives Caching hilft, löst das Problem aber nicht vollständig.

Shopify schneidet mäßig ab (Lighthouse 50 bis 80, 40 bis 65 Prozent CWV-Erfolgsquote). Die häufigsten Engpässe sind der Code der Theme-App, Apps von Drittanbietern (jede App fügt Skripte ein) und der Einkaufswagen- und Checkout-Overhead. Zu den Korrekturen gehören App-Audits, verzögertes Laden unkritischer Abschnitte und die Auswahl leistungsorientierter Themen (Dawn, Spotlight, Studio).

Websites mit Next.js (modernes React mit Serverkomponenten) schneiden sehr gut ab (Lighthouse 85 bis 98, 80 bis 95 Prozent CWV-Erfolgsrate). Die häufigsten Engpässe sind die clientseitige Flüssigkeitszufuhr (große Komponentenbäume), große JS-Pakete und Skripte von Drittanbietern. Bei den Problembehebungen werden Serverkomponenten für nicht interaktive Inhalte verwendet, die Bildoptimierung über next/image und die Bündelanalyse durchgeführt.

Statische Seitengeneratoren (Astro, Hugo, Eleventy) schneiden normalerweise am besten ab (Lighthouse 95 bis 100, 90 bis 99 Prozent CWV-Erfolgsquote). Die Ausgabe besteht im Wesentlichen aus HTML und CSS mit minimalem JavaScript-Anteil, sodass CWV-Fehler selten sind und in der Regel durch Skripte von Drittanbietern verursacht werden. Der Fix schränkt die Skripte von Drittanbietern ein. Die SSG kümmert sich um alles andere.

Handy gegen Desktop: Wo der wahre Kampf stattfindet

Google verwendet seit 2023 standardmäßig die Mobile-First-Indexierung. Das bedeutet, dass Google in erster Linie mobile Crawl-Daten für die Indexierung und das Ranking verwendet, selbst für Websites mit hauptsächlich Desktop-Besuchern. Die CWV-Ergebnisse für Mobilgeräte wirken sich auf das Ranking aus.

Der weltweite Anteil des Mobilfunkverkehrs liegt 2026 bei 55 bis 65 Prozent. Selbst B2B-Websites mit Desktop-lastigen Käuferreisen verzeichnen in der Regel 30 bis 45 Prozent des mobilen Traffics für Top-of-Tunnel-Inhalte (Blogbeiträge, Marketingseiten). Bei Websites, die auf dem Desktop gut, auf Mobilgeräten jedoch schlecht abschneiden, wirkt sich diese Asymmetrie direkt auf den organischen Traffic über Mobilgeräte aus.

Desktop-CWV ist in der Regel einfacher als Mobilgeräte, da der Desktop über schnellere Verbindungen (Kabel, Glasfaser mit niedriger Latenz), größere Bildschirme (weniger wahrscheinlich ist ein responsiver Bildaustausch erforderlich) und schnellere CPUs verfügt. Die meisten Websites, die mobile CWV weitergeben, bestehen auch Desktop-CWV; das Gegenteil ist selten der Fall.

Die mobile Realität ist hart. Bei mobilen Tests in der Praxis sollte von 4G-Verbindungen (10 bis 20 Mbit/s mit einer Latenz von 100 bis 300 ms) und Geräten der mittleren Preisklasse (ähnlich einem 3 Jahre alten Android) ausgegangen werden, nicht von Flaggschiff-Telefonen mit 5G. Labortests wie Lighthouse simulieren dies in der mobilen Voreinstellung. Vergewissern Sie sich, dass Ihre Tests die mobile Voreinstellung und nicht die Desktop-Version verwenden.

Der größte mobile Engpass ist JavaScript. Mobile CPUs analysieren und führen JavaScript 4- bis 6-mal langsamer aus als Desktop-CPUs. Eine Website mit 2 MB JavaScript, die auf dem Desktop einwandfrei läuft, kann auf Mobilgeräten unbrauchbar sein. Die Verwaltung des JavaScript-Budgets ist die leistungsstärkste mobile CWV-Arbeit.

Netzwerk und CPU bilden eine Verbindung. Die Kombination aus langsamerem Netzwerk und langsamerer CPU auf Mobilgeräten bedeutet, dass die Leistungsbudgets viel knapper sein müssen als bei Desktop-PCs. Eine 1,5-MB-Seite, die auf einem Desktop in 1,5 Sekunden geladen wird, kann auf Mobilgeräten 5 bis 7 Sekunden dauern.

Testen Sie auf echten Geräten, nicht nur auf Emulatoren. Die mobile Emulation von Chrome DevTools ist für das Layout nützlich, aber Tests auf realen Geräten zeigen die tatsächliche Leistung. Verwenden Sie BrowserStack, echte Telefone oder Chrome-Remote-Debugging, um die Genauigkeit zu gewährleisten.

Roadmap für die CWV-Umsetzung: von der Prüfung bis zur laufenden Überwachung

Ein ordnungsgemäßes CWV-Engagement umfasst vier Phasen: Basisplanung, Priorisierung, Problembehebungen und Überwachung. Der Versuch, Phasen zu überspringen oder stapelweise durchzuführen, führt zu vergeblicher Arbeit.

Baseline: Erfassen Sie den aktuellen Status. Rufe CruX-Daten für die 20 besten Seiten nach Traffic ab. Führen Sie Lighthouse-Audits für Mobilgeräte durch und dokumentieren Sie Ergebnisse. Erfassen Sie TTFB, LCP, CLS, INP pro Vorlagentyp (Homepage, Produktseite, Blogbeitrag usw.). Die Ausgangsbasis ist die Grundlage, mit der Sie die Verbesserungen später vergleichen. Sie muss also spezifisch sein und gespeichert werden.

Priorisierung: Nicht alle Seiten sind gleich. Sortiert Seiten nach Besucherzahlen und CWV-Ausfall. Die wirkungsvollsten Korrekturen sind Seiten mit hohem Traffic und schlechtem CWV. Vorlagen, die viele Seiten betreffen (z. B. eine Produktdetailvorlage, die 5.000 Produktseiten betrifft), erhalten eine höhere Priorität als einzelne Seiten.

Korrekturen: Adressieren Sie LCP zuerst, da es die größte Auswirkung auf die Benutzer hat und am sichtbarsten ist. Dann CLS, wo es oft schnelle Gewinne gibt. Dann INP, was normalerweise aufwändigere Codeänderungen erfordert. Vermeiden Sie den Versuch, alles auf einmal zu korrigieren. Mit sequentiellen Korrekturen können Sie die Auswirkungen jeder Änderung messen.

Überwachung: Richten Sie nach Korrekturen die Überwachung für reale Benutzer ein. Die Web-Vitals-JavaScript-Bibliothek plus GA4 dauert 2 bis 4 Stunden und liefert kontinuierliche CWV-Daten. Stellen Sie Warnungen für Regressionen ein. Planen Sie monatliche Stichprobenkontrollen und vierteljährliche vollständige Wiederholungsprüfungen ein, da CWV im Laufe der Zeit immer schlechter wird, wenn neuer Code und Inhalt eintreffen.

Dokumentstandards: Definieren Sie ein internes CWV-Budget für jede Seitenvorlage (z. B. LCP unter 2,5 Sekunden auf Mid-Tier-Mobilgeräten). Verwenden Sie das Budget als Deploy-Blocker für Änderungen, die gegen das Budget verstoßen. Ohne diese Disziplin gehen Gewinne, die in einem Quartal erzielt wurden, im nächsten verloren, da neue Funktionen ohne Leistungsbeurteilung veröffentlicht werden.

UnfoldMart Core Web Vitals Servicestufen

UnfoldMart bietet CWV-Optimierung als eigenständigen Service oder als Teil umfassenderer SEO-Dienste an. Die Preise variieren je nach Komplexität der Website, Seitenanzahl und Implementierungsgrad.

Das CWV-Audit (einmalig) kostet 1.500 bis 4.500 USD. Umfang: einzelne Domain, Top 10 bis 20 Seiten. Ergebnisse: vollständiges CWV-Audit (LCP, CLS, INP, TTFB), Liste mit priorisierten Problemlösungen, Implementierungs-Roadmap, CruX-Baseline vor und nach dem Ablauf. Ideal für Marken, die ein internes Team oder einen anderen Implementierungspartner haben und eine Prüfung und Priorisierung durch Experten benötigen.

Das CWV-Audit und die Implementierung kosten 4.500 bis 18.000 USD. Umfang: einzelne Domain, Top 30 bis 50 Seiten. Leistungsumfang: Ergebnisse auf Auditebene sowie Implementierung von Prioritätskorrekturen, fortlaufende Einrichtung der CWV-Überwachung, 90 Tage Nachverfolgung nach der Implementierung. Ideal für Marken, die sowohl Diagnose als auch Ausführung von demselben Partner wünschen.

Multidomain- oder E-Commerce-Engagements kosten 7.500 bis 35.000 USD. Umfang: mehr als 2 Domains oder E-Commerce-Website mit mehr als 100 Seiten. Lieferumfang: CWV-Audit mit mehreren Domains, E-Commerce-spezifische Optimierungen (Warenkorb, Checkout, Produktseiten), CDN-Konfiguration, Bildoptimierungspipeline. Ideal für Marken, die auf mehreren Websites oder transaktionalen Websites tätig sind, bei denen die Konversionsrate erheblich ist.

CWV als Teil des vollständigen SEO-Trainers ist in Retainern ab 5.000 USD pro Monat enthalten. Erstaudit plus monatliches CWV-Monitoring und vierteljährliches erneutes Audit im Rahmen eines umfassenderen SEO-Programms. Keine separate Gebühr. Ideal für Marken, die CWV als Bestandteil eines strategischen SEO-Programms und nicht als eigenständiges Projekt verwenden möchten.

Rote Fahnen in jedem CWV-Anbietervorschlag

CWV ist ein relativ technischer Bereich, was bedeutet, dass die Anbieter von hochkompetent bis hin zu regelrecht irreführend sind. Wenn Sie vor der Bewertung von Vorschlägen die Warnsignale kennen, sparen Sie Zeit und Geld.

Achten Sie auf Anbieter, die bestimmte Lighthouse-Ergebnisse versprechen (kein Anbieter kann Ergebnisse garantieren; die Bedingungen variieren), behaupten, CWV-Optimierung mit einem Klick oder „automatisch“ durchzuführen (echte CWV-Arbeit ist eine Analyse pro Seite, kein Plugin), sich nur auf Labordaten konzentrieren, ohne Felddaten und CruX zu berücksichtigen, INP vollständig ignorieren (nur LCP und CLS erwähnen), allgemeine Empfehlungen ohne standortspezifische Analyse geben, wiederkehrende „monatliche CWV-Wartung“ ohne festgelegte Arbeit berechnen, Ich empfehle, alle Skripte von Drittanbietern im großen Stil zu entfernen, und verspreche, dass CWV allein die Rankings korrigiert, ohne Vorher und Nachher Messplan und weigern Sie sich, frühere Fallstudien mit CruX Vorher-Nachher-Daten zu teilen.

Vertrauenswürdige Anbieter betrachten CWV als ein strukturiertes Projekt: Bewertung des Ausgangswerts, priorisierte Problembehebungsliste mit Begründung, Implementierung und Nachverfolgung nach der Implementierung anhand der Ausgangssituation. Die Arbeit ist real, aber begrenzt. Anbieter, die versuchen, es größer klingen zu lassen, als es ist, verkaufen in der Regel zu viel, und Anbieter, die versuchen, es einfacher klingen zu lassen, als es ist, verkaufen normalerweise ein Plugin.

Bereit, Core Web Vitals zu reparieren?

Core Web Vitals sind die notwendige Infrastruktur für jede Website, die 2026 wettbewerbsfähig sein und echte Nutzer effektiv konvertieren möchte. Die Arbeit ist gut verstanden, die Metriken sind klar und die Auswirkungen verstärken sich auf Rankings, Konversionsrate und Sichtbarkeit der KI-Engine.

UnfoldMart prüft und repariert CWV als eigenständigen Dienst oder als Teil umfassenderer SEO- und technischer Dienste. Wenn Ihre Website auf kritischen Seiten nicht erfolgreich ist, ist der nächste Schritt ein 30-minütiges Strategiegespräch, in dem wir Ihren aktuellen Status überprüfen, die wichtigsten Problemlösungen identifizieren, den Umfang der Implementierungsarbeiten festlegen und den daraus resultierenden Überwachungsrhythmus skizzieren.

‍Einen Strategieanruf buchen