Häufige Fragen zu PageSpeed

Ein PageSpeed-Test misst objektiv, wie schnell eine Webseite lädt. Wichtige Metriken sind Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Diese werden zusammengefasst zu einem Score von 0 bis 100 (Lighthouse) oder als Field-Data im Chrome User Experience Report ausgewiesen.

Drei Gründe. Erstens: Google nutzt Core Web Vitals als Ranking-Signal seit Juni 2021. Zweitens: schnelle Seiten haben höhere Conversion-Raten (Amazon hat berechnet: 100 ms Verzögerung = 1 % Umsatzverlust). Drittens: Nutzer auf Mobilgeräten brechen ab, wenn die Seite nach 3 s nicht nutzbar ist.

Drei Metriken, die Google als Ranking-Signal nutzt: LCP (wann das größte Element gerendert ist, Ziel ≤ 2,5 s), INP (Verzögerung zwischen Eingabe und Antwort, Ziel ≤ 200 ms), und CLS (unerwartete Layout-Verschiebungen, Ziel ≤ 0,1). Seit März 2024 ersetzt INP die alte Metrik FID.

Lab-Daten kommen aus einem einzelnen Test in einer kontrollierten Umgebung (z.B. Lighthouse). Field-Daten kommen aus echten Nutzungssessions über 28 Tage (CrUX, Google Search Console). Lab dient zum Iterieren, Field bestimmt das Ranking. Eine Seite kann Lab-grün und Field-rot sein - oder umgekehrt.

Lighthouse ist das Audit-Tool selbst, integriert in Chrome DevTools und als CLI/CI-Tool nutzbar. PageSpeed Insights ist Googles gehostete Variante, die zusätzlich CrUX-Field-Daten anzeigt. Beide nutzen das gleiche Engine, aber Insights kombiniert Lab und Field in einer Übersicht.

Mindestens vor jedem größeren Deploy. Bei aktiven Sites täglich automatisiert über Lighthouse-CI oder Service wie SpeedCurve, Calibre, DebugBear. Bei langsamen Iterationen reicht wöchentlich. CrUX-Daten zeigen den Trend über 28 Tage.

Lighthouse (in Chrome DevTools), PageSpeed Insights (web), WebPageTest (Free-Tier), Chrome User Experience Report (CrUX). Bezahltools wie SpeedCurve, Calibre, DebugBear bieten dauerhaftes Monitoring, RUM und Charts über Zeit.

In dieser Reihenfolge: 1) TTFB prüfen (langsames Hosting? CDN aktivieren), 2) Hero-Bild preloaden mit fetchpriority="high", 3) Hero-Bild als AVIF/WebP mit korrekten width/height, 4) Critical CSS inline, restliches CSS async, 5) Render-blocking JS via defer/async, 6) Webfonts mit font-display: swap.

INP wird fast immer von langen JavaScript-Tasks im Hauptthread blockiert. Hebel: schwere Komponenten lazy laden (React.lazy + Suspense), Third-Party-Scripts asynchron, CPU-intensive Aufgaben in Web Workers, Filter-Operationen debouncen, scheduler.yield() für Aufteilung langer Tasks.

Goldene Regel: jedes <img> bekommt width und height. Mit CSS aspect-ratio bleibt es trotzdem responsiv. Werbe-Banner und Embeds bekommen feste min-height per CSS. Webfonts mit font-display: swap nutzen, idealerweise mit fallback-Font ähnlicher Zeichenbreite. Dynamische Insertions oberhalb des Folds vermeiden.

Bei internationalem Traffic oder vielen statischen Assets immer. Bei rein deutschem Traffic auf modernen Hostern (Vercel, Netlify, Cloudflare Pages) bringt zusätzliches CDN wenig - die haben Edge-Caching schon eingebaut. Cloudflare Free ist als Default empfehlenswert: kostenlos, einfach, deckt 90 % der Use-Cases ab.

Ziel für moderne Sites: Initial-JS unter 100 KB (komprimiert). Statische Sites mit Astro/Hugo/11ty kommen oft auf < 20 KB. Klassische React-Apps ohne Code-Splitting landen schnell bei 300-500 KB - das blockiert INP auf Mobile massiv. Bundle-Analyzer regelmäßig laufen lassen.

Ja, aber als Tie-Breaker, nicht als Hauptfaktor. Wenn zwei Seiten inhaltlich vergleichbar sind, gewinnt die schnellere. Bei deutlich besseren Inhalten kann eine langsame Seite trotzdem ranken. Wichtiger als Ranking-Effekt: schnelle Seiten haben höhere Conversions und niedrigere Bounces.

LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Diese Werte müssen vom 75. Perzentil aller User-Messungen erreicht werden (nicht vom Durchschnitt). Anders gesagt: drei von vier Besuchern müssen unter den Schwellwerten liegen, damit Google die URL als "Good" wertet.

Lighthouse Mobile rechnet mit 4× CPU-Slowdown und Slow 4G - simuliert ein Mid-Range-Android auf schlechter Verbindung. Desktop hat keine Throttling, daher höhere Scores. Wichtig: die Mobile-Bewertung ist die ranking-relevante (Mobile-First-Indexing seit 2019).

Für statische Sites: Vercel, Netlify, Cloudflare Pages - alle drei haben sehr niedrige TTFB (50-150 ms typisch) durch Edge-Caching. Für klassische CMS (WordPress, etc.): managed Hoster wie Kinsta, WP Engine, Cloudways. Shared Hosting auf 1blu, Strato, etc. ist für Performance-Sites typischerweise zu langsam.

Bedingt. Der größte Sprung liegt zwischen Shared-Hosting (~500-1500 ms TTFB) und modernem Static-Hosting/CDN (~50-200 ms TTFB). Innerhalb der Static-Tier-Anbieter (Vercel vs Netlify vs Cloudflare) unterscheiden sich die Performance-Werte kaum - wichtiger sind Workflow-Features und Preisstruktur.