Core Web Vitals verbessern: Schnelle Websites für KMU 2026.

Seit 2021 sind Core Web Vitals offizieller Google-Ranking-Faktor. 2024 hat Google FID durch INP ersetzt, und die Messung ist heute strenger als früher. Für KMU ist das keine Panik-Nachricht, aber auch nicht ignorierbar: Wer langsame Seiten ausliefert, verliert messbar Positionen bei kompetitiven Suchbegriffen. Hier ist, was die drei Kennzahlen bedeuten, wie du sie misst und welche Schritte wirklich helfen.

Die drei Core Web Vitals

LCP — Largest Contentful Paint

Misst, wann das größte sichtbare Element (meistens ein Hero-Bild oder eine große Headline) geladen ist. Richtwert: unter 2,5 Sekunden. Alles über 4 Sekunden gilt als schlecht.

Typische Ursachen für schlechten LCP:

• Riesige unkomprimierte Hero-Bilder (5+ MB).
• Langsamer Hosting-Server oder fehlendes CDN.
• Web-Fonts, die den Text blockieren (FOIT — Flash of Invisible Text).
• JavaScript-Frameworks, die das Rendering verzögern.

INP — Interaction to Next Paint

Misst, wie schnell die Seite auf Nutzerinteraktionen reagiert — Klick, Tipp, Tastenanschlag. Seit März 2024 ersetzt INP den älteren FID. Richtwert: unter 200 Millisekunden. Über 500 ms ist schlecht.

Typische Ursachen für schlechten INP:

• Zu viel JavaScript, das beim Laden auf dem Main-Thread läuft.
• Schwere Tracking-Skripte (Google Tag Manager, Facebook Pixel, Hotjar).
• Third-Party-Widgets (Chat-Tools, Review-Widgets, Cookie-Banner).
• Event-Handler, die bei jedem Klick zu viele Berechnungen auslösen.

CLS — Cumulative Layout Shift

Misst, wie stark sich Inhalte während des Ladens visuell verschieben. Richtwert: unter 0,1. Das klassische Beispiel: Du wolltest den Kontakt-Button drücken, aber in dem Moment lädt ein Banner nach, der Button rutscht, und du klickst auf etwas anderes.

Typische Ursachen für schlechten CLS:

• Bilder ohne festgelegte width/height-Attribute.
• Dynamisch eingefügte Inhalte (Banner, Werbung, Popups).
• Web-Fonts, die nachträglich geladen werden und Text umfließen.
• Iframes ohne feste Dimensionen.

Wie du die Werte misst

Es gibt zwei Arten von Messungen: Labor-Daten (eine simulierte Seite wird einmal geladen) und Felddaten (tatsächliche Nutzer- Messungen aus dem Chrome UX Report). Google wertet für das Ranking nur die Felddaten.

Hilfreiche Tools:

• PageSpeed Insights (pagespeed.web.dev): Laborwerte plus Felddaten, wenn genug Traffic vorhanden ist.
• Google Search Console: Feldmessungen über alle Seiten deiner Property, mit Aufteilung in „Gut", „Optimierung nötig", „Schlecht".
• Chrome DevTools (Lighthouse-Tab): schneller lokaler Check im Browser.
• web.dev/measure: ähnlich wie PageSpeed Insights, andere UI.

Für KMU-Websites ohne großen Traffic stehen in der Search Console oft keine Felddaten zur Verfügung. Dann zählen die Laborwerte als Annäherung.

Die wichtigsten Fixes nach Wirkung

1. Bilder komprimieren und modernisieren

Das ist bei den meisten KMU-Websites der größte Einzel-Hebel. Konkret:

• Bilder vor dem Upload auf die richtige Anzeigegröße reduzieren (ein 1920-Pixel-Hero-Bild muss nicht 4000 Pixel breit hochgeladen werden).
• Modernes Format (WebP oder AVIF statt JPEG/PNG).
• Lazy-Loading für alle Bilder below-the-fold (loading="lazy" Attribut).
• width und height als HTML-Attribute setzen, damit der Browser Platz reserviert (gegen CLS).

2. Weniger JavaScript

Jedes Skript kostet INP. Praktische Maßnahmen:

• Tracking und Marketing-Pixel erst nach Cookie-Zustimmung laden.
• Chat-Tools (Intercom, Crisp) mit Verzögerung laden, nicht sofort.
• Jede nicht zwingend benötigte Third-Party-Bibliothek entfernen.
• Cookie-Banner mit schlanken Open-Source-Lösungen (Cookiebot, Klaro) oder ganz auf cookiefreies Analytics umstellen.

3. Schrift-Loading richtig machen

Web-Fonts sind oft Performance-Killer. Empfehlungen:

• Self-Hosting statt Google Fonts CDN (DSGVO-konform, oft schneller).
• Nur die wirklich benötigten Schnitte laden (nicht alle Gewichte und Kursiven).
• font-display: swap setzen, damit Text sofort sichtbar wird.
• Variable Fonts nutzen, wenn mehrere Gewichte gebraucht werden.

4. Hosting und CDN

Billiges Shared Hosting ist bei Performance oft der Flaschenhals. Für statische Websites (Next.js, Astro, Hugo) lohnt sich moderner Edge-Hosting (Vercel, Netlify, Cloudflare Pages) — die Seiten werden weltweit ausgeliefert, ohne dass der Server in München jedes Mal neu rendern muss. Für dynamische Seiten (WordPress) hilft ein vorgelagertes CDN (z. B. Cloudflare).

5. Render-Blocking-Ressourcen entfernen

CSS und JavaScript im head blockieren das Rendering. Wer Dev-Zugriff hat, kann:

• Unkritisches JS mit async oder defer laden.
• Critical CSS inlined in den head einfügen, den Rest asynchron nachladen.
• Unused CSS entfernen (Tools wie PurgeCSS).

Was realistisch erreichbar ist

Bei gut gebauten Seiten (moderne Frameworks, statische Auslieferung, wenig Third-Party-Skripte) sind Scores von 95 bis 100 in allen drei Kennzahlen normal. Bei typischen WordPress-KMU- Seiten mit Theme-Builder, 15 Plugins und unoptimierten Bildern liegen die Werte oft zwischen 40 und 70 — und verlieren messbar in der Suche.

Unsere Seiten bauen wir nach dem Prinzip: So viel statisch wie möglich, so wenig JavaScript wie möglich, alles komprimiert und modern. Das ist kein Zufall, sondern bewusste Architektur. Mehr dazu unter Leistungen.