Core Web Vitals: Warum Ladezeiten über Ihren Erfolg entscheiden

Was sind Core Web Vitals?

Core Web Vitals sind drei von Google definierte Metriken, die die tatsächliche Nutzererfahrung einer Website messen:

• LCP (Largest Contentful Paint) — Wie schnell wird der Hauptinhalt sichtbar? Ziel: unter 2,5 Sekunden. Der LCP ist meist das größte Bild oder die Überschrift im sichtbaren Bereich — solange sie fehlen, wirkt die Seite „noch nicht da“.
• INP (Interaction to Next Paint) — Wie schnell reagiert die Seite auf Klicks, Tipps und Eingaben? Ziel: unter 200 Millisekunden. INP hat 2024 den älteren FID-Wert abgelöst und misst die Reaktionsträgheit über den gesamten Besuch, nicht nur beim ersten Klick.
• CLS (Cumulative Layout Shift) — Wie stabil bleibt das Layout beim Laden? Ziel: unter 0,1. Jeder kennt den Effekt: Man will klicken, und der Button springt weg, weil ein Banner nachlädt.

Warum diese Werte über Umsatz entscheiden

Google nutzt Core Web Vitals als Ranking-Signal: Bei vergleichbarer inhaltlicher Relevanz werden schnellere Seiten bevorzugt. Der SEO-Effekt ist aber nur die halbe Wahrheit — der direktere Hebel ist die Conversion:

• Bessere Ladezeiten senken die Absprungrate und erhöhen die Conversion-Rate messbar.
• Weniger Layout-Shifts bedeuten weniger Fehlklicks und weniger Frustration im entscheidenden Moment.
• Schnelle Interaktion vermittelt Qualität — eine träge Website färbt auf die Wahrnehmung des Angebots ab.

Eine viel zitierte Amazon-Rechnung besagt, dass jede 100 Millisekunden zusätzliche Ladezeit rund 1 % Umsatz kosten. Die absolute Zahl ist auf kleine Unternehmen nicht übertragbar, der Mechanismus schon: Wer auf einer langsamen Seite kaufen oder anfragen will, bricht häufiger ab. Wie stark Ladezeit speziell im Shop auf den Umsatz wirkt, zeigt unser Beitrag zur Conversion-Rate-Optimierung.

Labordaten vs. Felddaten — der wichtigste Unterschied beim Messen

Wer seine Werte prüft, stolpert schnell über widersprüchliche Zahlen. Der Grund: Es gibt zwei Datenquellen. Labordaten (Lighthouse, der untere Teil von PageSpeed Insights) entstehen in einer simulierten Testumgebung — reproduzierbar, aber künstlich. Felddaten (der obere Teil von PageSpeed Insights, Quelle: Chrome UX Report) stammen von echten Besuchern der letzten 28 Tage — und nur diese Felddaten fließen ins Ranking ein. Eine Seite kann im Labor-Test schlecht aussehen und im Feld grün sein, oder umgekehrt. Für die Diagnose gilt deshalb: Felddaten sagen, ob ein Problem besteht; Labordaten helfen herauszufinden, woran es liegt.

Die wichtigsten kostenlosen Werkzeuge: PageSpeed Insights für die Einzelseiten-Analyse mit konkreten Verbesserungsvorschlägen, die Google Search Console für den Überblick über alle indexierten Seiten, Lighthouse in den Chrome DevTools für Entwickler — und unser kostenloser Website-Check, der Performance, SEO-Grundlagen und mobile Darstellung Ihrer Seite in einem Durchgang prüft und die Ergebnisse verständlich einordnet.

Die häufigsten Performance-Killer

In unserer Praxis sehen wir immer wieder dieselben Probleme — in dieser Reihenfolge:

• Nicht optimierte Bilder: fehlende Kompression, keine modernen Formate (WebP/AVIF), Bilder in voller Auflösung für kleine Darstellungen. Der häufigste und am leichtesten behebbare LCP-Killer.
• Zu viele externe Skripte: Analytics, Chat-Widgets, Karten, Fonts, Social-Embeds — jedes Skript kostet Ladezeit und blockiert oft die Interaktivität (INP).
• Kein Caching, kein CDN: Jeder Seitenaufruf wird komplett neu berechnet und aus einem einzigen Rechenzentrum ausgeliefert.
• Veraltete CMS-Installationen mit aufgeblähten Plugins: Besonders bei gewachsenen WordPress-Seiten laden Dutzende Plugins ihre Skripte auf jeder einzelnen Seite.
• Render-blockierendes CSS und JavaScript: Der Browser darf nichts anzeigen, bevor er Dateien geladen hat, die für den sichtbaren Bereich gar nicht nötig wären.
• Fehlende Größenangaben für Bilder und Einbettungen: die Hauptursache für Layout-Sprünge (CLS) — der Browser weiß nicht, wie viel Platz er reservieren soll.

Wie wir Performance optimieren

Unser Ansatz bei M² WEBVISION: Performance ist kein Nachgedanke, sondern Teil der Architektur. Konkret setzen wir auf:

• Next.js mit automatischem Code-Splitting und serverseitigem Rendering — der Browser bekommt fertiges HTML statt eines JavaScript-Pakets, das er erst ausführen muss;
• Bildoptimierung mit automatischer Format-Konvertierung (WebP/AVIF) und größenabhängiger Auslieferung;
• Edge-Hosting über Vercel für minimale Latenz — die Seite kommt vom nächstgelegenen Serverstandort;
• Lazy Loading für Inhalte unterhalb des sichtbaren Bereichs;
• konsequente Minimierung von Third-Party-Skripten — jedes Widget muss seinen Ladezeit-Preis rechtfertigen.

Genauso wichtig wie die einmalige Optimierung ist das Dranbleiben: Core Web Vitals verschlechtern sich schleichend — ein neues Plugin hier, ein Tracking-Skript dort, unkomprimierte Bilder im Blog. Deshalb gehört Performance-Monitoring in die laufende Wartung, nicht in die Kategorie „einmal gemacht, für immer erledigt“.

Wenn die Werte rot sind: reparieren oder neu bauen?

Nicht jedes Performance-Problem rechtfertigt große Investitionen. Bilder komprimieren, Caching aktivieren, überflüssige Plugins entfernen — das bringt auf den meisten Seiten spürbare Verbesserungen zu überschaubaren Kosten. Die ehrliche Grenze verläuft an der Architektur: Wenn Theme, Plugin-Struktur und Hosting das Problem sind, kostet das Auf-Grün-Optimieren einer alten Installation oft mehr als ein Neuaufbau — und liefert trotzdem schlechtere Werte. Woran Sie erkennen, dass dieser Punkt erreicht ist, behandelt unser Beitrag zum richtigen Zeitpunkt für den Website-Relaunch.

Fazit

Core Web Vitals sind kein technisches Detail für Entwickler, sondern ein Business-Faktor: Google nutzt die drei Metriken LCP (Hauptinhalt sichtbar in unter 2,5 Sekunden), INP (Reaktion auf Eingaben unter 200 Millisekunden) und CLS (Layout-Stabilität unter 0,1) als Ranking-Signal — und langsame Seiten verlieren Besucher, bevor diese anfragen oder kaufen. Maßgeblich sind die Felddaten echter Besucher, nicht der Labor-Score. Die häufigsten Ursachen schlechter Werte sind unoptimierte Bilder, zu viele externe Skripte und aufgeblähte CMS-Installationen. Vieles davon ist mit gezielten Maßnahmen behebbar; scheitert die Optimierung an der Architektur, ist der Neuaufbau meist wirtschaftlicher als die Reparatur.