Was ist PageSpeed Insights (PSI)?

Was ist PageSpeed Insights (PSI)?

PageSpeed Insights (PSI) ist Googles kostenloses Web-Performance-Analyse-Tool. Gib eine URL bei pagespeed.web.dev ein, und PSI liefert eine Performance-Scorecard zurück, die zwei verschiedene Datenquellen kombiniert: Lab-Daten (ein frischer synthetischer Lighthouse-Audit, durchgeführt aus einem Google-Rechenzentrum) und Field-Daten (Real-User-Metriken aus dem Chrome User Experience Report, der die letzten 28 Tage abdeckt). Das Tool surfaced dann spezifische, priorisierte Empfehlungen zur Verbesserung der Seitengeschwindigkeit.

PSI ist das meistzitierte Performance-Tool in SEO-Diskussionen aus einem Grund: Es ist das öffentliche Gesicht von Googles Core-Web-Vitals-Programm. Die Scores, die du in PSI siehst, mappen direkt auf die Signale, die Google fürs Ranking nutzt. "Hat sich PSI verbessert?" ist die Frage, die die meisten Performance-Debatten beendet.

Die zwei Hälften von PSI: Lab-Daten vs. Field-Daten

PSI zu verstehen, erfordert die zwei komplett verschiedenen Datentypen zu verstehen, die es zeigt. Sie beantworten verschiedene Fragen.

Field-Daten (CrUX) — "wie erleben echte Nutzer diese Seite?"

Der Chrome User Experience Report (CrUX) ist ein öffentlicher Datensatz anonymisierter Performance-Metriken, gesammelt von echten Chrome-Nutzern (denen, die für Browser-History-Sync opt-in gegeben haben). PSI zeigt die 75. Perzentil-Werte über die letzten 28 Tage für diese URL oder Origin.

Die vier CrUX-Metriken in PSI:

• LCP (Largest Contentful Paint) — wann das größte above-fold-Element rendert. Gut: ≤2,5s.
• INP (Interaction to Next Paint) — Reaktionsfähigkeit auf Nutzer-Input. Ersetzte FID im März 2024. Gut: ≤200ms.
• CLS (Cumulative Layout Shift) — visuelle Stabilität. Gut: ≤0,1.
• FCP (First Contentful Paint) und TTFB (Time to First Byte) — diagnostisch, nicht pass/fail.

Field-Daten sind, was Google fürs Core-Web-Vitals-Ranking-Signal nutzt. Wenn Field-Daten fehlen (Seite mit wenig Traffic), fällt Google auf Origin-Level-Daten zurück, dann gar kein Signal.

Lab-Daten (Lighthouse) — "wie schnell kann diese Seite unter idealen Bedingungen laden?"

Lab-Daten kommen von einem frischen Lighthouse-Audit auf einem simulierten Mobile- oder Desktop-Gerät mit gedrosseltem Netzwerk. Sie sind reproduzierbar (gleiche Bedingungen jeden Run) und diagnostisch (Lighthouse generiert eine Liste von Möglichkeiten).

Die Lab-Metriken in PSI:

• FCP, LCP, CLS — gleiche Metriken, aber unter Lab-Bedingungen gemessen.
• TBT (Total Blocking Time) — Proxy für INP. Zeit, in der der Main-Thread während des Page-Loads blockiert war.
• Speed Index — wie schnell sichtbarer Content während des Loads paint.
• Performance Score (0-100) — gewichteter Durchschnitt der Lab-Metriken.

Der PSI-Score: wie er berechnet wird

Der Performance-Score ist eine gewichtete Kombination der Lab-Metriken mit diesen Gewichtungen (Stand Lighthouse 10):

• LCP: 25%
• TBT: 30%
• CLS: 25%
• FCP: 10%
• Speed Index: 10%

Jede Metrik wird auf einen 0-100-Score gemappt, mit einer log-normalen Kurve, die gegen die Top-1000-Sites kalibriert ist. Eine 100 bedeutet "in der Top-Stufe schneller Seiten". Eine 50 bedeutet Median.

Google nennt 90+ "gut", 50-89 "verbesserungsbedürftig" und unter 50 "schlecht". Die meisten Produktions-Sites scoren 2026 50-80 mobile und 80-95 desktop. 90+ auf mobile zu treffen ist wirklich schwierig und erfordert bewusste Optimierung.

Mobile vs. Desktop-Scoring

PSI führt zwei Audits durch: einen mit simuliertem Slow-4G + Mid-Tier-Mobile-Gerät-Drosselung und einen mit simulierter Kabel-Geschwindigkeit-Desktop. Der Mobile-Score ist fast immer niedriger, weil das simulierte Gerät langsamer ist.

Googles Ranking-Signal nutzt Mobile-Field-Daten. Desktop-Scores sind nützlich zur Diagnose, beeinflussen aber nicht direkt SEO. Optimiere zuerst für die Mobile-Erfahrung.

Die Empfehlungs-Engine: Opportunities und Diagnostics

Unter den Scores surfaced PSI eine priorisierte Liste von Issues. Zwei Typen:

• Opportunities — quantifizierte Einsparungen, z.B. "Bilder richtig dimensionieren: geschätzte 1,2s Einsparungen." Das sind konkrete Dinge zum Fixen, die deinen Score verbessern sollten.
• Diagnostics — qualitative Befunde, z.B. "Vermeide eine exzessive DOM-Größe." Nützlicher Kontext, aber keine direkten Einsparungs-Schätzungen.

Die häufigsten Opportunities (in unserer Erfahrung beim Auditieren tausender Sites):

1. Bilder richtig dimensionieren (Bilder größer geliefert als angezeigt)
2. Off-Screen-Bilder verzögern (Below-Fold-Bilder eager geladen)
3. Render-blocking-Ressourcen eliminieren (CSS/JS im Head)
4. Ungenutztes JavaScript reduzieren (Bundle-Bloat)
5. Bilder in Next-Gen-Formaten ausliefern (kein WebP/AVIF)
6. Ungenutztes CSS reduzieren (über-geshipte Stylesheets)
7. CSS/JavaScript minifizieren (unkomprimierte Assets)
8. Text-Kompression aktivieren (kein gzip/brotli)
9. Preconnect zu erforderlichen Origins (kritische Drittanbieter-Domains)
10. Verkettung kritischer Requests vermeiden (Waterfall-Tiefe)

Häufige PSI-Score-Interpretations-Fehler

• Einen 100-Score jagen. Abnehmender Ertrag schlägt über 90 hart zu. 95→100 zu optimieren kostet oft mehr Dev-Zeit als 70→90 und bringt weniger Real-World-Nutzen.
• Jeden PSI-Run als autoritativ behandeln. PSI-Lab-Scores haben ±5-Punkte-Varianz von Run zu Run wegen Network-Simulations-Rauschen. Reagiere nicht auf eine einzelne Score-Änderung; schau auf Trends über mehrere Runs.
• Field-Daten ignorieren. Lab-Daten sagen dir, was möglich ist; Field-Daten sagen dir, was Nutzer tatsächlich erleben. Wenn dein Field-LCP schlecht ist, aber Lab-LCP gut, ist dein Problem geografische Verteilung, Real-Device-Varianz oder Drittanbieter-Skripte, die nicht in Lab-Bedingungen laden.
• Für den Score statt für die Erfahrung optimieren. Manche Optimierungen verbessern den Score, ohne Nutzern zu helfen (z.B. aggressives Code-Splitting, das Interaktionen langsamer macht). Validiere immer mit echten Nutzern (RUM-Daten) nach PSI-Änderungen.
• Den Ranking-Signal-Lag vergessen. CrUX-Daten sind ein 28-Tage-Rolling-Window. Wenn du heute eine Optimierung shippst, dauert es 4 Wochen, bis Field-Daten sie vollständig reflektieren.
• PSI mit anderen Tools ohne Normalisierung vergleichen. WebPageTest, GTmetrix und PSI nutzen verschiedene Drosselungsprofile. Die gleiche Seite kann 65 auf PSI-Mobile und 85 auf GTmetrix scoren. Die Zahlen sind nicht über Tools vergleichbar — wähle eines und bleib dabei.

PSI vs. Lighthouse vs. Chrome-DevTools-Performance

Drei verwandte Tools, verschiedene Use-Cases:

• PSI — öffentlich gerichtet, inklusive Field-Daten, einfach zu teilen. Am besten für Produkt/Exec-Audiences und schnelle Checks.
• Lighthouse (DevTools oder CLI) — läuft auf deiner lokalen Maschine, keine Field-Daten, schnellere Iteration. Am besten für aktive Optimierungs-Arbeit.
• Chrome-DevTools-Performance-Tab — Flame-Charts, JavaScript-Profiling, kein Scoring. Am besten für tiefe Root-Cause-Analyse.

PSI-Checks in CI automatisieren

Verlasse dich nicht auf manuelle PSI-Runs. Bessere Praxis: automatisiere Lighthouse-Audits in deiner CI-Pipeline (mit lighthouse-ci) und lasse den Build fehlschlagen, wenn Performance unter einen Schwellenwert regrediert. Das fängt Regressionen, bevor sie Production treffen. Die meisten reifen Web-Teams haben Lighthouse-CI-Gates für die Hauptseiten.

FAQ: PageSpeed Insights

Warum ist mein PSI-Score so niedrig?

Wahrscheinliche Übeltäter: Render-blocking-JavaScript im Head, unoptimierte Bilder, Layout-Shifts durch spät-ladenden Content und Drittanbieter-Skripte (Analytics, Ads, Chat-Widgets). PSIs Diagnostics werden diese für dich ranken. Fang oben an.

Beeinflusst der PSI-Score das SEO-Ranking?

Indirekt. Das Ranking-Signal sind Core Web Vitals, die Field- (CrUX-) Daten nutzen — nicht den PSI-Lab-Score. Ein hoher Lab-Score mit schlechten Field-Daten wird SEO nicht helfen. Eine perfekte Field-Daten-Bestehensrate mit mittelmäßigem Lab-Score ist okay.

Warum fluktuieren meine PSI-Scores?

Lab-Scores fluktuieren, weil Lighthouse simulierte Netzwerk-Drosselung nutzt, die Zufälligkeit hinzufügt. Führe 3-5 Audits durch und nutze den Median. Field-Daten fluktuieren wegen Änderungen im Nutzer-Geräte-Mix, geografischer Verteilung und Traffic-Patterns.

Warum ist Desktop-Score 90+, aber Mobile in den 50ern?

Mobile-Geräte sind dramatisch langsamer als Desktops, besonders auf simulierter Mid-Tier-Hardware mit Slow-4G-Drosselung. JavaScript-Ausführung ist 4-6x langsamer auf Mobile, Netzwerk ist gedrosselt, und Main-Thread-Engpässe haben mehr Impact. Mobile-First-Optimierung ist schwerer.

Wie verbessere ich PSI-Scores?

Top-drei-Aktionen für die meisten Sites: (1) Bilder optimieren — richtige Größe, WebP/AVIF-Format, Lazy-Loading below-fold; (2) JavaScript reduzieren — Code-Splitten, nicht-kritische Skripte deferren, ungenutzte Libraries eliminieren; (3) Render-Blocking eliminieren — kritisches CSS inlinen, JS deferr/async, Fonts preloaden. LoadFocus-Speed-Test zeigt die gleichen Diagnostics mit Multi-Location-Coverage.

Wie oft sollte ich PSI prüfen?

Für aktive Optimierungs-Arbeit, täglich. Für Monitoring ist monatlich okay — richte automatisierte Lighthouse-CI in deiner Build-Pipeline ein, sodass du dich nicht erinnern musst.

Wie LoadFocus PSI ergänzt

PSI testet eine URL aus einem Google-Rechenzentrum. LoadFocus-Website-Speed-Testing führt das gleiche Lighthouse-Audit aus 30+ Standorten weltweit durch und surfaced geografische Performance-Unterschiede, die PSI nicht sehen kann. Kontinuierliches Monitoring trackt Core Web Vitals über Zeit, sodass du Regressionen am Tag fängst, an dem sie passieren, nicht 4 Wochen später, wenn das Field-Daten-Signal ankommt.