Du hast eine schöne Website, aber die Anfragen bleiben aus? Dann lohnt sich ein Blick unter die Motorhaube – genauer gesagt: auf deine Core Web Vitals. Google bewertet Websites seit 2021 auch danach, wie schnell und wie stabil sie sich anfühlen. 2026 sind diese Kennzahlen nicht mehr Kür, sondern Pflicht.

Die gute Nachricht: Die drei Metriken LCP, INP und CLS sind berechenbar – und mit den richtigen Hebeln lassen sich fast alle Probleme in wenigen Tagen beheben. In diesem Guide zeige ich dir, was sich 2026 geändert hat, wie du deine Werte korrekt misst und welche zehn Stellschrauben den größten Hebel haben.

Das Ziel ist nicht, einen hübschen grünen Balken in PageSpeed Insights zu haben. Das Ziel ist eine Website, die in der realen Welt schnell ist – auf dem Smartphone deines Kunden, im schlechten Mobilfunknetz, beim ersten Klick. Genau das belohnt Google mit besseren Rankings und genau das sorgt für mehr Conversions.

Was sind Core Web Vitals überhaupt?

Die Core Web Vitals sind drei Kennzahlen, mit denen Google die tatsächliche Nutzererfahrung einer Website misst. Sie basieren nicht auf Schätzungen aus einem Labortest, sondern auf echten Daten, die Chrome von Millionen Nutzern anonymisiert sammelt (CrUX – Chrome User Experience Report). Wenn deine Seite bei diesen drei Werten gut abschneidet, hat Google einen klaren Hinweis: Hier funktioniert die Seite auch unter Realbedingungen.

Seit März 2024 hat Google FID durch INP ersetzt. Das ist für 2026 der wichtigste Punkt: Wer seine Performance nur auf FID optimiert hat, misst seitdem am Thema vorbei. INP ist strenger, strafft Interaktionen über die gesamte Seitenlebensdauer und wird häufiger rot als FID es je war.

LCP – Largest Contentful Paint

LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt im Viewport gerendert ist – typischerweise ein Hero-Bild oder eine große Überschrift. Ziel: unter 2,5 Sekunden. Wenn deine Seite länger braucht, wirkt sie träge, obwohl der Server vielleicht längst alles ausgeliefert hat.

INP – Interaction to Next Paint

INP misst, wie lange es dauert, bis die Seite auf eine Interaktion (Klick, Tap, Tastendruck) sichtbar reagiert. Anders als FID betrachtet INP alle Interaktionen während der gesamten Nutzungsdauer und nimmt den schlechtesten Wert. Ziel: unter 200 Millisekunden. Wenn du ein Formular hast, das nach einem Klick 800 ms blockiert, merkt INP das sofort.

CLS – Cumulative Layout Shift

CLS misst, wie stark sich dein Layout während des Ladens verschiebt. Jeder hat es schon erlebt: Du willst auf einen Button tippen, eine Werbeanzeige lädt nach, der Button rutscht nach unten und du klickst auf die Werbung. CLS belegt diesen Frustmoment mit einem Zahlenwert. Ziel: unter 0,1.

LCP

Gut: < 2,5 s
Mittel: 2,5–4 s
Schlecht: > 4 s

INP

Gut: < 200 ms
Mittel: 200–500 ms
Schlecht: > 500 ms

CLS

Gut: < 0,1
Mittel: 0,1–0,25
Schlecht: > 0,25

Warum Core Web Vitals 2026 wichtiger sind als je zuvor

Drei Dinge haben sich in den letzten Jahren verdichtet. Erstens: Google nutzt die Werte als Rankingsignal. Sie sind nicht das wichtigste Signal, aber wenn zwei Seiten inhaltlich gleichwertig sind, gewinnt die schnellere. Zweitens: Nutzer sind ungeduldiger geworden. Studien von Google zeigen, dass die Absprungrate um über 30 % steigt, sobald LCP von 1 s auf 3 s wächst. Drittens: Mobile Nutzung dominiert. 2026 surft die Mehrheit deiner Besucher mobil, oft in schwankender 4G- oder 5G-Qualität. Was auf deinem MacBook im Büro flott wirkt, ist auf einem Mittelklasse-Android unter Umständen zäh.

Dazu kommt: Performance ist Teil von Barrierefreiheit. Wer lange wartet oder in ein springendes Layout klickt, verliert das Vertrauen – genau wie bei fehlenden Alt-Texten oder zu kleinen Buttons. Mehr dazu findest du in meinem Beitrag zum Barrierefreiheitsstärkungsgesetz 2026.

So misst du deine Core Web Vitals richtig

Bevor du optimierst, musst du messen. Und zwar sowohl Labordaten (was ein kontrollierter Test zeigt) als auch Felddaten (was echte Nutzer erleben). Google zählt ausschließlich Felddaten fürs Ranking. Labordaten sind nur ein Wegweiser.

PageSpeed Insights

Der einfachste Einstieg: pagespeed.web.dev. URL einfügen, Report lesen. Der obere Teil zeigt echte CrUX-Daten der letzten 28 Tage, der untere Teil einen Lighthouse-Laborlauf. Wenn oben steht „Die Seite bestand die Core-Web-Vitals-Prüfung“, ist alles in Ordnung. Wenn es rot ist, weißt du, wo du ansetzen musst.

Google Search Console

In der Search Console findest du unter „Core Web Vitals“ einen Report für deine gesamte Domain. Er gruppiert URLs mit ähnlichen Problemen – praktisch, um systemische Fehler zu erkennen. Wenn 200 Produktseiten rot sind, aber nur zwei Content-Templates existieren, liegt der Fehler im Template.

Chrome DevTools & Lighthouse

Für tiefere Analysen: Öffne die DevTools in Chrome, Tab „Performance“. Mit einem Throttling auf „Slow 4G“ und einer emulierten Mobile-CPU bekommst du ein realistischeres Bild. Das Performance-Panel zeigt dir genau, welche Tasks die JavaScript-Laufzeit blockieren – der häufigste INP-Killer.

Real-User-Monitoring (RUM)

Wer es ernst meint, baut RUM ein. Tools wie SpeedCurve, Sentry oder die kostenlose Bibliothek web-vitals von Google loggen die Metriken direkt im Browser deiner Nutzer und schicken sie an ein Dashboard. So siehst du, wie sich ein Relaunch auf reale Nutzer auswirkt – nicht nur auf deinen Testserver.

LCP verbessern – sieben Hebel, die wirken

LCP ist meistens das dankbarste Ziel, weil die Ursachen klar sind. Ich sehe in 90 % der Projekte dieselben Fehler:

  1. Hero-Bild zu groß: Ein 4.000-px-Bild in einem 1.200-px-Container ist Verschwendung. Serviere JPEG/WebP in genau der Größe, die du brauchst, und nutze srcset plus sizes.
  2. Kein modernes Bildformat: WebP und AVIF sparen bei gleicher Qualität 30–70 % Bytes. Dein Bildhero sollte beides ausliefern, mit JPEG-Fallback.
  3. Blockierendes CSS: Ein 300-KB-CSS-File im <head> blockiert das Rendering. Inline die kritischen Styles für den First View, lade den Rest asynchron.
  4. Langsamer Server: Wenn die TTFB (Time To First Byte) schon 1,5 s beträgt, hast du beim LCP keine Chance. Billiges Shared Hosting ist 2026 das häufigste LCP-Problem.
  5. Keine CDN: Ein Nutzer aus Hamburg, der auf einen Server in Frankfurt zugreift, verliert schon 30–50 ms. Ein Nutzer aus Zürich verliert noch mehr. Ein CDN löst das Problem.
  6. Fehlendes Preload des LCP-Elements: <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> zwingt den Browser, das Hero-Bild früh zu laden.
  7. Web-Fonts ohne font-display: Wenn Text auf Fonts wartet, flimmert die Seite. Mit font-display: swap oder selbst gehosteten Fonts löst du das.

Praxis-Tipp: Ein Hero-Bild in WebP, mit fetchpriority="high" und sauberem Preload senkt den LCP oft von 3,8 s auf unter 1,5 s – in einer einzigen Deployment-Runde.

INP verbessern – weniger JavaScript, mehr UX

INP ist die Kennzahl, die 2026 am häufigsten rot ist. Grund: viele Websites laden zu viel JavaScript, das beim ersten Klick noch gar nicht fertig geparst ist. Die Hebel:

  • Drittanbieter-Skripte rausschmeißen oder lazy laden. Jedes Tracking-Pixel, jedes Chat-Widget, jedes A/B-Testing-Tool blockiert potenziell den Main Thread. Stelle dir bei jedem Skript die Frage: Muss das wirklich beim ersten Pageload laufen?
  • Lange Tasks aufteilen. JavaScript-Tasks über 50 ms gelten als Long Tasks. Zerlege große Funktionen in kleinere, gib dem Browser zwischendurch Zeit zum Atmen (setTimeout, scheduler.yield()).
  • Hydration-Last reduzieren. Bei React-/Next.js-Seiten ist Server-Side-Rendering plus partielle Hydration fast immer schneller als volle Client-Rendering-Apps.
  • Event-Handler entschlacken. Ein Klick-Handler, der 300 Zeilen Analytics feuert, bevor er das UI aktualisiert, verschlechtert INP. Rendere zuerst, track später.
  • CSS statt JavaScript. Wenn ein Akkordeon mit :has() oder details/summary funktioniert, brauchst du dafür kein Script.

CLS verbessern – stabile Layouts von Anfang an

CLS ist die Kennzahl, die sich am leichtesten auf null drücken lässt – wenn man sie ernst nimmt. Die größten Verursacher:

  • Bilder ohne width/height. Der Browser reserviert keinen Platz, das Bild pumpt den Inhalt runter, sobald es geladen ist. Immer Dimensionen angeben oder aspect-ratio setzen.
  • Web-Fonts ohne Fallback-Metriken. Wenn der Font nachlädt, springen Textblöcke. Mit size-adjust und ascent-override lässt sich das glätten.
  • Nachladene Werbung/Widgets ohne Reservierung. Reserviere Platzhalter mit festen Höhen, auch wenn der Inhalt asynchron kommt.
  • Cookie-Banner, die erst nach 2 s aufploppen und den Content runterschieben. Render das Banner oben oder als Overlay, nicht inline.

Typische Fehler und wie du sie vermeidest

Drei Fallen sehe ich besonders häufig, und sie kosten jeden Monat tausende Euro an verlorenen Conversions:

Fehler 1: Nur Labordaten optimieren. Ein Lighthouse-Score von 100 sagt wenig über die Realität. Lighthouse testet auf einer virtuellen Maschine im Datacenter, nicht auf einem alten iPhone in der S-Bahn. Immer die Felddaten aus der Search Console gegenprüfen.

Fehler 2: Plugins vor dem Problem installieren. Viele greifen zu „Performance-Plugins“ (WP Rocket, Autoptimize etc.), ohne zu verstehen, was die überhaupt tun. Ein Plugin, das falsch konfiguriert ist, macht die Seite langsamer als vorher.

Fehler 3: Optimieren, ohne vorher zu messen. Ich sehe regelmäßig Projekte, in denen wochenlang an Details geschraubt wurde – während das eigentliche Problem ein 3-MB-Hero-Video war, das niemand gebraucht hat. Erst messen, dann optimieren, dann wieder messen.

Quick-Wins, die du heute noch umsetzen kannst

Wenn du kurz auf die Uhr schaust und keine Lust auf einen Monat-Projekt hast, sind das die fünf Maßnahmen mit dem besten Aufwand-Nutzen-Verhältnis:

  1. Alle Bilder auf WebP umstellen und mit width/height versehen.
  2. Das Hero-Bild preloaden und mit fetchpriority="high" markieren.
  3. Tracking-Skripte auf defer/async setzen oder komplett rauswerfen, wenn sie niemand auswertet.
  4. Fonts selbst hosten statt Google Fonts direkt einzubinden (spart Requests und ist DSGVO-konform).
  5. Cookie-Banner auf ein festes Overlay umstellen, nicht inline.

Diese fünf Schritte bringen bei den meisten Seiten einen messbaren Sprung – oft von „Schlecht“ auf „Gut“ in allen drei Metriken. Und sie lassen sich an einem Nachmittag umsetzen.

Fazit: Performance ist kein Selbstzweck

Core Web Vitals sind kein Ego-Projekt für Entwickler, sondern ein Werkzeug, um deine Website geschäftlich besser zu machen. Schnellere Seiten ranken besser, konvertieren höher und werden seltener abgebrochen. Jede Sekunde, die du im LCP sparst, ist bares Geld – weil sie dafür sorgt, dass mehr Besucher bleiben, lesen und anfragen.

Wenn du mehr darüber lesen willst, warum eine Website gut aussehen und performen muss, um Kunden zu bringen, schau in meinen Beitrag 7 Gründe, warum deine Website keine Kunden bringt. Und wenn du wissen willst, welche Webdesign-Trends 2026 tatsächlich einen Performance-Vorteil haben, findest du die Antworten in Webdesign-Trends 2026.