Langsame Websites kosten Kunden und Rankings gleichzeitig. Die Ursachen sind meist bekannt: unoptimierte Bilder, zu viele externe Skripte, Page-Builder-Bloat und fehlendes Caching. Die Loesungen sind technisch einfach - wenn man beim Aufbau von Anfang an auf Performance achtet.
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. Wer diese Werte nicht erreicht, verliert gegenüber schnelleren Wettbewerbern Rankingpositionen.
Der direkte Rankingeinfluss ist messbar, aber nicht der einzige Effekt. Langsame Websites haben höhere Absprungraten: Studien von Google zeigen, dass jede zusätzliche Sekunde Ladezeit die Absprungrate um 32 Prozent erhöht. Bei mobilen Nutzern ist der Effekt noch stärker. Wer in Google Ads investiert und eine langsame Landing-Page hat, zahlt für Besucher, die sofort wieder abspringen.
INREMA misst Core Web Vitals bei jedem Projekt-Start und nach jeder größeren Änderung. Die Ergebnisse werden dokumentiert und mit konkreten Maßnahmen verbunden — nicht als abstrakte Kennzahl, sondern als Grundlage für Prioritätsentscheidungen.
Die häufigsten Performance-Killer bei Mittelstandswebsites
- Unoptimierte Bilder: Keine WebP-Konvertierung, keine Komprimierung, keine Größenanpassung an Darstellungsgröße
- Kein Lazy Loading: Alle Bilder werden sofort geladen, auch die unterhalb des sichtbaren Bereichs
- Externe Skripte zu viele: Google Analytics, Facebook Pixel, Chat-Widgets, Fonts vom Google-CDN — jedes ist ein DNS-Lookup
- Page-Builder-Bloat: Elementor, Divi, 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 wegen physischer Distanz
- Render-Blocking-Ressourcen: CSS und JS im Head laden synchron und blockieren das Rendern der Seite
- Shared Hosting überlastet: Zu viele Websites auf einem Server führen zu langsamen Serverantwortzeiten
Performance systematisch verbessern: Schritt für Schritt
-
Ist-Zustand messen und dokumentieren
Google PageSpeed Insights (kostenlos, pagespeed.web.dev) gibt Scores für Mobile und Desktop und listet konkrete Verbesserungshinweise mit geschätzter Zeiteinsparung. GTmetrix und WebPageTest bieten detailliertere Wasserfall-Analysen. Der Chrome-DevTools-Lighthouse-Tab ermöglicht lokale Messungen ohne Netzwerk-Einflüsse. Alle drei Werte — LCP, CLS, INP — separat dokumentieren und als Baseline festhalten.
-
Bilder in WebP/AVIF konvertieren und komprimieren
WebP-Bilder sind im Schnitt 30 Prozent kleiner als JPEG bei gleicher Qualität. AVIF ist noch effizienter, aber noch nicht vollständig kompatibel. Alle Bilder auf die tatsächliche Darstellungsgröße skalieren — ein 4000-Pixel-Bild in einer 400-Pixel-Spalte verschwendet 90 Prozent der Dateigröße. Lazy Loading für alle Bilder unterhalb des first viewport aktivieren. Tools: Squoosh (kostenlos, im Browser), TinyPNG (API verfügbar), oder automatisch über das CMS.
-
Externe Skripte reduzieren und verzögern
Jedes externe Skript ist ein DNS-Lookup, ein TCP-Handshake und ein potenzieller Single-Point-of-Failure. Google Fonts lokal hosten. Analytics-Skripte auf tatsächlichen Nutzen prüfen: Werden die Daten wirklich ausgewertet? Chat-Widgets nur auf Seiten laden, wo sie genutzt werden. Nicht-kritische Skripte mit defer oder async-Attribut laden. Ziel: maximal drei externe Domains aus dem kritischen Ladepfad.
-
Caching auf Server- und Browser-Ebene aktivieren
Server-seitiges Caching (Redis, Varnish, oder CMS-Caching-Plugins) reduziert die Serverbelastung drastisch und verkürzt die Time-to-First-Byte. Browser-Caching über Cache-Control-Header stellt sicher, dass wiederkehrende Besucher statische Ressourcen aus dem lokalen Cache laden. Bei WordPress: WP Rocket ist die zuverlässigste All-in-One-Lösung, W3 Total Cache als kostenlose Alternative.
-
CDN einbinden für geografische Verteilung
Ein Content Delivery Network speichert statische Ressourcen auf Servern weltweit und liefert sie vom nächstgelegenen Server aus. Für deutsche Websites mit hauptsächlich deutschen Nutzern ist der CDN-Effekt begrenzt — aber für internationale Reichweite essenziell. Cloudflare bietet einen kostenlosen Einstieg und zusätzlich DDoS-Schutz. Hetzner-Objekt-Storage als CDN für Asset-Hosting ist eine günstige Alternative.
-
Hosting-Qualität überprüfen und upgraden
Shared Hosting auf günstigen Paketen ist oft der größte einzelne Performance-Flaschenhals — besonders bei häufig ausgelasteten Servern. Ein VPS bei Hetzner (ab 4 Euro/Monat) schlägt die meisten Shared-Hosting-Pakete bei der Server-Antwortzeit (Time-to-First-Byte) deutlich. PHP 8.3 statt 7.x bringt signifikante Performance-Verbesserungen. OPcache aktivieren ist bei vielen Hostern nicht Standard, aber ein einfacher Gewinn.
Bilder sind fast immer der größte Hebel
INREMA-Grundsatz zur Website-Performance
Eine schnelle Website ist kein Luxus. Sie ist die Grundvoraussetzung dafür, dass Ihre Kunden überhaupt ankommen — und bleiben. Jede Sekunde Ladezeit kostet Umsatz.
Performance-Analyse anfragen
Wir messen Ihre Website-Geschwindigkeit mit PageSpeed Insights und GTmetrix, dokumentieren LCP, CLS und INP und zeigen konkret, wo die größten Hebel liegen.
Performance-Analyse anfragenCLS und INP: Die unterschätzten Metriken
Während LCP (Ladezeit des größten Inhaltselements) intuitiv verständlich ist, werden CLS und INP oft unterschätzt. CLS (Cumulative Layout Shift) beschreibt springende Seiteninhalte: Ein Nutzer klickt auf einen Link — und in dem Moment lädt eine Werbeanzeige und schiebt alles nach unten. Der Klick trifft ein anderes Element. Das ist frustrierend, und Google wertet es als schlechtes Nutzererlebnis.
Häufige CLS-Ursachen: Bilder ohne definierte Höhen- und Breitenangaben (der Browser reserviert keinen Platz, bis das Bild lädt). Eingebettete Inhalte wie YouTube-Videos oder Karten ohne reservierten Container. Webfonts, die beim Laden von System-Fallback-Font auf den Webfont wechseln (FOUT — Flash of Unstyled Text). Dynamisch nachgeladene Inhalte wie Cookie-Banner oder Newsletter-Pop-ups, die Inhalte verschieben.
INP (Interaction to Next Paint) 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. Page-Builder mit umfangreichen Event-Listenern und Analytics-Scripts mit vielen DOM-Operationen sind typische INP-Verursacher.
Die Messung von CLS und INP erfordert echte Nutzerdaten (Field Data) oder Labor-Simulationen. Google Search Console zeigt unter 'Core Web Vitals' die tatsächlichen Werte aus dem Chrome-Nutzerdaten-Pool — das ist realer als Lighthouse-Scores und sollte die Basis jeder Optimierungsentscheidung sein.
Performance-Tools: Was Sie kostenlos nutzen können
- Google PageSpeed Insights: Kostenfrei, zeigt CWV-Scores und konkrete Verbesserungshinweise
- Google Search Console: Echte Nutzerdaten für CWV aus Chrome User Experience Report
- GTmetrix: Detaillierte Wasserfall-Analyse, Videoaufnahme des Ladevorgangs, kostenloser Plan verfügbar
- WebPageTest.org: Fortgeschrittene Tests mit verschiedenen Geräten, Standorten und Verbindungstypen
- Chrome DevTools Lighthouse: Lokale Messungen, Performance, Accessibility und SEO in einem
- Squoosh.app: Kostenlose Bild-Optimierung im Browser, WebP/AVIF-Konvertierung mit Vorschau
- wave.webaim.org: Barrierefreiheitsprüfung die auch Performance-Probleme durch redundanten Code aufdeckt
- Cloudflare Speed Test: Zeigt Netzwerklatenz und TTFB ohne Plugin-Overhead
Page-Builder sind oft der größte Performance-Blocker
Das Wichtigste zu Core Web Vitals
- LCP unter 2,5s, CLS unter 0,1, INP unter 200ms sind die Google-Zielwerte für gutes Ranking
- Unoptimierte Bilder sind in 80 % der Mittelstandswebsites der größte einzelne Performance-Faktor
- Google Search Console zeigt echte Nutzerdaten — zuverlässiger als Lighthouse-Lab-Scores
Quick-Win: Diese drei Maßnahmen bringen sofort Ergebnisse
Häufige Fragen
Wie messe ich die Core Web Vitals meiner Website?
Wie stark beeinflusst die Ladegeschwindigkeit das Google-Ranking?
Was ist der Unterschied zwischen LCP und TTFB?
Welchen Core-Web-Vitals-Score sollte ich anstreben?
War dieser Artikel hilfreich?