Core Web Vitals optimieren: der Praxis-Guide 2026

14.09.2026 Christopher Schütz SEO 10 Min Lesezeit
Core Web Vitals optimieren: der Praxis-Guide 2026

Core Web Vitals sind kein neues Thema mehr, trotzdem tun sich die meisten Websites 2026 immer noch schwer damit. Das liegt selten an fehlendem Wissen, sondern an der Praxis: Ein Webshop wird um zehn neue Apps erweitert, ein Blog bekommt ein Werbenetzwerk, ein WordPress-Theme sammelt über Jahre Plugins an, und irgendwann rutscht die Ladezeit von grün auf gelb oder rot. Wir sehen das bei fast jedem Website-Audit, das wir für Kunden durchführen. In diesem Guide zeigen wir, welche drei Werte wirklich zählen, wo die typischen Bremsen liegen und mit welchen Schritten man sie in überschaubarer Zeit wieder in den grünen Bereich bringt.

Was Core Web Vitals eigentlich messen

Google fasst unter Core Web Vitals drei Metriken zusammen, die beschreiben, wie eine reale Nutzerin oder ein realer Nutzer eine Seite erlebt: wie schnell der sichtbare Hauptinhalt lädt, wie flüssig sich die Seite bei Klicks und Eingaben anfühlt und wie stabil das Layout bleibt, während die Seite aufbaut. Das sind keine Labor-Werte aus einem Testtool, sondern echte Felddaten, die Google über den Chrome-Browser bei Millionen Nutzern sammelt und im Chrome User Experience Report (CrUX) bündelt.

  • LCP (Largest Contentful Paint): Zeit bis zum Rendern des größten sichtbaren Elements im Viewport, meist ein Hero-Bild, eine Überschrift oder ein Produktfoto.
  • INP (Interaction to Next Paint): Zeit zwischen einer Nutzerinteraktion, etwa einem Klick oder Tap, und dem Moment, in dem der Browser sichtbar reagiert. INP hat FID (First Input Delay) im März 2024 als offizielle Metrik abgelöst und misst nicht nur die erste, sondern alle Interaktionen einer Session.
  • CLS (Cumulative Layout Shift): Summe aller unerwarteten Layoutverschiebungen während des Seitenaufbaus, zum Beispiel wenn ein Bild ohne feste Größe nachlädt und der Text darunter nach unten springt.

Wichtig für die Einordnung: Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil aller Sitzungen der letzten 28 Tage, getrennt nach Mobil und Desktop. Das bedeutet, drei von vier Besuchern müssen die Seite im grünen Bereich erleben, damit die Metrik insgesamt als "gut" gilt. Einzelne schnelle Testläufe in PageSpeed Insights sagen deshalb wenig darüber aus, wie es der Mehrheit der echten Besucher tatsächlich ergeht.

Warum sich der Aufwand 2026 lohnt

Core Web Vitals sind ein Rankingfaktor unter vielen, aber ihre Wirkung reicht weiter als reines SEO. Eine Seite, die schnell lädt und sich sofort bedienen lässt, senkt die Absprungrate, erhöht die Verweildauer und verbessert die Conversion, besonders im Onlinehandel, wo jede Sekunde Ladezeit bares Geld kostet. Gerade bei einem Online-Shop mit vielen Produktbildern, Filtern und Drittanbieter-Skripten für Tracking, Chat und Zahlungsanbieter summieren sich kleine Verzögerungen schnell zu einem spürbaren Problem. Hinzu kommt: Seit generative KI-Suchergebnisse und AI Overviews immer mehr Klicks vorwegnehmen, zählt jeder organische Besuch doppelt, und eine technisch saubere, schnelle Seite ist die Grundvoraussetzung dafür, dass Inhalte überhaupt zuverlässig gecrawlt und indexiert werden.

LCP in der Praxis verbessern

Der LCP-Wert hängt fast immer an einer von vier Ursachen: langsame Serverantwort, verzögertes Laden von Bildern oder Schriften, blockierendes CSS oder JavaScript, oder ein zu großes, unoptimiertes Hauptbild. In der Praxis reicht es fast nie, nur eine Stellschraube zu drehen.

  • Server Response Time senken: Ein Time to First Byte über 600 Millisekunden verschiebt automatisch alles Nachfolgende. Caching auf Server-Ebene, ein CDN für statische Assets und ein vernünftig dimensioniertes Hosting sind hier die Basis, bevor man überhaupt an Frontend-Feinarbeit denkt.
  • Hero-Bild priorisieren: Das größte sichtbare Element sollte mit fetchpriority="high" ausgezeichnet und nicht per loading="lazy" verzögert werden, denn Lazy Loading auf genau diesem Element verlangsamt den LCP künstlich.
  • Moderne Bildformate: WebP oder AVIF statt JPEG und PNG, dazu srcset für responsive Größen, damit ein Smartphone kein Desktop-Bild in voller Auflösung herunterladen muss.
  • Render-blockierende Ressourcen entschärfen: Kritisches CSS inline einbetten, den Rest asynchron nachladen, und Skripte, die für den ersten Bildaufbau nicht nötig sind, mit defer versehen.
  • Schriftarten sauber laden: font-display: swap setzen und die wichtigsten Web Font-Dateien per preload vorziehen, damit Text nicht unsichtbar bleibt, bis die Schrift geladen ist.

Zielwert: unter 2,5 Sekunden gilt als gut, zwischen 2,5 und 4 Sekunden als verbesserungswürdig, alles darüber als schlecht. Bei Bildlastigen Seiten wie Möbelshops, Fotografen-Portfolios oder Immobilienseiten ist dieser Wert erfahrungsgemäß der größte Hebel.

INP verstehen und optimieren

INP ist die anspruchsvollste der drei Metriken, weil sie nicht nur einen Ladevorgang, sondern die Reaktionsfähigkeit während der gesamten Sitzung misst. Ein Klick auf ein Dropdown-Menü, ein Filter im Shop, ein Akkordeon in den FAQ: Jede dieser Interaktionen zählt, und der schlechteste gemessene Wert dominiert oft das Gesamtbild. Die Hauptursache ist fast immer der Main Thread des Browsers, der durch zu viel oder zu lange laufendes JavaScript blockiert wird.

  • Lange Tasks aufbrechen: JavaScript-Aufgaben über 50 Millisekunden sollten in kleinere Häppchen zerlegt werden, damit der Browser zwischendurch auf Eingaben reagieren kann, statt eine Aufgabe am Stück durchzurechnen.
  • Drittanbieter-Skripte prüfen: Tag-Manager, Chat-Widgets, A/B-Testing-Tools und Werbenetzwerke sind die häufigsten INP-Killer, weil sie oft synchron laden und eigene Event-Listener registrieren. Ein regelmäßiger Check, welche Skripte wirklich gebraucht werden, spart hier oft mehr als jede Code-Optimierung.
  • Event-Handler entlasten: Aufwendige DOM-Manipulationen bei Klick-Events verzögern, per requestIdleCallback oder Web Worker auslagern, statt sie direkt im Klick-Handler abzuarbeiten.
  • Hydration bei Frameworks im Blick behalten: Bei React-, Vue- oder Next.js-Anwendungen ist die Hydration-Phase ein klassischer INP-Bremser, weil die Seite optisch fertig aussieht, aber noch nicht interaktiv ist. Partial oder progressive Hydration reduziert dieses Zeitfenster spürbar.

Zielwert: unter 200 Millisekunden ist gut, bis 500 Millisekunden noch akzeptabel, darüber wird es für Nutzer spürbar träge. Gerade auf älteren Android-Smartphones mit schwächerer CPU macht sich ein hoher INP-Wert deutlich stärker bemerkbar als auf einem aktuellen iPhone, weshalb reale Felddaten so wichtig sind.

CLS: Layoutsprünge vermeiden

Cumulative Layout Shift ist oft der am einfachsten zu behebende Wert, wird aber trotzdem regelmäßig übersehen. Die Ursachen sind meist banal: Bilder oder Videos ohne definierte Breite und Höhe, Werbebanner, die nachträglich Platz beanspruchen, dynamisch nachgeladene Inhalte über der Falz, oder Web Fonts, die beim Laden eine andere Zeilenbreite erzeugen als die Fallback-Schrift.

  • Größenangaben setzen: Für jedes Bild und Video die Attribute width und height im HTML angeben, damit der Browser vor dem Laden bereits den benötigten Platz reserviert.
  • Platzhalter für Anzeigen und Embeds: Werbeflächen, Social-Media-Einbettungen oder Cookie-Banner mit fester Mindesthöhe reservieren, statt sie erst nach dem Laden ihren Platz beanspruchen zu lassen.
  • Neue Inhalte unterhalb einfügen: Wenn per JavaScript Inhalte nachträglich eingefügt werden müssen, sollten sie nach Möglichkeit unterhalb des sichtbaren Bereichs erscheinen und nicht bestehende Elemente verschieben.
  • Font-Metriken angleichen: Mit size-adjust und passenden Fallback-Schriften lässt sich der Sprung beim Wechsel von System- auf Webfont fast vollständig eliminieren.

Zielwert: unter 0,1 ist gut, bis 0,25 verbesserungswürdig, darüber schlecht. Anders als bei LCP und INP kostet die Behebung hier meist wenig Entwicklungszeit und bringt trotzdem sofort spürbare Verbesserungen im Nutzererlebnis.

Zielwerte auf einen Blick

MetrikGutVerbesserungswürdigSchlecht
LCPbis 2,5 s2,5 bis 4,0 süber 4,0 s
INPbis 200 ms200 bis 500 msüber 500 ms
CLSbis 0,10,1 bis 0,25über 0,25

Besonderheiten bei Shopify und anderen Shopsystemen

Bei Shopify-Shops kommen zu den allgemeinen Ursachen noch ein paar plattformspezifische Fallen hinzu. Zu viele installierte Apps sind der klassische Übeltäter: Jede App hängt eigenes JavaScript ein, oft unabhängig davon, ob sie auf der aktuellen Seite überhaupt gebraucht wird. Ein regelmäßiger App-Audit, bei dem ungenutzte oder redundante Apps deinstalliert werden, bringt in der Praxis oft mehr als jede Theme-Optimierung. Auch das Theme selbst spielt eine große Rolle: Schwergewichtige Themes mit vielen eingebauten Funktionen für Slider, Countdown-Timer oder Produktbadges laden häufig Skripte auf allen Seiten, statt sie nur dort einzubinden, wo sie tatsächlich verwendet werden. Bei Shopify Plus lässt sich zusätzlich über Checkout Extensibility und Script-Optimierung im Checkout selbst noch einmal nachjustieren, was bei klassischen Shopify-Plänen nicht möglich ist. Wer einen neuen Shop plant, sollte Performance von Anfang an mitdenken statt sie nachträglich zu reparieren, ein Grundthema, das wir bei jedem Online-Shop-Projekt von der ersten Konzeptphase an mitplanen.

Die richtigen Messwerkzeuge nutzen

Für eine belastbare Analyse braucht es mehr als einen einzelnen Test. Die Google Search Console zeigt unter "Wichtige Web-Vitals" die tatsächlichen Feld-Daten aus dem CrUX-Report, aufgeschlüsselt nach URL-Gruppen, und ist damit die wichtigste Quelle für echte Nutzererfahrung über Zeit. PageSpeed Insights kombiniert Feld- und Labordaten in einem Bericht und liefert zusätzlich konkrete Handlungsempfehlungen mit geschätztem Einsparpotenzial. Chrome DevTools mit dem Performance-Panel und dem Lighthouse-Tab eignen sich für die Tiefenanalyse einzelner Ladevorgänge, etwa um herauszufinden, welches konkrete Skript einen langen Task verursacht. Für laufendes Monitoring lohnt sich ein Real User Monitoring (RUM), das Core Web Vitals kontinuierlich aus echten Besuchersitzungen erfasst, statt nur stichprobenartig zu testen. Wichtig dabei: Labordaten aus Lighthouse und Felddaten aus der Search Console können deutlich auseinanderliegen, weil Lighthouse unter idealisierten Bedingungen misst, während Felddaten die reale Gerätevielfalt und Netzqualität der Besucher abbilden. Bei widersprüchlichen Werten zählt für das Ranking ausschließlich das Feld.

Typische Fehler aus der Praxis

In den Audits, die wir regelmäßig durchführen, tauchen immer wieder dieselben Muster auf. Erstens: Optimierung nur auf Desktop getestet, während der Großteil des Traffics mobil kommt und dort ganz andere Werte liefert. Zweitens: Ein einziger PageSpeed-Test wird als Erfolg gefeiert, ohne die 28-Tage-Felddaten der Search Console abzuwarten, die oft ein deutlich ehrlicheres Bild zeigen. Drittens: Bilder werden komprimiert, aber die eigentliche Bremse liegt im Drittanbieter-JavaScript von Tracking-Tools, das dabei komplett übersehen wird. Viertens: Nach einem Relaunch wird die Core-Web-Vitals-Kontrolle einmalig gemacht und dann monatelang nicht wiederholt, obwohl jede neue App, jedes neue Plugin und jeder neue Tracking-Pixel die Werte wieder verschlechtern kann. Fünftens: Man optimiert einzelne Unterseiten manuell, obwohl das zugrunde liegende Template oder Theme das eigentliche Problem ist und die Korrektur an einer Stelle für alle betroffenen Seiten gleichzeitig wirken würde. Wer diese Punkte im Hinterkopf behält, spart sich einen guten Teil der Nacharbeit, die sonst nach ein paar Monaten wieder ansteht.

Ein realistischer Ablauf für die Umsetzung

Bewährt hat sich ein dreistufiges Vorgehen: Zuerst eine Bestandsaufnahme über Search Console und PageSpeed Insights, um zu sehen, welche der drei Metriken auf welchen Seitentypen am schlechtesten abschneidet. Danach die Priorisierung nach Traffic-Anteil, denn es lohnt sich immer zuerst, die Seitenvorlagen mit den meisten Besuchern zu optimieren, etwa Kategorieseiten im Shop oder die Startseite, statt einzelne wenig besuchte Unterseiten. Zuletzt die technische Umsetzung in kleinen, messbaren Schritten, bei der nach jeder Änderung erneut gemessen wird, ob sich der jeweilige Wert tatsächlich verbessert hat. Diese Vorgehensweise verhindert, dass Wochen in Optimierungen investiert werden, die am Ende kaum Wirkung zeigen, weil sie nicht dort ansetzen, wo der eigentliche Engpass liegt. Bei größeren technischen Eingriffen, etwa dem Wechsel des Theme-Frameworks oder einer grundlegenden Überarbeitung der Ladereihenfolge, empfiehlt sich eine enge Abstimmung mit einer erfahrenen SEO-Agentur, damit technische Maßnahmen und inhaltliche Optimierung Hand in Hand gehen statt sich gegenseitig auszubremsen.

Häufige Fragen

Wie lange dauert es, bis sich verbesserte Core Web Vitals im Ranking zeigen?
Google aktualisiert die Feld-Daten auf Basis der letzten 28 Tage, ein spürbarer Effekt auf das Ranking zeigt sich deshalb frühestens nach vier bis sechs Wochen. Kurzfristig verbessert sich meist zuerst die Nutzererfahrung, das Ranking zieht danach nach.

Reicht ein guter PageSpeed-Insights-Score von 90 Punkten aus?
Nicht unbedingt, denn der Score ist ein Laborwert unter Idealbedingungen. Entscheidend für Google sind die echten Feld-Daten aus der Search Console, die je nach Gerätevielfalt und Netzqualität der Besucher deutlich schlechter ausfallen können als der Testwert.

Welche der drei Metriken hat den größten Einfluss auf das Ranking?
Google gewichtet alle drei Metriken als Teil eines gemeinsamen Signals, keine davon zählt isoliert stärker. In der Praxis lohnt sich meist zuerst der Blick auf die Metrik mit dem schlechtesten Wert, weil dort der größte Sprung erzielbar ist.

Wie oft sollte man die Core Web Vitals kontrollieren?
Ein monatlicher Check über die Search Console reicht für die meisten Websites aus, bei aktiven E-Commerce-Shops mit häufigen App- und Theme-Änderungen empfiehlt sich eine engmaschigere Kontrolle alle zwei Wochen.

Kann ein CDN allein die Core Web Vitals retten?
Ein CDN verbessert vor allem die Serverantwortzeit und damit indirekt den LCP, löst aber keine Probleme bei INP durch schwerfälliges JavaScript oder bei CLS durch fehlende Bildgrößen. Es ist ein wichtiger Baustein, aber kein Ersatz für die restliche Optimierung.

Wirken sich schlechte Core Web Vitals auch auf Google Ads aus?
Indirekt ja, denn eine langsame Landingpage erhöht die Absprungrate und senkt damit die Conversion-Rate der Kampagne, was wiederum den Qualitätsfaktor und somit die Klickkosten negativ beeinflussen kann.

Lohnt sich eine Optimierung für kleine, lokale Websites überhaupt?
Ja, denn gerade bei lokalen Suchanfragen von unterwegs mit schwächerem Mobilfunknetz macht sich eine langsame Seite besonders negativ bemerkbar, und Core Web Vitals sind unabhängig von der Seitengröße Teil des Rankings.

Haben Sie Fragen zu diesem Thema?

Wir beraten Sie gerne persönlich und unverbindlich

Kontakt aufnehmen Weitere Artikel lesen