CORE WEB VITALS IM JAHR 2026

Bei der Leistungsoptimierung im Jahr 2026 lassen sich zwei Ansätze unterscheiden. Der reaktive Ansatz optimiert einzelne Seiten erst dann, wenn sie einen Schwellenwert unterschreiten. Der strukturelle Ansatz integriert die Leistungsoptimierung bereits in die Wahl des Frameworks, des Designsystems, der Bereitstellungs-Pipeline und der Inhaltsgestaltung, sodass die Leistung das natürliche Ergebnis der Arbeit ist und nicht erst im Nachhinein optimiert werden muss. Jede Website, die ich kenne und die langfristig erfolgreich ist, verfolgt den strukturellen Ansatz.

Dieser Leitfaden bietet einen Überblick über die Struktur. Konkrete Zahlen von Websites, die ich bereits veröffentlicht habe, die Prüfungen, die ich tatsächlich durchführe, die kostspieligsten Fehler, die ich gemacht habe, und die Teile der gängigen Ratschläge, die sich in der Praxis als falsch herausgestellt haben. Felddaten von CrUX sind immer aussagekräftiger als Labordaten von PageSpeed Insights, daher stammen die meisten der folgenden Zahlen von echten Nutzern im 75. Perzentil.

LCP (Largest Contentful Paint)

Die Zeit bis zum Rendern des größten Elements oberhalb der Falz. Ziel: unter 2,5 Sekunden am 75. Perzentil. Der am häufigsten genannte Core Web Vital-Wert, der oft am einfachsten zu beheben ist, sobald man das LCP-Element korrekt identifiziert hat. Bei den meisten Websites handelt es sich bei dem LCP-Element um ein Bild oder einen Hero-Textblock; die Lösung besteht fast immer darin, das Bild vorab zu laden, es richtig zu skalieren und sicherzustellen, dass kein JavaScript das Rendern blockiert.

CLS (Cumulative Layout Shift)

Wie stark sich der Seiteninhalt beim Laden unerwartet verschiebt. Zielwert: unter 0,1. Diese Metrik wird am häufigsten durch verzögert geladene Bilder ohne explizite Breite und Höhe, durch nach dem ersten Rendern eingefügte Anzeigen oder durch Webfonts, deren Metriken sich von denen des Fallbacks unterscheiden, beeinträchtigt. In den meisten Fällen lässt sich dies beheben, indem man bei jedem visuellen Element oberhalb der Falz konsequent explizite Abmessungen angibt.

INP (Interaction to Next Paint)

Die längste Interaktionszeit, die während der Lebensdauer der Seite aufgetreten ist. Ziel: unter 200 ms. Hat im März 2024 den FID abgelöst. Die CWV-Metrik, die sich am schwersten manipulieren lässt, da sie echte Reibungspunkte der Nutzer mit JavaScript bei lang andauernden Aufgaben aufdeckt. Websites mit umfangreichem Client-JavaScript haben hier fast immer Schwierigkeiten. Die Lösung besteht darin, weniger JavaScript zu übertragen, lange Aufgaben in kleinere Abschnitte aufzuteilen und für nicht dringende Aufgaben `requestIdleCallback` zu verwenden.

TTFB (Zeit bis zum ersten Byte)

Server-Antwortzeit, bevor das Rendern beginnen kann. Ziel: unter 600 ms. Offiziell kein „Core Web Vital“, aber dieser Wert begrenzt alle anderen Metriken. Statisch gerenderte Websites auf einem CDN erreichen in der Regel 50 bis 150 ms. WordPress auf Shared Hosting erreicht bei kaltem Cache 800 ms bis 2,5 s. Die Wahl des Hostings ist der wichtigste Einflussfaktor für die TTFB.

Das Wichtigste auf einen Blick: Betrachten Sie „die vier Kennzahlen, die tatsächlich für das Ranking zählen“ in erster Linie als operative Entscheidung. Die Tools funktionieren nur, wenn die Verantwortlichkeiten klar geregelt sind.

Labordaten geben Aufschluss darüber, was ein einzelner Rechner an einem Standort zu einem bestimmten Zeitpunkt unter kontrollierten Bedingungen gemessen hat. Felddaten geben Aufschluss darüber, welche Erfahrungen echte Nutzer in großem Maßstab gemacht haben. An den meisten Websites weichen diese beiden Daten erheblich voneinander ab, und Google nutzt die Felddaten als Ranking-Signale. Optimieren Sie daher zuerst für die Felddaten und erst in zweiter Linie für die Labordaten.

Wo kann man Felddaten einlesen?

Search Console > Bericht „Core Web Vitals“. CrUX-Datensatz in BigQuery, wenn Sie Rohdaten auf Ereignisebene benötigen. PageSpeed Insights > Abschnitt „Felddaten“ (sofern für die URL ausreichende Echtnutzerdaten vorliegen). Calibre, SpeedCurve und Treo bieten kostenpflichtigen Nutzern erweiterte Dashboards auf Basis von CrUX. RUM-Tools (Real User Monitoring) wie Vercel Analytics oder Cloudflare Web Analytics sorgen für noch mehr Detailgenauigkeit.

Wo kann man Laborwerte einsehen?

PageSpeed Insights > Abschnitt „Lab-Daten“. Lighthouse in den Chrome DevTools. WebPageTest für eine detaillierte Wasserfall-Analyse. Nützlich zur Ermittlung der Ursachen für einen Rückgang einer Feldmetrik, nicht jedoch zu deren Messung.

Der Diagnoseablauf, den ich durchführe

Feldmetrik-Regression in der Search Console. Das betroffene URL-Muster identifizieren. Labortests über WebPageTest an drei Standorten durchführen, um das Problem zu reproduzieren. Das Wasserfall-Diagramm überprüfen, um die fehlerhafte Anfrage zu finden. Beheben. 28 Tage warten, bis die CrUX-Felddaten aktualisiert sind. Die Behebung bestätigen.

Tatsächliche LCP-Werte, die ich im 75. Perzentil der Felddaten auf den Plattformen beobachtet habe, die ich am häufigsten ausliefere:

Statisch gerendertes Astro auf Netlify oder Cloudflare Pages

LCP typischerweise 0,6 bis 1,0 Sekunden. Ein Lighthouse-Wert von 100 in allen vier Metriken ist das Standardergebnis. Anfängliches JavaScript unter 30 KB. Für Content-Websites die am schwersten zu erreichende Stufe.

Statisch gerendertes Next.js (App-Router mit RSC, SSG-Modus)

LCP 1,0 bis 1,5 Sekunden. Anfängliche JavaScript-Größe 80 bis 150 KB, je nachdem, wie viele Client-Komponenten ausgeliefert werden. Ein Lighthouse-Wert von über 90 ist erreichbar, erfordert jedoch gezielte Optimierung.

ISR oder SSR bei Next.js

LCP 1,5 bis 2,5 Sekunden, abhängig von der Cache-Trefferquote und der Antwortzeit des Ursprungsservers. Bei „Cold Cache Misses“ beträgt die Dauer 3 bis 5 Sekunden. Hervorragende Technologie mit einer realen Kostenkurve und einer realen Leistungsschwankung.

WordPress auf Kinsta oder WP Engine plus Cloudflare

LCP typischerweise 1,8 bis 2,8 Sekunden. Mit konsequenter Umsetzung lassen sich die CWV-Schwellenwerte erreichen. Die Websites, die ich auf diesem Stack betreibe, bestehen nach der Optimierung durchweg den CWV-Test im 75. Perzentil.

WordPress auf Shared Hosting

LCP 3,5 Sekunden oder schlechter. Bei Websites, bei denen die Leistung eine wichtige Rolle spielt, sollte diese Lösung vermieden werden.

Auf rund 70 % der Marketing-Seiten sind Bilder das LCP-Element. Die konsequente Handhabung von Bildern ist der wichtigste Leistungshebel, den ich kenne.

Format und Komprimierung

WebP mit der Qualitätseinstellung 82 bietet das optimale Verhältnis zwischen Bildqualität und Dateigröße. AVIF ist zwar kleiner, die Kodierung erfolgt jedoch langsamer und die Browserunterstützung weist noch einige Lücken auf. Verzichten Sie bei allen Bildern, die keine Originaldateien sind, auf JPEG und PNG. WebP mit q=82 erzeugt in der Regel Dateien, die 70 bis 90 % kleiner sind als die PNG-Quelldatei, ohne dass dabei wahrnehmbare Qualitätsverluste auftreten.

Auf die tatsächlich gerenderten Abmessungen skalieren

Ein 4K-JPEG mit einer Breite von 1200 Pixeln bedeutet eine Verschwendung von 90 % der Bandbreite. Passen Sie die Bildgröße stets an die größte Abmessung an, in der das Bild dargestellt wird, und erstellen Sie zusätzlich eine 2- oder 3-fache Version für Displays mit hoher Pixeldichte. Sharp erledigt dies mit etwa fünf Zeilen Code in jeder Node.js-Build-Pipeline.

FAL-Hero-Pipeline

Wir generieren Hero-Bilder über FAL flux-pro/v1.1-ultra und Imagen 4 direkt aus der Auto-Blog-Pipeline. Die generierten Bilder sind JPEGs mit einer Größe von 600 KB bis 1,5 MB und einer Auflösung von 1200 × 675. Das Hochladen der Rohdaten in den Supabase-Speicher bedeutet, dass jede Seite allein für das Hero-Bild etwa 1 MB an Daten überträgt. Vor dem Hochladen in den Speicher leiten wir die Bilder durch sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer(). Dadurch wird die Dateigröße um 90 % reduziert, ohne dass ein wahrnehmbarer Qualitätsverlust entsteht. Nach der Anwendung dieser Pipeline konnten wir auf einer einzelnen Seahawk-Website bei 53 Hero-Bildern eine Einsparung von 50 MB siteweit verzeichnen. Verwenden Sie beim Upload in den Speicher ebenfalls `cacheControl: 31536000`.

Explizite Angabe von Breite und Höhe bei jedem `img`-Element

Browser reservieren erst dann Platz, bevor das Bild geladen wird, wenn die Attribute „width“ und „height“ im HTML-Code vorhanden sind. Fehlen diese, kommt es beim Laden der Bilder zu Layoutverschiebungen und der CLS-Wert steigt an. Die Bildkomponenten von Astro und Next.js kümmern sich automatisch darum; bei einfachen `img`-Tags muss dies manuell erfolgen.

LCP-Bild-Vorladen

Das „Hero-Bild“ oberhalb der Falz sollte mit dem Link „rel=‘preload’ as=‘image’“ im Head-Bereich vorgeladen werden. Das spart in der Regel 100 bis 400 ms. Dies ist die einzelne, einzeilige Änderung mit der größten Wirkung, die auf den meisten Marketing-Websites möglich ist.

JavaScript ist auf den meisten modernen Websites der größte Leistungsengpass. Das Budget, mit dem ich 2026 arbeite:

Anfängliches JavaScript unter 100 KB auf Content-Websites

Unterhalb von 100 KB werden das Framework, die Website sowie alle Analyse- und Marketing-Pixel zusammen auf einem mobilen Gerät der mittleren Leistungsklasse immer noch schnell genug geladen und ausgeführt. Oberhalb von 100 KB macht sich dies in den Kennzahlen INP und TTI bemerkbar – oft unbemerkt für den Desktop-Entwickler, der auf einem schnellen Laptop testet.

Alles, was nicht „above-the-fold“ ist, zurückstellen

Analytics, Social-Pixel, Chat-Widgets, Skripte für A/B-Tests. Keines dieser Elemente muss den „First Paint“ blockieren. Verwenden Sie das „defer“-Attribut oder laden Sie sie erst bei einer Benutzerinteraktion. Die Verbesserung des CWV ist oft dramatisch, der Verlust an Nutzerinteraktion beträgt in der Regel null.

Vermeiden Sie umfangreiche Client-Komponenten oberhalb der Falz

Ein Helden-Karussell, für dessen Darstellung des ersten Frames React + framer-motion + 30 KB unterstützender Code erforderlich sind, beeinträchtigt die Leistung. Stellen Sie die erste Folie als statisches HTML dar und füllen Sie das Karussell erst dann mit Inhalten, wenn der Benutzer im Begriff ist, damit zu interagieren.

Drittanbieter-Skripte vierteljährlich überprüfen

Marketing-Skripte häufen sich unbemerkt an. Eine Website, die im Jahr 2020 ein Analytics-Tag enthielt, verfügt im Jahr 2026 über acht Skripte, wenn niemand eine Überprüfung durchführt. Führen Sie vierteljährlich eine Überprüfung mit Lighthouse oder WebPageTest durch, ermitteln Sie, welche Skripte noch ihren Platz verdienen, und entfernen Sie alles, was nicht mehr benötigt wird.

Das Wichtigste auf einen Blick: Betrachten Sie „JavaScript-Budgetdisziplin“ in erster Linie als operative Entscheidung. Die Tools funktionieren nur, wenn die Verantwortlichkeiten klar geregelt sind.

Wichtige CSS-Elemente wurden inline eingebunden, der Rest wurde zurückgestellt

Das CSS, das für die Darstellung des Bereichs „above-the-fold“ benötigt wird, sollte im `head`-Bereich inline eingebunden werden. Der Rest kann asynchron geladen werden. Astro und Next.js erledigen dies automatisch mithilfe ihres CSS-Scoping; bei manuell erstellten Websites ist ein Schritt zur Extraktion des kritischen CSS in der Build-Pipeline erforderlich.

Schriftarten selbst hosten und „font-display: swap“ verwenden

Von Google Fonts geladene Webfonts verursachen in der Regel eine Verzögerung von 100 bis 300 ms. Durch das Selbsthosting vom selben Ursprung wie die Website entfällt die DNS-Abfrage. Mit „font-display: swap“ wird der Fallback-Text sofort dargestellt, während der Webfont geladen wird, wodurch FOIT (Flash of Invisible Text) vermieden wird. Variablene Fonts liefern, sofern unterstützt, mehrere Schriftstärken aus einer einzigen Datei.

Beschränken Sie die Schriftarten auf die Sprachen, die Sie tatsächlich anbieten

Eine Teilmenge der lateinischen Schriftzeichen ist 30 bis 60 KB groß. Die vollständige mehrsprachige Datei ist oft 250 KB oder größer. Die Reduzierung auf eine Teilmenge erfordert in den meisten Build-Pipelines lediglich eine einzeilige Änderung und spart bei jedem Laden einer Seite erheblich Bandbreite ein.

Die Hosting- und Edge-Ebene ist wichtiger, als die meisten Teams annehmen. Der nicht ganz offensichtliche Ratschlag:

Cloudflare immer vor dem Ursprungsserver

Ganz gleich, ob Ihr Ursprungsserver Vercel, Netlify, AWS oder ein Managed-WordPress-Host ist: Durch den Einsatz von Cloudflare als Frontend lassen sich die globale Latenz verbessern, Bot-Traffic abfangen und Caching-Funktionen nutzen, die andernfalls vom Ursprungsserver bereitgestellt würden. Für die meisten Websites reicht die kostenlose Stufe aus; die kostenpflichtigen Stufen bieten zusätzliche Funktionen für Observability und Sicherheit.

Das statische Rendering ist der wichtigste Hebel für die Leistung

Vorgerenderte HTML-Seiten, die von CDN-Edge-Knoten bereitgestellt werden, erreichen weltweit eine TTFB von unter 100 ms. Kein Origin-Hop, keine Datenbankabfrage, kein Rendern von Vorlagen. Wenn Ihre Inhalte nicht unbedingt dynamisch sein müssen, rendern Sie sie statisch.

Kantenfunktionen für die dynamische Oberfläche

Wenn Sie dynamisches Verhalten benötigen (Authentifizierung, Personalisierung, A/B-Tests), werden Edge-Funktionen auf Cloudflare Workers oder Vercel Edge Functions näher am Nutzer ausgeführt als Origin-Server. Die Latenz sinkt dadurch drastisch, ohne dass der Betriebsaufwand für den Betrieb der Infrastruktur entsteht.

Beobachten Sie die ISR-Abrechnung auf Vercel in großem Maßstab

Die inkrementelle statische Regeneration (ISR) ist eine hervorragende Technologie mit einer echten Kostenkurve. Im März 2026 haben wir bei Deluxe Astrology einen Abrechnungsmonat mit mehreren Millionen ISR-Ereignissen erreicht. Die Lösung bestand in einer expliziten Regel „zwei Produktionszusammenführungen pro Woche“, da jede Zusammenführung bei einem Umfang von 91.000 Seiten etwa sechs Millionen ISR-Schreibereignisse auslöst. Planen Sie dies ein, wenn Sie ISR auf einer großen Website einsetzen.

Bevor ich eine neue Website oder Vorlage für startbereit erkläre, gehe ich diese Checkliste durch. Sie ist bewusst kurz gehalten. Lange Checklisten werden nie benutzt.

1. Das Hero-Bild wird mit dem Link-Attribut „rel=preload“ als Bild vorgeladen. 2. Bilder im Bereich „Above-the-fold“ haben explizit festgelegte Breite und Höhe. 3. WebP-Format, Qualität 82, auf die Darstellungsmaße skaliert. 4. Kritisches CSS wird inline eingebunden, der Rest wird verzögert geladen. 5. Webfonts werden selbst gehostet mit „font-display: swap“. 6. Das anfängliche JavaScript ist kleiner als 100 KB. 7. Analytics- und Marketing-Skripte werden verzögert geladen. 8. CSS-Grid-Spalten verwenden „minmax(0, 1fr)“ statt „1fr“, um einen Überlauf bei langen Inhalten zu verhindern. 9. Statisches Rendering, wo immer es der Inhalt zulässt. 10. Cloudflare vor dem Ursprungsserver. 11. Felddaten werden wöchentlich über die Search Console gemessen. 12. Der SEO-Linter zur Erstellungszeit bricht den Build bei Regressionen ab.

Websites, bei denen alle zwölf Kriterien erfüllt sind, weisen selten Probleme mit dem CWV auf. Websites, bei denen drei oder vier Kriterien fehlen, scheitern letztendlich am 75. Perzentil, und das Team muss sich beeilen, das Problem zu beheben, nachdem Google es bereits bemerkt hat.

Nicht jede Website muss bei Lighthouse 100 Punkte erreichen. Die ehrliche Herangehensweise an die Frage „Wie viel Arbeit an der Performance ist genug?“:

Websites mit weniger als 10.000 Besuchern pro Monat, die wirtschaftlich nicht von Suchrankings abhängig sind: Erreichen Sie die CWV-Schwellenwerte am 75. Perzentil und hören Sie dann auf. Eine weitere Optimierung bringt immer weniger Ertrag. Verwenden Sie die Zeit stattdessen lieber für Inhalte oder Ihr Produkt.

Websites mit bezahltem Traffic, bei denen die Konversionsrate eine Rolle spielt: Jede 100 ms LCP kostet bei durchschnittlichen Benchmarks etwa 1 bis 4 % der Konversionen. Eine Optimierung über die CWV-Schwellenwerte hinaus zahlt sich in der Regel bei großem Umfang aus. Rechnen Sie nach und setzen Sie entsprechend Prioritäten.

Websites, bei denen der Lighthouse-Score Teil des Marken-Briefings ist: Erreichen Sie einen Lighthouse-Wert von 100 und behandeln Sie jede Verschlechterung als Fehler. Der Optimierungsaufwand vervielfacht sich, da das Team keine Verschlechterungen in die Produktion lässt.

Websites mit Redaktionsteams, die die Optimierungsdisziplin nicht aufrechterhalten können: Wählen Sie das Framework, das standardmäßig eine gute Performance liefert (Astro, statisch gerendertes Next.js, Headless-WordPress mit Managed Hosting), und nehmen Sie die Einschränkungen in Kauf. Eine manuelle Leistungsoptimierung, die das Team nicht aufrechterhalten kann, ist weniger wert als eine etwas weniger optimale Standardeinstellung, die aber beständig bleibt.

Leistung im Jahr 2026 ist eine strukturelle Grundhaltung: Wahl des Frameworks, Wahl des Hostings, Disziplin bei der Bildverarbeitung, JavaScript-Budget, Disziplin bei CSS und Schriftarten, Edge-Caching sowie die CWV-Checkliste, die bei jedem Launch angewendet wird. Websites, die diese Aspekte frühzeitig integrieren, erreichen ein Leistungsniveau, das sich zunehmend positiv auswirkt. Websites, die sie erst später nachrüsten, geben mehr aus und erzielen weniger.

Sie brauchen am ersten Tag nicht jede Zeile dieses Leitfadens. Sie müssen jedoch wissen, welchen Hebel Sie noch nicht betätigt haben, und den nächsten betätigen, bevor die Felddaten Ihnen zeigen, dass es bereits zu spät war.

Wenn du ein Core Web Vitals Audit für deine spezifische Website möchtest, führe ich diese ab 1.500 Dollar durch. Das Audit liefert Field-Data-Analyse, priorisierte Verbesserungen und ein Zielmetrik-Profil, das du über die Zeit verfolgen kannst.

Das Wichtigste auf einen Blick: Betrachten Sie „das Endergebnis“ in erster Linie als operative Entscheidung. Das Instrumentarium funktioniert nur, wenn die Verantwortlichen ehrlich sind.