CORE WEB VITALS 2026

Performance-Arbeit 2026 fällt in zwei Lager. Das reaktive Lager optimiert einzelne Seiten, sobald sie unter einen Schwellenwert fallen. Das strukturelle Lager baut Performance in die Framework-Wahl, das Design System, die Deployment-Pipeline und die Content-Disziplin ein, sodass Performance das Standardergebnis der Arbeit ist, nicht ein Optimierungspass, der später stattfindet. Jede Site, die ich langfristig erfolgreich gesehen habe, gehört zum strukturellen Lager.

Dieser Leitfaden bietet die strukturelle Perspektive. Konkrete Zahlen von Sites, die ich shipped habe, die tatsächlichen Checks, die ich durchführe, die teuersten Fehler, die ich gemacht habe, und die Teile des konventionellen Rat, die sich in der Praxis als falsch herausgestellt haben. Field Data von CrUX schlägt Lab Data von PageSpeed Insights immer, daher stammen die meisten Zahlen unten von echten Nutzern beim 75. Perzentil.

LCP (Largest Contentful Paint)

Die Zeit bis zur Darstellung des größten Inhalts oberhalb der Faltkante. Ziel: unter 2,5 Sekunden im 75. Perzentil. Die am häufigsten zitierte Core Web Vital, oft die einfachste zu beheben, wenn du das LCP-Element korrekt identifizierst. Die meisten Websites haben ein Bild oder einen Hero-Textblock als LCP-Element; die Lösung ist fast immer, das Bild vorab zu laden, es korrekt zu dimensionieren und sicherzustellen, dass kein JavaScript den Render blockiert.

CLS (Cumulative Layout Shift)

Wie sehr sich der Seiteninhalt während des Ladens unerwartet verschiebt. Ziel: unter 0,1. Die Metrik, die am häufigsten durch lazy-geladene Bilder ohne explizite Breite und Höhe, durch nach dem ersten Render eingefügte Anzeigen oder durch Web-Fonts mit anderen Metriken als das Fallback beeinträchtigt wird. In den meisten Fällen lösbar, indem man konsequent explizite Dimensionen für jedes visuelle Element oberhalb der Faltkante setzt.

INP (Interaction to Next Paint)

Die langsamste Interaktionszeit, die während der Seitenlebensdauer auftritt. Ziel: unter 200 ms. Hat FID im März 2024 ersetzt. Die schwierigste CWV-Metrik zum Manipulieren, da sie echte Benutzerreibung mit JavaScript bei langwierigen Aufgaben aufdeckt. Websites mit umfangreichem Client-JavaScript kämpfen hier fast immer. Die Lösung ist, weniger JavaScript auszuliefern, lange Aufgaben in kleinere Teile zu zerlegen und requestIdleCallback für nicht dringende Arbeiten zu verwenden.

TTFB (Time to First Byte)

Serverantwortzeit, bevor ein Render beginnen kann. Ziel: unter 600 ms. Offiziell keine Core Web Vital, aber es begrenzt jede andere Metrik. Statisch gerenderte Websites auf einem CDN erreichen typischerweise 50 bis 150 ms. WordPress auf gemeinsamen Hosting-Servern erreicht 800 ms bis 2,5 s bei kaltem Cache. Die Hosting-Entscheidung ist der größte TTFB-Hebel.

Lab Data zeigt dir, was eine Maschine an einem Ort zu einem Zeitpunkt unter kontrollierten Bedingungen gemessen hat. Field Data zeigt dir, was echte Benutzer im großen Stil erlebt haben. Die beiden weichen auf den meisten Websites erheblich ab, und Field Data ist das, was Google für Ranking-Signale verwendet. Optimiere zuerst für Field Data, dann für Lab Data.

Wo man Field Data liest

Search Console > Core Web Vitals Report. CrUX Dataset auf BigQuery, wenn du Raw Event-Level Data möchtest. PageSpeed Insights > Field Data Abschnitt (wenn ausreichend echte Nutzerdaten für die URL vorhanden sind). Calibre, SpeedCurve und Treo bieten angereicherte Dashboards auf Basis von CrUX für zahlende Nutzer. RUM Tooling (Real User Monitoring) wie Vercel Analytics oder Cloudflare Web Analytics fügt weitere Granularität hinzu.

Wo man Lab Data liest

PageSpeed Insights > Lab Data Abschnitt. Lighthouse in Chrome DevTools. WebPageTest für detaillierte Waterfall-Analyse. Hilfreich, um das Warum hinter einer Field Metric Regression zu diagnostizieren, nicht um sie zu messen.

Der diagnostische Ablauf, den ich durchlaufe

Field Metric Regression in Search Console. Identifiziere das betroffene URL Pattern. Führe Lab Tests über WebPageTest an drei Standorten durch, um das Problem zu reproduzieren. Inspiziere die Waterfall, um die problematische Request zu finden. Behebe das Problem. Warte 28 Tage, bis sich die CrUX Field Data aktualisiert. Bestätige die Behebung.

Echte LCP Zahlen, die ich beim 75. Perzentil der Field Data auf den Plattformen, auf denen ich am meisten deploye, gesehen habe:

Statisch gerendertes Astro auf Netlify oder Cloudflare Pages

LCP 0,6 bis 1,0 Sekunden typisch. Lighthouse 100 über alle vier Metriken ist das Standard-Ergebnis. Initial JavaScript unter 30KB. Die schwierigste Kategorie für Content Sites.

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

LCP 1,0 bis 1,5 Sekunden. Initial JavaScript 80 bis 150KB je nachdem, wie viele Client-Komponenten ausgeliefert werden. Lighthouse 90+ ist erreichbar, erfordert aber bewusste Optimierung.

ISR oder SSR Next.js

LCP 1,5 bis 2,5 Sekunden je nach Cache-Hit-Rate und Origin-Response-Zeit. Cold-Cache-Misses sind 3 bis 5 Sekunden. Ausgezeichnete Technologie mit echter Kostenkurve und echter Performance-Varianz.

WordPress auf Kinsta oder WP Engine plus Cloudflare

LCP 1,8 bis 2,8 Sekunden typischerweise. Es ist erreichbar, CWV-Schwellwerte mit Disziplin zu überschreiten. Sites, die ich auf diesem Stack betreibe, bestehen CWV konsistent beim 75. Perzentil nach dem Optimierungsdurchlauf.

WordPress auf Shared Hosting

LCP 3,5 Sekunden oder schlechter. Vermeiden Sie das für jede Website, bei der Performance Teil der Anforderung ist.

Images sind das LCP-Element auf ungefähr 70% der Marketing-Pages. Image-Disziplin ist der einzelne höchste Performance-Hebel, den ich kenne.

Format und Kompression

WebP mit Qualität 82 trifft den Sweet Spot zwischen Bildqualität und Dateigröße. AVIF ist kleiner, aber die Kodierung ist langsamer und die Browser-Unterstützung hat subtile Lücken. Überspringen Sie JPEG und PNG für alle Bilder, die keine Quelloriginalversionen sind. WebP bei q=82 erzeugt typischerweise Dateien, die 70 bis 90% kleiner sind als die Quell-PNG ohne wahrnehmbaren Verlust.

Auf tatsächliche Render-Dimensionen verkleinern

Eine 4K-JPEG, die mit 1200 Pixeln Breite gerendert wird, ist eine 90%-Bandbreitenverschwendung. Verkleinern Sie immer auf die größte Dimension, bei der das Bild gerendert wird, plus eine 2x- oder 3x-Version für hochauflösende Displays. Sharp macht das in 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 600KB bis 1,5MB JPEGs bei 1200x675. Das direkte Hochladen zu Supabase Storage bedeutet, dass jede Seite ~1MB nur für den Hero mitbringt. Wir pipen durch sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer() vor dem Speicher-Upload. Reduziert die Dateigröße um 90% ohne wahrnehmbaren Verlust. Wir sahen eine 50MB siteweite Ersparnis über 53 Hero-Bilder auf einer einzelnen Seahawk-Site nach Anwendung dieser Pipeline. Nutzen Sie auch cacheControl: 31536000 beim Speicher-Upload.

Explizite Breite und Höhe bei jedem img

Browser reservieren Platz vor dem Laden des Bildes nur, wenn Breite und Höhe im HTML vorhanden sind. Ohne sie entstehen Layout-Verschiebungen beim Laden der Bilder und CLS steigt. Astro- und Next.js-Image-Komponenten handhaben das automatisch; reine img-Tags brauchen es manuell.

LCP-Bildvorladung

Das Above-the-Fold-Hero-Bild sollte mit link rel="preload" as="image" im Head vorgeladen werden. Spart typischerweise 100 bis 400ms. Die einzelne höchste Auswirkung einer einzeiligen Änderung auf den meisten Marketing-Websites.

JavaScript ist die größte Performance-Belastung auf den meisten modernen Websites. Das Budget, nach dem ich 2026 arbeite:

Initial-JavaScript unter 100KB auf Content-Sites

Unter 100KB parsen und führen das Framework, die Website und alle Analytics- oder Marketing-Pixel kombiniert schnell genug auf einem Mid-Tier-Mobilgerät aus. Über 100KB zeigt sich der Kostenfaktor in INP und TTI, oft unsichtbar für den Desktop-Entwickler, der auf einem schnellen Laptop testet.

Alles aufschieben, das nicht above-the-fold ist

Analytics, Social Pixels, Chat-Widgets, A/B-Testing-Skripte. Keines davon muss den First Paint blockieren. Nutze das defer-Attribut oder lade bei Benutzerinteraktion. Die CWV-Verbesserung ist oft dramatisch, der Engagement-Verlust normalerweise null.

Vermeide schwere Client-Komponenten above-the-fold

Ein Hero-Carousel, das React + framer-motion + 30KB unterstützenden Code benötigt, um den ersten Frame zu rendern, ist eine Performance-Liability. Rendere die erste Folie als statisches HTML und hydratisiere das Carousel nur, wenn der Benutzer mit ihm interagieren wird.

Audit von Third-Party-Skripten vierteljährlich

Marketing-Skripte häufen sich unbemerkt an. Eine Website mit einem Analytics-Tag im Jahr 2020 hat acht Skripte im Jahr 2026, wenn niemand ein Audit durchführt. Führe eine vierteljährliche Prüfung über Lighthouse oder webpagetest durch, identifiziere, was sich noch rentiert, und entferne alles, das sich nicht rentiert.

Kritisches CSS inline, Rest verzögert

Das CSS, das zum Rendern des sichtbaren Bereichs notwendig ist, sollte im head inline eingebunden sein. Der Rest kann asynchron geladen werden. Astro und Next.js handhaben dies automatisch durch ihr CSS-Scoping; manuelle Sites benötigen einen Critical-CSS-Extraktionsschritt in der Build-Pipeline.

Fonts selbst hosten und font-display: swap verwenden

Web-Fonts von Google Fonts hinzugefügt üblicherweise 100 bis 300ms. Self-Hosting vom gleichen Origin wie die Site eliminiert den DNS-Lookup. font-display: swap rendert Fallback-Text sofort, während der Web-Font lädt, und verhindert FOIT (Flash of Invisible Text). Variable Fonts liefern, wo unterstützt, mehrere Schriftstärken aus einer einzelnen Datei.

Fonts auf die Sprachen begrenzen, die du tatsächlich bereitstellst

Ein lateinisches Font-Subset ist 30 bis 60KB. Die vollständige mehrsprachige Datei ist oft 250KB+. Subsetting ist eine Ein-Zeilen-Änderung in den meisten Build-Pipelines und spart erhebliche Bandbreite bei jedem Seitenaufruf.

Hosting und Edge-Layer sind wichtiger als die meisten Teams ihnen zugestehen. Der nicht offensichtliche Rat:

Cloudflare vor dem Origin immer

Egal ob dein Origin Vercel, Netlify, AWS oder ein verwalteter WordPress-Host ist: Cloudflare davor zu platzieren verbessert globale Latenz, absorbiert Bot-Traffic und fügt Caching hinzu, das der Origin sonst selbst bedienen würde. Der kostenlose Tier reicht für die meisten Sites aus; bezahlte Tier fügen Observability und Sicherheits-Features hinzu.

Statisches Rendering ist der größte Performance-Hebel

Vorgerenderte HTML, die von CDN-Edge-Knoten bereitgestellt wird, erreicht global sub-100ms TTFB. Kein Origin-Hop, keine Datenbankabfrage, kein Template-Rendering. Wenn dein Content nicht unbedingt dynamisch sein muss, rendere ihn statisch.

Edge Functions für die dynamische Oberfläche

Wenn du dynamisches Verhalten brauchst (Auth, Personalisierung, A/B), führen Edge Functions auf Cloudflare Workers oder Vercel Edge Functions näher beim Nutzer aus als Origin-Server. Die Latenz fällt dramatisch, ohne die operative Last, Infrastruktur selbst zu betreiben.

Beobachte ISR-Abrechnung auf Vercel im großen Maßstab

Incremental Static Regeneration ist exzellente Technologie mit echter Kostenentwicklung. Wir hatten einen Abrechnungsmonat mit mehreren Millionen ISR-Events auf Deluxe Astrology im März 2026. Die Lösung war eine explizite „zwei Produktions-Merges pro Woche"-Regel, da jeder Merge etwa sechs Millionen ISR-Schreibereignisse bei 91.000-Seiten-Größe auslöst. Plane dafür ein, wenn du ISR auf einer großen Site laufen lässt.

Bevor ich einen neuen Site oder Template als launch-ready erkläre, laufe ich durch diese Checkliste. Sie ist bewusst kurz. Lange Checklisten werden nie verwendet.

1. Hero-Bild wird mit link rel preload als image vorgeladen. 2. Above-the-fold-Bilder haben explizite Breite und Höhe. 3. WebP-Format, Qualität 82, auf Render-Dimensionen skaliert. 4. Kritisches CSS inline, Rest deferred. 5. Web-Fonts selbst gehostet mit font-display: swap. 6. Initial JavaScript unter 100KB. 7. Analytics- und Marketing-Skripte deferred. 8. CSS Grid-Spalten verwenden minmax(0, 1fr) nicht 1fr, um Overflow bei langen Inhalten zu verhindern. 9. Statisches Rendering überall wo der Content es erlaubt. 10. Cloudflare vor Origin. 11. Field Data wöchentlich via Search Console gemessen. 12. Build-time SEO Linter bricht den Build bei Regressionionen ab.

Sites, die mit allen zwölf Punkten deployed werden, haben selten CWV-Probleme. Sites, die drei oder vier davon auslassen, schlagen letztendlich beim 75. Perzentil fehl und das Team versucht fieberhaft, es zu reparieren, nachdem Google es bereits bemerkt hat.

Nicht jede Website muss bei Lighthouse 100 landen. Die ehrliche Antwort auf die Frage „wie viel Performance-Arbeit ist genug":

Websites unter 10.000 monatlichen Besuchern ohne kommerzielle Abhängigkeit von Such-Rankings: erfüllen Sie die CWV-Schwellwerte im 75. Perzentil und hören Sie auf. Weitere Optimierung bringt nur noch sinkende Erträge. Verwenden Sie die Zeit lieber für Inhalte oder Produkt.

Websites mit bezahltem Traffic, bei denen die Conversion Rate zählt: jede 100ms LCP kostet durchschnittlich etwa 1 bis 4% der Conversions nach Benchmark-Daten. Optimierung über die CWV-Schwellwerte hinaus zahlt sich typischerweise in der Skalierung aus. Rechnen Sie nach, priorisieren Sie entsprechend.

Websites, bei denen der Lighthouse-Score Teil des Brand-Briefings ist: erreichen Sie Lighthouse 100 und behandeln Sie jede Regression als Bug. Die Optimierungsarbeit verstärkt sich selbst, weil das Team keine Regressionen in den Live-Status lässt.

Websites mit redaktionellen Teams, die keine Performance-Disziplin durchhalten: wählen Sie das Framework, das Performance standardmäßig liefert (Astro, statisch gerendertes Next.js, headless WordPress mit verwaltetes Hosting), und akzeptieren Sie die Einschränkung. Manuelle Performance-Tuning, das das Team nicht aufrechterhalten kann, ist weniger wert als ein etwas weniger optimales Standard, das Bestand hat.

Performance 2026 ist eine strukturelle Haltung: Framework-Wahl, Hosting-Wahl, Image-Pipeline-Disziplin, JavaScript-Budget, CSS- und Font-Disziplin, Edge-Caching und die CWV-Checkliste bei jedem Launch. Websites, die das früh einbauen, bekommen einen Performance-Floor, der sich verstärkt. Websites, die es später aufsetzen, geben mehr aus für weniger.

Du brauchst nicht jede Zeile dieses Leitfadens am ersten Tag. Du brauchst zu wissen, welchen Hebel du noch nicht gezogen hast, und den nächsten ziehen, bevor die Field-Daten dir sagen, dass es schon zu spät war.

Wenn du ein Core Web Vitals Audit für deine spezifische Website möchtest, führen wir diese bei Seahawk Media ab 2.500 USD durch. Das Audit liefert Field-Data-Analyse, priorisierte Lösungsvorschläge und ein Zielmetrik-Profil, das du über die Zeit hinweg tracken kannst.