Was PageSpeed Insights wirklich misst – Lab vs. Field
Google PageSpeed Insights zeigt zwei grundlegend verschiedene Datenkategorien an – und die meisten Website-Betreiber kennen nur eine davon.
Lab-Daten (Lighthouse) sind synthetische Tests: Lighthouse simuliert einen Seitenbesuch unter kontrollierten Bedingungen – definierte CPU, throttled Netzwerk, leerer Cache. Das Ergebnis ist der bekannte 0–100-Punktestand. Er ist nützlich für Diagnosen, hat aber einen entscheidenden Nachteil: Er misst keine echten Nutzer.
Field-Daten (CrUX) kommen aus dem Chrome User Experience Report – echte Messwerte von Chrome-Nutzern, die deine Website in den letzten 28 Tagen besucht haben. Diese Daten fließen in das Google-Ranking ein. Nicht der Score.
Die entscheidende Erkenntnis: Ein PageSpeed-Score von 95 bedeutet nicht automatisch gute Core Web Vitals im Feld. Und ein Score von 78 kann trotzdem zu einem „Gut"-Rating in allen drei Core Web Vitals führen. Für das Ranking zählt ausschließlich, was echte Nutzer erleben.
Die drei Core Web Vitals: LCP, INP und CLS erklärt
Core Web Vitals sind drei von Google als besonders nutzerrelevant eingestufte Performance-Metriken. Sie werden als Field-Daten gemessen – am 75. Perzentilwert: 75 % aller Seitenbesuche müssen im „Gut"-Bereich liegen, damit eine Seite als bestanden gilt.
| Metrik | Was wird gemessen | Gut | Verbesserung | Schlecht |
|---|---|---|---|---|
| LCP Largest Contentful Paint |
Ladezeit des größten sichtbaren Elements | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP Interaction to Next Paint |
Reaktionszeit auf alle Nutzerinteraktionen | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS Cumulative Layout Shift |
Visuelle Stabilität während des Ladens | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
| FCP First Contentful Paint |
Erstes sichtbares Element im Viewport | ≤ 1,8 s | 1,8 – 3 s | > 3 s |
| TTFB Time to First Byte |
Serverantwortzeit bis zum ersten Byte | ≤ 600 ms | 600 – 1.800 ms | > 1.800 ms |
LCP – Largest Contentful Paint
LCP misst, wie schnell das größte sichtbare Element einer Seite geladen wird – typischerweise das Hero-Bild, ein großes Textblock oder ein Video-Thumbnail. Es ist die Metrik, die am schwierigsten zu optimieren ist und bei der noch immer die meisten Websites im roten Bereich landen. Laut web.dev sind die häufigsten LCP-Kandidaten: Bilder (<img>, <picture>), CSS-Hintergrundbilder mit url() und Text-Elemente. Der LCP-Kandidat sollte nie lazy-loaded werden.
INP – Interaction to Next Paint (seit März 2024)
INP löste im März 2024 den alten FID-Wert (First Input Delay) als Core Web Vital ab. Der entscheidende Unterschied: FID maß nur die erste Interaktion eines Nutzers. INP erfasst alle Interaktionen während des gesamten Seitenbesuchs – Klicks, Tastatureingaben, Touch-Events – und bewertet die gesamte Input-to-Paint-Pipeline: Input Delay + Verarbeitungszeit + Presentation Delay. Schlechter INP ist fast immer ein JavaScript-Problem: zu viel Code auf dem Main Thread, lange Tasks, blockierende Event-Handler.
CLS – Cumulative Layout Shift
CLS misst unerwartete Layoutverschiebungen während des Ladens. Das nervige Phänomen kennt jeder: Man will auf einen Link klicken, plötzlich lädt ein Bild nach und der Button rutscht weg. CLS entsteht durch Bilder und Videos ohne deklarierte Abmessungen, dynamisch geladene Inhalte, spät geladene Schriften (FOUT) und Iframes ohne feste Größe. Die Lösung ist fast immer präventiv: Dimensionen im HTML angeben, bevor das Element gerendert wird.
PageSpeed als Ranking-Faktor – was stimmt wirklich?
Ja, Seitengeschwindigkeit ist ein bestätigter Google-Ranking-Faktor. Aber das Bild ist differenzierter als viele glauben. Seit 2018 fließt mobile Page Speed in den Google-Algorithmus ein, seit 2021 sind Core Web Vitals Teil des Page Experience Signals.
Was Google tatsächlich nutzt: die Core Web Vitals Field-Daten aus dem CrUX-Bericht – nicht den Lighthouse-Score. Und diese Daten wirken primär als Tiebreaker: Zwei Seiten mit vergleichbar gutem Inhalt zum selben Thema – die schnellere gewinnt. Eine langsame Seite mit deutlich besserem und relevanterem Inhalt kann trotzdem gut ranken.
Für die SEO-Praxis im Saarland: Bei vielen lokalen Suchbegriffen ist der inhaltliche Wettbewerb hoch, die technische Qualität aber oft niedrig. Eine performante Website gibt hier einen messbaren Vorteil – besonders auf Mobilgeräten, wo Google primär indexiert. Mehr zum Zusammenspiel von Technik und Sichtbarkeit im SEO-Leitfaden für das Saarland.
Bildoptimierung: WebP, AVIF und Lazy Loading
Bilder sind der größte einzelne Performancehebel. Sie machen typischerweise 40–60 % des gesamten Seitengewichts aus. Wer hier optimiert, gewinnt am meisten – und zwar mit vergleichsweise überschaubarem Aufwand.
Moderne Bildformate: WebP und AVIF
JPEG und PNG sind veraltet. Die modernen Alternativen liefern bei gleicher oder besserer visueller Qualität erheblich kleinere Dateien:
Bildformat-Vergleich (gleiche Qualität):
- WebP – 25–35 % kleiner als JPEG, 95 % Browser-Unterstützung, schnelle Encoding-Zeiten, ideal für allgemeine Verwendung
- AVIF – bis zu 75 % kleiner als JPEG, exzellente Qualität bei niedrigen Dateigrößen, 93 % Browser-Support, etwas langsameres Encoding
- SVG – für Logos, Icons und Illustrationen immer die erste Wahl: skalierbar, klein, kein Qualitätsverlust
Zielgrößen: Hero-Bilder unter 200 KB, Content-Bilder unter 100 KB. Ein 1920×1080 JPEG mit 500 KB wird als AVIF oft unter 100 KB.
Die technisch sauberste Implementierung nutzt das <picture>-Element mit progressivem Fallback – so bekommt jeder Browser das beste Format, das er versteht:
<picture>
<source srcset="bild.avif" type="image/avif">
<source srcset="bild.webp" type="image/webp">
<img src="bild.jpg" alt="Beschreibung" width="1200" height="675"
loading="lazy" decoding="async">
</picture>
Lazy Loading richtig einsetzen
Das HTML-Attribut loading="lazy" verzögert das Laden von Bildern außerhalb des sichtbaren Bereichs bis kurz vor dem Scrolleintritt – mit 94 % Browser-Unterstützung ohne JavaScript. Entscheidend: Das LCP-Bild darf niemals lazy-geladen werden. Es muss sofort laden. Das Hero-Bild bekommt stattdessen loading="eager" und fetchpriority="high".
<!-- LCP-Bild: NIEMALS lazy laden -->
<img src="hero.webp" loading="eager" fetchpriority="high"
width="1200" height="675" alt="...">
<!-- Alle anderen Bilder: lazy laden -->
<img src="content.webp" loading="lazy" decoding="async"
width="800" height="450" alt="...">
Immer width und height angeben – das ist Pflicht für einen guten CLS-Wert. Ohne diese Attribute weiß der Browser nicht, wie viel Platz er reservieren soll, und verschiebt beim Laden das Layout.
Fonts: Warum Google Fonts deinen Score kostet
Schriften sind ein überraschend großer Performancefaktor – und seit der Browser-Cache-Partitionierung 2020 nicht mehr teilbar zwischen Websites. Das bedeutet: Google Fonts lädt jeder Besucher neu herunter, egal wie viele andere Seiten dieselbe Schrift nutzen. Self-hosted Fonts sind 200–300 ms schneller als externe Google Fonts-Anfragen.
Die richtige Font-Loading-Strategie
/* 1. Fonts self-hosten und preloaden */
<link rel="preload" href="/fonts/myfont.woff2"
as="font" type="font/woff2" crossorigin>
/* 2. font-display: swap in der @font-face-Definition */
@font-face {
font-family: 'MyFont';
src: url('/fonts/myfont.woff2') format('woff2');
font-display: swap; /* Verhindert FOIT – zeigt Systemfont, bis Webfont lädt */
}
- WOFF2-Format verwenden – beste Komprimierung, 95 % Browser-Support
- font-display: swap – verhindert unsichtbaren Text (FOIT), zeigt Systemschrift als Fallback
- Fonts mit <link rel="preload"> vorausladen – reduziert FOUT und CLS
- Font-Subsetting – nur benötigte Zeichensätze einbinden, nicht den gesamten Unicode-Zeichenvorrat
- Maximal 2 Schriftfamilien pro Website – jede weitere Schrift kostet Zeit und Speicher
Wichtig für CLS: Wenn Systemfont und Webfont unterschiedlich groß sind, entsteht beim Swap ein Layout Shift. Die CSS-Properties size-adjust, ascent-override und descent-override in modernen Browsern können diesen Effekt minimieren.
JavaScript optimieren: defer, async und Long Tasks
JavaScript ist die häufigste Ursache für schlechten INP und hohen TBT (Total Blocking Time). Der Browser kann während der JavaScript-Ausführung keine Nutzerinteraktionen verarbeiten – jeder JavaScript-Block blockiert also potenziell die Reaktionsfähigkeit der Seite.
defer vs. async – der Unterschied
<!-- Standard: blockiert HTML-Parsing -->
<script src="script.js"></script>
<!-- async: lädt parallel, führt sofort nach Download aus -->
<script src="analytics.js" async></script>
<!-- defer: lädt parallel, führt nach HTML-Parsing aus (empfohlen) -->
<script src="app.js" defer></script>
Die Faustregel: defer für alle eigenen Skripte, die DOM-Zugriff brauchen. async für unabhängige Tracking-Skripte (Analytics, Hotjar), die keine bestimmte Reihenfolge benötigen. Kein Attribut nur noch für kritisches Inline-JavaScript.
Long Tasks vermeiden
Long Tasks sind JavaScript-Ausführungen, die länger als 50 Millisekunden dauern und den Main Thread blockieren. Sie sind der Hauptgrund für schlechten INP. Die Lösung: Große Funktionen in kleinere Tasks aufteilen und mit setTimeout(fn, 0) oder der Scheduler-API auf spätere Frames verschieben. Drittanbieter-Skripte (Chat-Widgets, Consent-Manager, Werbeskripte) sind besonders häufige Täter.
Gzip & Brotli: Komprimierung die wirklich etwas bringt
HTTP-Komprimierung reduziert die übertragene Datenmenge für Textressourcen (HTML, CSS, JavaScript) drastisch – ohne dass Entwickler Code ändern müssten. Es ist eine der einfachsten Optimierungen mit sofortigem Effekt.
Komprimierungsvergleich:
- Gzip – der bewährte Standard: reduziert typisch um 60–70 % für HTML/CSS/JS. Von praktisch jedem Server unterstützt.
- Brotli – Googles modernes Format: 15–25 % bessere Komprimierung als Gzip, wird von über 95 % der Browser unterstützt. Sollte heute immer aktiviert sein.
- Zstandard (zstd) – neuester Standard, noch begrenzte Server-Unterstützung, aber deutlich schnellere Komprimierung als Brotli bei ähnlicher Ratio.
Aktivierung via .htaccess auf Apache-Servern:
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/css
application/javascript application/json
text/xml image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css
application/javascript application/json
text/xml image/svg+xml
</IfModule>
Ob dein Server Gzip oder Brotli korrekt ausliefert, lässt sich sofort prüfen:
TTFB & Caching: Der Server als unsichtbare Bremse
Alle Frontend-Optimierungen nützen wenig, wenn der Server zu langsam antwortet. TTFB (Time to First Byte) unter 600 Millisekunden gilt als gut – alles darüber kostet wertvolle Millisekunden, bevor der Browser überhaupt anfangen kann, etwas zu rendern.
Was die TTFB erhöht
- Langsame Datenbankabfragen – besonders häufig bei WordPress mit vielen Plugins und unkonfigurierten Datenbanken
- Kein serverseitiges Caching – jede Anfrage generiert die Seite neu statt aus dem Cache zu liefern
- Großer geografischer Abstand zum Hosting-Server – ein deutsches Unternehmen auf einem US-Server zahlt immer Latenz-Schulden
- Shared Hosting ohne Ressourcenreservierung – Ressourcen konkurrieren mit anderen Website-Betreibern auf demselben Server
Browser-Caching richtig konfigurieren
Statische Ressourcen (CSS, JS, Bilder, Fonts) sollten aggressiv gecacht werden. Via .htaccess:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
WordPress-spezifische Performance-Optimierung
WordPress-Websites haben ihre eigenen Performance-Herausforderungen – und ihre eigenen Lösungen. Mit den richtigen Plugins und Einstellungen lassen sich 90+ Scores erreichen, ohne den Theme-Code anfassen zu müssen.
Das WordPress Performance-Stack 2026:
- Caching-Plugin – LiteSpeed Cache (auf LiteSpeed-Servern) oder WP Rocket/W3 Total Cache: Seiten-Caching, Objekt-Caching, Minification in einem
- Bildoptimierung – Imagify, ShortPixel oder Smush: automatische WebP/AVIF-Konvertierung und Komprimierung beim Upload
- CDN – Cloudflare (kostenlos, mit automatischer WebP-Konvertierung) oder BunnyCDN: Assets von geografisch nahem Server ausliefern
- Datenbankoptimierung – WP-Optimize: Revisionen bereinigen, transients löschen, Datenbanktabellen optimieren
- Plugin-Audit – Nicht genutzte Plugins löschen; jedes Plugin lädt PHP, CSS und JS – auch wenn es nicht aktiv gebraucht wird
Grundlage für jede WordPress-Performance-Optimierung ist eine saubere und sichere Installation. Veraltete Plugins sind nicht nur ein Sicherheitsrisiko, sondern oft auch Performance-Killer durch aufgeblähten Code. Der vollständige Überblick dazu im Leitfaden zur WordPress-Sicherheit.
Ebenfalls unverzichtbar: HTTPS. HTTP/2 und HTTP/3 – die Protokollversionen mit deutlichen Performance-Vorteilen durch Multiplexing und Header-Komprimierung – sind ausschließlich über verschlüsselte Verbindungen verfügbar. Die vollständige Anleitung zur HTTPS-Umstellung für WordPress zeigt den Weg Schritt für Schritt.
Messwerkzeuge im Überblick
PageSpeed Insights ist der Ausgangspunkt – aber nicht das einzige relevante Tool. Für eine vollständige Performance-Analyse braucht es verschiedene Perspektiven.
Die wichtigsten Performance-Tools:
- PageSpeed Insights – kombiniert Lighthouse-Lab-Daten und CrUX-Field-Daten in einer Ansicht. Erste Anlaufstelle für jede Diagnose.
- Chrome DevTools → Lighthouse – vollständige Lab-Tests direkt im Browser, mit detaillierten Empfehlungen für jede Metrik. Bietet auch Filmstrip-Ansicht des Ladevorgangs.
- WebPageTest – Tests auf echten Geräten mit paketgenauer Netzwerksimulation. Zeigt Waterfall-Diagramm, detaillierte Ressourcenanalyse und Vergleiche zwischen Läufen.
- Google Search Console → Core Web Vitals – zeigt aggregierte Field-Daten für alle Seiten der Domain, sortiert nach URL-Gruppen. Einzige Quelle für URL-spezifische CrUX-Daten.
- Treo Site Speed – historisches CrUX-Dashboard: wie haben sich die Core Web Vitals im Zeitverlauf entwickelt?
Wichtige Unterscheidung: Lighthouse-Scores variieren zwischen verschiedenen Runs – durch CPU-Last des Testrechners, Netzwerkschwankungen, Ad-Blocker. Immer mehrere Messungen machen und Durchschnittswerte betrachten. CrUX-Field-Daten dagegen sind stabil und zeigen echte Nutzererfahrungen.
Die häufigsten PageSpeed-Fehler
- LCP-Bild lazy-loaden – der häufigste Einzelfehler. Das wichtigste Bild der Seite verzögert sich selbst.
- Bilder ohne width und height – Browser kann keinen Platz reservieren → Layout Shift → schlechter CLS.
- Google Fonts extern laden – kostet 200–300 ms durch DNS-Lookup, TCP-Verbindung und TLS-Handshake zu Googles Server.
- font-display nicht gesetzt – führt zu FOIT: der Browser zeigt keine Texte bis die Webfont geladen ist.
- JavaScript blockierend laden – kein defer/async, kein Code-Splitting. Alles landet synchron im <head>.
- Uncompressed assets – kein Gzip, kein Brotli. Die HTML-, CSS- und JS-Dateien reisen unkomprimiert durch das Netz.
- Zu viele Drittanbieter-Skripte – jedes Widget, jeder Chat, jede Analytics-Integration kostet Render-Zeit und kann INP verschlechtern.
- Kein Browser-Caching – bei jedem Besuch werden dieselben Ressourcen neu heruntergeladen.
- Zu großes JavaScript-Bundle – kein Tree-Shaking, keine Code-Splitting, das komplette Framework lädt auf jeder Seite.
- Den Score anstatt die Nutzererfahrung optimieren – der gefährlichste Fehler. Man kann einen Score von 100 erzielen und trotzdem eine miserable Nutzererfahrung im echten Feld haben.
Häufige Fragen zur Google PageSpeed Optimierung
