Website-Geschwindigkeit und SEO: Wie Ladezeiten deine Rankings beeinflussen
Core Web Vitals, PageSpeed und Ladezeiten als SEO-Rankingfaktor. Konkrete Tipps um deine Website schneller zu machen.
Deine Website ist inhaltlich stark, die Keywords stimmen, aber die Rankings stagnieren. Ein haeufig uebersehener Grund: Ladezeiten. Seit Google Page Speed als offiziellen Rankingfaktor eingefuehrt hat und seit den Core Web Vitals als Ranking-Signal ein Teil des Page Experience Updates wurden, ist Website-Geschwindigkeit kein nettes Extra mehr. Sie ist ein harter Wettbewerbsfaktor.
Dieser Artikel zeigt dir was Google wirklich misst, welche Stellschrauben den groessten Einfluss haben, und wie du konkret deine Website schneller machst.
Warum Geschwindigkeit ein Rankingfaktor ist
Google hat Geschwindigkeit aus einem simplen Grund als Rankingfaktor eingefuehrt: Nutzer verlassen langsame Websites. Und zwar schnell.
Zahlen die Google selbst veroffentlicht hat:
- Eine Verzoegerung von 1 Sekunde reduziert Conversions um bis zu 20%
- 53% der mobilen Nutzer verlassen eine Seite, wenn sie laenger als 3 Sekunden braucht zu laden
- Seiten die in 1 Sekunde laden konvertieren 3x besser als Seiten die 5 Sekunden brauchen
Fuer Google ergibt sich daraus ein klares Qualitaetssignal: Schnelle Seiten liefern eine bessere User Experience. Seiten mit schlechter UX ranken schlechter, weil Nutzer signalisieren (durch Absprungraten, kurze Verweildauer), dass die Seite nicht relevant ist.
Core Web Vitals im Detail
Google hat drei spezifische Metriken als Core Web Vitals definiert. Sie messen verschiedene Aspekte der wahrgenommenen Ladegeschwindigkeit.
LCP, Largest Contentful Paint
LCP misst wie lange es dauert bis das groesste sichtbare Element der Seite geladen ist, meist ein Bild oder ein grosser Textblock.
Schwellenwerte:
- Gut: unter 2,5 Sekunden
- Verbesserung noetig: 2,5,4,0 Sekunden
- Schlecht: ueber 4,0 Sekunden
Haeufigste LCP-Killer: Grosse Hero-Bilder ohne Komprimierung, blockierendes JavaScript vor dem Render, langsame Server-Antwortzeiten.
INP, Interaction to Next Paint
INP hat seit 2024 FID (First Input Delay) als Core Web Vital abgeloest. Es misst die Reaktionszeit auf Nutzerinteraktionen, also wie schnell die Seite auf Klicks, Tippen oder andere Eingaben reagiert.
Schwellenwerte:
- Gut: unter 200 Millisekunden
- Verbesserung noetig: 200,500 Millisekunden
- Schlecht: ueber 500 Millisekunden
Haeufigste INP-Killer: Schweres JavaScript, Third-Party-Scripts (Chat-Widgets, Analytics, Cookie-Banner), lange Tasks die den Main Thread blockieren.
CLS, Cumulative Layout Shift
CLS misst wie stark sich die Seite waehrend des Ladens “verschiebt”, also ob Elemente springen und die Nutzung erschweren. Kennt jeder vom Handy: Man will auf einen Link klicken, und im letzten Moment springt ein Banner dazwischen.
Schwellenwerte:
- Gut: unter 0,1
- Verbesserung noetig: 0,1,0,25
- Schlecht: ueber 0,25
Haeufigste CLS-Killer: Bilder ohne definierte Dimensionen, eingebettete Ads oder Widgets die nachtraglich geladen werden, Web Fonts die spaet eingeblendet werden.
Messwerkzeuge fuer Core Web Vitals
- Google Search Console: Zeigt reale Nutzerdaten (Field Data) fuer deine gesamte Website. Erste Anlaufstelle
- PageSpeed Insights: Analysiert einzelne URLs mit Lab-Daten und Field Data
- GTmetrix: Detailliertere Wasserfall-Analyse, gut zum Debuggen
- WebPageTest: Die technischste Option, Filmstreifen-Analysen, Multi-Step-Tests, Vergleiche
Wichtig: Lab-Daten (synthetische Tests) und Field Data (echte Nutzer) koennen stark abweichen. Google nutzt fuer Rankings die Field Data aus dem Chrome User Experience Report (CrUX).
Die haeufigsten Speed-Killer
1. Unkomprimierte Bilder
Der mit Abstand haeufigste Speed-Killer auf normalen Unternehmenswebsites. Ein unkomprimiertes Hero-Foto mit 4 MB zerstoert jede Ladezeit.
Loesung: WebP oder AVIF statt JPEG/PNG. WebP ist im Schnitt 30% kleiner als JPEG bei gleicher Qualitaet. AVIF ist nochmal 20% kleiner, aber Browserunterstuetzung beachten.
2. Render-blockierendes JavaScript
JavaScript das im <head> ohne async oder defer eingebunden ist, blockiert den Browser-Render-Prozess komplett. Die Seite bleibt leer bis das Script geladen und ausgefuehrt ist.
Loesung: Alle nicht-kritischen Scripts mit defer oder async versehen. Third-Party-Scripts (Analytics, Chat, Fonts) so spaet wie moeglich laden.
3. Nicht-optimierte Web Fonts
Google Fonts und andere Web-Font-Anbieter verursachen oft 2,4 zusaetzliche HTTP-Requests und verzoegern den Text-Render. Ohne Font Display Optimierung erscheint der Text erst spaet, das senkt den LCP.
Loesung: font-display: swap nutzen. Fonts selbst hosten statt externe CDNs. Nur benoetigen Font-Weights laden.
4. Langsame Server-Antwortzeiten (TTFB)
Time to First Byte (TTFB) ist die Zeit bis der Browser das erste Byte vom Server erhaelt. Ein hoher TTFB (ueber 600ms) zerstoert jeden anderen Speed-Gewinn.
Ursachen: Schlechtes Hosting, kein Caching, schwere Server-seitige Berechnungen, kein CDN.
5. Zu viele HTTP-Requests
Jedes Bild, Script, Stylesheet und jede Schriftart ist ein eigener Request. 80+ Requests pro Seite sind keine Seltenheit bei schlecht optimierten Websites.
Loesung: Scripts zusammenfassen (Bundling), CSS reduzieren, unnoetige Plugins entfernen.
Konkrete Optimierungsschritte
Schritt 1: Bildoptimierung
Vorher: foto.jpg, 3.2 MB, 4000x3000px
Nachher: foto.webp, 280 KB, 1200x800px (80% kleiner!)- Alle Bilder auf Web-Ausspielungsgroesse skalieren (nicht groesser als 1600px Breite)
- Konvertierung zu WebP mit Tools wie Squoosh, ImageOptim oder automatisch per Build-Pipeline
<img>mitwidthundheightAttributen versehen (verhindert CLS)- Lazy Loading fuer Bilder unterhalb des Faltbereichs:
loading="lazy" - Hero-Bild mit
loading="eager"undfetchpriority="high"priorisieren
Schritt 2: Critical CSS
Nur das CSS laden das fuer den sichtbaren Bereich der Seite benoetigt wird (“above the fold”). Den Rest asynchron nachladen.
Tools: Critical (npm-Paket), Penthouse, oder manuelle Analyse mit Chrome DevTools Coverage-Tab.
Schritt 3: JavaScript-Optimierung
- Render-blockierende Scripts mit
deferversehen - Code Splitting nutzen (nur laden was die aktuelle Seite braucht)
- Unnoetige Plugins und Third-Party-Scripts entfernen
- Tree Shaking aktivieren (entfernt ungenutzten Code aus Bundles)
Schritt 4: Font-Optimierung
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>- Fonts als
woff2selbst hosten font-display: swapsetzen- Nur benoetigen Weights und Styles laden (kein “alle Weights” von Google Fonts)
- Font Subsetting: Nur genutzten Zeichensatz einbinden
Schritt 5: Server-Response-Zeit verbessern
- Caching einrichten: Browser-Caching fuer statische Assets (CSS, JS, Bilder) auf mindestens 1 Jahr setzen
- Server-seitiges Caching: Seiten als statische HTML-Dateien cachen statt dynamisch zu generieren
- GZIP/Brotli Komprimierung: Textbasierte Dateien (HTML, CSS, JS) komprimiert uebertragen
Schritt 6: CDN einsetzen
Ein Content Delivery Network liefert deine statischen Assets von einem Server in der Naehe des Nutzers. Fuer internationale Websites essentiell, auch fuer nationale Sites sehr sinnvoll.
Optionen: Cloudflare (kostenlos fuer Basic), BunnyCDN (guenstig), AWS CloudFront, Fastly.
Hosting-Vergleich fuer Speed
Die Wahl des Hosters hat massiven Einfluss auf TTFB und damit auf alle anderen Metriken.
| Hoster | TTFB (Durchschnitt) | Eignung |
|---|---|---|
| Shared Hosting (1&1, Strato) | 600,1200ms | Nicht empfehlenswert |
| Managed WordPress (Kinsta, WP Engine) | 150,300ms | WordPress-Seiten |
| Vercel / Netlify | 50,150ms | JAMstack, Astro, Next.js |
| Hetzner VPS (mit Nginx) | 100,200ms | Technisch versierte Teams |
| Cloudflare Pages | 30,100ms | Statische Sites |
Fazit: Modernes Static-Site-Hosting (Vercel, Netlify, Cloudflare Pages) schlaegt klassisches Webhosting in puncto Speed um Laengen.
Caching-Strategien
Browser Caching
Statische Assets sollten sehr lange gecacht werden (1 Jahr). Durch Cache Busting (Dateiname mit Hash) werden bei Aenderungen neue Versionen geladen.
Cache-Control: max-age=31536000, immutableServer-seitiges Caching
- Full Page Cache: Komplett gerenderte HTML-Seiten cachen (z.B. mit Redis oder Varnish)
- API-Caching: Backend-Daten cachen um Datenbankabfragen zu reduzieren
- Stale-while-revalidate: Gecachten Content sofort ausliefern und im Hintergrund aktualisieren
Tools fuer Speed-Analyse
- Google PageSpeed Insights (pagespeed.web.dev), Erster Check, zeigt Field Data wenn vorhanden
- Google Search Console → Core Web Vitals Bericht, Reale Nutzerdaten auf Seitenebene
- GTmetrix, Detaillierte Wasserfall-Diagramme, gut zum Identifizieren von Flaschenstoepfen
- WebPageTest, Filmstreifen-Ansicht, Vergleiche, Throttling-Optionen
- Chrome DevTools → Lighthouse Tab, Lokale Analyse mit konkreten Verbesserungshinweisen
Vorher/Nachher, Reale Optimierungsergebnisse
Ein typisches Szenario aus der Praxis: WordPress-Website eines lokalen Dienstleisters.
Vorher:
- LCP: 5,8 Sekunden
- CLS: 0,31
- INP: 480ms
- PageSpeed Score Mobile: 34/100
Optimierungen durchgefuehrt:
- Hero-Bild von 2,4 MB auf 180 KB (WebP) reduziert
- Google Fonts selbst gehostet
- Render-blockierendes JavaScript mit defer versehen
- Image-Dimensionen definiert (CLS behoben)
- Hosting von Shared zu Managed WordPress gewechselt
Nachher:
- LCP: 1,9 Sekunden
- CLS: 0,04
- INP: 140ms
- PageSpeed Score Mobile: 87/100
Ergebnis nach 3 Monaten: +23% organischer Traffic, Conversion Rate von 1,8% auf 3,1% gestiegen.
Checkliste: Website-Speed Optimierung
- PageSpeed Insights Score gemessen (Ziel: 90+ auf Desktop, 70+ auf Mobile)
- Core Web Vitals Status in Google Search Console geprueft
- Alle Bilder in WebP konvertiert und komprimiert
- Bilder mit width/height Attributen versehen
- Hero-Bild mit fetchpriority=“high” priorisiert
- Render-blockierendes JavaScript mit defer/async geladen
- Web Fonts selbst gehostet mit font-display: swap
- GZIP oder Brotli Komprimierung auf dem Server aktiv
- Browser-Caching fuer statische Assets konfiguriert
- CDN fuer statische Assets eingerichtet
- TTFB unter 600ms (Ziel: unter 200ms)
Haeufige Fragen zur Website-Geschwindigkeit
Wie stark beeinflusst Speed das Ranking wirklich? Google gibt an, dass Page Experience ein Tiebreaker-Signal ist, bei gleich relevantem Content gewinnt die schnellere Seite. In stark umkaempften Nischen kann es durchaus 2,5 Positionen ausmachen.
Mein PageSpeed Score ist 95, aber meine Rankings sind trotzdem schlecht, warum? Speed ist nur eines von ueber 200 Ranking-Signalen. Content-Relevanz, Backlinks und E-E-A-T sind weiterhin wichtiger. Speed allein rettet keine schwache Content-Strategie.
Wie oft sollte ich die Speed meiner Website messen? Nach jeder groesseren Aenderung (neues Plugin, Template-Update, neue Sektion) und mindestens einmal monatlich. Speed kann sich durch kleine Aenderungen stark verschlechtern.
Lohnt sich Speed-Optimierung fuer kleine Websites? Absolut. Gerade lokale Unternehmen mit begrenztem Budget koennen sich durch bessere UX und Speed von Konkurrenten abheben die das vernachlaessigen.
Willst du die technische Performance deiner Website verbessern? Scaleee hilft dir mit technischer SEO und Performance-Optimierung. Jetzt SEO-Leistungen entdecken oder direkt Kontakt aufnehmen.
Philipp Pötzinger
Performance Marketing Experte bei Scaleee
Ich helfe Unternehmen dabei, mit datengetriebenem Marketing mehr Leads und Umsatz zu generieren.
Mehr über mich →Weitere Artikel
E-Commerce SEO 2026: Onlineshops für Google optimieren
E-Commerce SEO Guide 2026: Wie du deinen Onlineshop technisch, inhaltlich und strukturell für Google optimierst und mehr organischen Traffic generierst.
Google Business Profil optimieren: Der komplette Guide 2026
Google Business Profil optimieren: So rankst du in der lokalen Suche, im Maps Pack und generierst mehr Anrufe und Kundenbesuche. Schritt-für-Schritt-Guide.
SEO-Audit durchführen: Die komplette Schritt-für-Schritt Anleitung 2026
SEO-Audit Anleitung 2026: Technisches SEO, OnPage, OffPage, Content systematisch prüfen. Mit Checkliste und den besten kostenlosen und kostenpflichtigen Tools.
Passende Services
Professionelle Unterstützung zu diesem Thema