Warum Ihre Website zu langsam ist — und was das für Google und Ihre Kunden bedeutet

Core Web Vitals: Was Google misst und warum es Ihr Ranking beeinflusst

Google misst seit 2021 drei Kern-Metriken, die direkt in das Suchranking einfließen. LCP (Largest Contentful Paint) misst, wie schnell der größte sichtbare Inhaltsblock lädt, typischerweise das Hero-Bild oder die Hauptüberschrift. CLS (Cumulative Layout Shift) misst, wie stark die Seite während des Ladens springt und Elemente verschiebt. INP (Interaction to Next Paint) ersetzt seit März 2024 FID und misst, wie schnell die Seite auf Nutzerinteraktionen wie Klicks oder Tastatureingaben reagiert.

Die Google-Zielwerte: LCP unter 2,5 Sekunden gilt als gut, zwischen 2,5 und 4 Sekunden als verbesserungswürdig, über 4 Sekunden als schlecht. CLS unter 0,1 ist gut, über 0,25 ist schlecht. INP unter 200 Millisekunden ist gut, über 500 Millisekunden ist schlecht. Der Effekt ist auch ohne direkten Rankingeinfluss spürbar: Studien von Google zeigen, dass jede zusätzliche Sekunde Ladezeit die Absprungrate um 32 Prozent erhöht, bei mobilen Nutzern noch stärker. Wer in Google Ads investiert und eine langsame Landingpage hat, zahlt für Besucher, die sofort wieder abspringen.

Die häufigsten Performance-Killer bei Mittelstandswebsites

• Unoptimierte Bilder: keine WebP-Konvertierung, keine Komprimierung, keine Größenanpassung an die Darstellungsgröße
• Kein Lazy Loading: alle Bilder werden sofort geladen, auch die unterhalb des sichtbaren Bereichs
• Zu viele externe Skripte: Analytics, Marketing-Pixel, Chat-Widgets, Fonts vom Google-CDN — jedes ein DNS-Lookup
• Page-Builder-Bloat: Elementor, Divi oder WPBakery laden CSS und JS auch auf Seiten, die sie nicht benötigen
• Kein Caching: jede Anfrage wird neu vom Server berechnet statt aus dem Cache ausgeliefert
• Kein CDN: Nutzer weit vom Server entfernt haben lange Ladezeiten durch physische Distanz
• Render-Blocking-Ressourcen: CSS und JS im Head laden synchron und blockieren das Rendern der Seite
• Überlastetes Shared Hosting: zu viele Websites auf einem Server führen zu langsamen Serverantwortzeiten

Performance systematisch verbessern: Schritt für Schritt

1. Ist-Zustand messen und dokumentieren: Google PageSpeed Insights gibt Scores für Mobile und Desktop mit konkreten Verbesserungshinweisen. GTmetrix und WebPageTest liefern detailliertere Wasserfall-Analysen. LCP, CLS und INP separat dokumentieren und als Baseline festhalten. 2. Bilder in WebP oder AVIF konvertieren und komprimieren: WebP-Bilder sind im Schnitt 30 Prozent kleiner als JPEG bei gleicher Qualität. Bilder auf die tatsächliche Darstellungsgröße skalieren, Lazy Loading unterhalb des ersten sichtbaren Bereichs aktivieren. 3. Externe Skripte reduzieren und verzögern: Google Fonts lokal hosten, Analytics-Skripte auf tatsächlichen Nutzen prüfen, Chat-Widgets nur auf benötigten Seiten laden, nicht-kritische Skripte mit defer oder async laden. Ziel: maximal drei externe Domains im kritischen Ladepfad. 4. Caching auf Server- und Browser-Ebene aktivieren: serverseitiges Caching reduziert die Serverbelastung und verkürzt die Time-to-First-Byte, Browser-Caching stellt sicher, dass wiederkehrende Besucher statische Ressourcen aus dem lokalen Cache laden. 5. CDN einbinden für geografische Verteilung: für deutsche Websites mit hauptsächlich deutschen Nutzern begrenzt wirksam, für internationale Reichweite essenziell. 6. Hosting-Qualität überprüfen und upgraden: Shared Hosting auf günstigen Paketen ist oft der größte einzelne Performance-Flaschenhals. PHP 8.3 statt älterer Versionen bringt signifikante Verbesserungen, OPcache ist bei vielen Hostern kein Standard, aber ein einfacher Gewinn.

Bilder sind fast immer der größte Hebel

In über 80 Prozent der analysierten Mittelstandswebsites sind unoptimierte Bilder der größte Performance-Faktor. Ein Bild, das als JPEG 2 MB groß ist und in WebP 200 KB groß wäre, verlängert die Ladezeit um mehrere Sekunden, auf mobilen Verbindungen noch deutlich mehr. Lösbar mit einfachen Tools: Squoosh.app im Browser, TinyPNG für Batch-Optimierung, oder automatisch über das CMS.

CLS und INP: die unterschätzten Metriken

Während LCP intuitiv verständlich ist, werden CLS und INP oft unterschätzt. CLS beschreibt springende Seiteninhalte: Ein Nutzer klickt auf einen Link, in dem Moment lädt eine Anzeige und schiebt alles nach unten — der Klick trifft ein anderes Element. Häufige Ursachen: Bilder ohne definierte Höhen- und Breitenangaben, eingebettete Videos oder Karten ohne reservierten Container, Webfonts, die beim Laden vom System-Fallback auf den Webfont wechseln, und dynamisch nachgeladene Inhalte wie Cookie-Banner oder Newsletter-Pop-ups.

INP misst, wie schnell die Seite auf Klicks, Tippaktionen oder Scrollevents reagiert. Eine Seite kann schnell laden und trotzdem bei INP schlecht abschneiden, wenn JavaScript-intensive Prozesse den Haupt-Thread blockieren — typisch bei Page-Buildern mit umfangreichen Event-Listenern. Die Google Search Console zeigt unter "Core Web Vitals" die tatsächlichen Werte aus echten Nutzerdaten, das ist realistischer als Lighthouse-Labor-Scores und sollte die Basis jeder Optimierungsentscheidung sein.

Page-Builder sind oft der größte Performance-Blocker

Elementor, Divi und WPBakery vereinfachen die visuelle Bearbeitung, laden aber auf jeder Seite hunderte Kilobyte CSS und JavaScript — auch auf Seiten mit einfachem Text. Ein realer Vergleich: Eine handgecodete WordPress-Seite mit identischem Design lädt in 0,8 Sekunden, dieselbe Seite mit Elementor in 3,2 Sekunden, ohne weitere Optimierung. Wer PageSpeed-Scores über 90 erreichen will und gleichzeitig einen vollwertigen Page-Builder einsetzt, steht vor einem strukturellen Widerspruch, der sich nur begrenzt durch Caching kompensieren lässt.