Pagespeed und Ladezeit: Was Core Web Vitals wirklich bedeuten

Was ist Pagespeed?

53 % der mobilen Nutzer verlassen eine Webseite, wenn sie länger als drei Sekunden lädt — das ergab eine vielzitierte Google-Studie aus dem Jahr 2016. Seitdem hat Google die Messung von Seitengeschwindigkeit grundlegend verändert. Der Begriff "Pagespeed" meint heute etwas anderes als noch vor fünf Jahren.

Pagespeed beschreibt, wie schnell eine Webseite im Browser geladen und bedienbar wird. Der Begriff wird oft mit "Ladezeit" gleichgesetzt — technisch sind es unterschiedliche Dinge.

Ladezeit (Page Load Time) misst die Dauer vom ersten HTTP-Request bis zum vollständigen Laden aller Ressourcen. Das Problem: Eine Seite kann "fertig geladen" sein, ohne dass der Nutzer etwas sieht oder klicken kann.

Pagespeed betrachtet die wahrgenommene Geschwindigkeit aus Nutzersicht: Wann erscheint der erste sichtbare Inhalt? Wann reagiert die Seite auf Eingaben? Springt das Layout während des Ladens?

Drei Metriken bilden diesen Dreiklang — die sogenannten Core Web Vitals, die Google seit Juni 2021 als Ranking-Faktor in der Websuche verwendet:

• Largest Contentful Paint (LCP): Wann ist das größte sichtbare Element gerendert? Zielwert: unter 2,5 Sekunden.

• Interaction to Next Paint (INP): Wie schnell reagiert die Seite auf Klicks, Taps oder Tastatureingaben? Zielwert: unter 200 Millisekunden. INP hat im März 2024 die ältere Metrik First Input Delay (FID) abgelöst.

• Cumulative Layout Shift (CLS): Wie stark verschiebt sich das Layout während des Ladens? Zielwert: unter 0,1.

Daneben existiert der Time to First Byte (TTFB) — die Dauer bis der Server das erste Byte der Antwort liefert. TTFB ist kein Core Web Vital, beeinflusst aber alle drei Metriken, weil ein langsamer Server den gesamten Ladevorgang verzögert.

Google unterscheidet bei der Messung zwischen Lab Data (synthetische Tests unter kontrollierten Bedingungen, z. B. Lighthouse) und Field Data (echte Nutzerdaten aus dem Chrome User Experience Report). Lab Data identifiziert Probleme, Field Data priorisiert sie.

Warum Ladezeit Geld kostet

Der Zusammenhang zwischen Seitengeschwindigkeit und Geschäftsergebnis ist gut dokumentiert. Drei Studien stechen heraus:

Google/SOASTA (2017): Eine Analyse von 11 Millionen mobilen Landingpages zeigte, dass die Absprungrate um 32 % steigt, wenn die Ladezeit von einer auf drei Sekunden wächst. Bei fünf Sekunden sind es 90 %.

Deloitte/Google "Milliseconds Make Millions" (2020): Eine Verbesserung der mobilen Ladezeit um 0,1 Sekunden führte bei Retail-Websites zu 8,4 % mehr Conversions und 9,2 % höherem durchschnittlichen Bestellwert.

Portent (2022): Jede zusätzliche Sekunde Ladezeit zwischen 0 und 5 Sekunden senkt die Conversion-Rate um durchschnittlich 4,42 %.

Neben dem direkten Conversion-Effekt ist Pagespeed seit 2021 ein offizieller Google-Ranking-Faktor. Seiten mit schlechten Core Web Vitals können in den Suchergebnissen hinter technisch besser optimierten Wettbewerbern zurückfallen — unabhängig von der Inhaltsqualität. Google hat klargestellt, dass Pagespeed kein dominanter Faktor ist: bei gleichwertigen Inhalten gibt er den Ausschlag, ersetzt aber keine Relevanz.

Für den Nutzer summiert sich der Effekt: Eine langsame Seite verliert Besucher (höhere Absprungrate), konvertiert schlechter (weniger Anfragen, Käufe, Anmeldungen) und wird seltener gefunden (schlechteres Ranking). Die drei Effekte verstärken sich gegenseitig.

Core Web Vitals im Detail

Google hat die Core Web Vitals nicht willkürlich gewählt. Jede Metrik adressiert eine spezifische Dimension der Nutzererfahrung: visuelles Feedback, Reaktionsfähigkeit und visuelle Stabilität.

Largest Contentful Paint (LCP)

LCP misst, wann das größte sichtbare Element im Viewport fertig gerendert ist — typischerweise ein Hero-Bild, eine Überschrift oder ein Video-Poster. Der Nutzer interpretiert diesen Moment als "die Seite ist da".

Häufigste Ursachen für schlechten LCP: Render-blockierende Ressourcen (CSS, JavaScript), langsamer Server (hoher TTFB), nicht optimierte Bilder ohne explizite Dimensionen, und Client-Side Rendering ohne Server-Side Pre-Rendering.

Interaction to Next Paint (INP)

INP misst die Verzögerung zwischen einer Nutzerinteraktion (Klick, Tap, Tastendruck) und dem nächsten visuellen Update im Browser. Anders als der Vorgänger First Input Delay (FID), der nur die erste Interaktion erfasste, bewertet INP alle Interaktionen während des gesamten Seitenbesuchs und nimmt den schlechtesten Wert bei Percentile 98.

Häufigste Ursachen: Lang laufende JavaScript-Tasks die den Main Thread blockieren, Third-Party-Scripts (Analytics, Chat-Widgets, Ad-Tags), und aufwendige DOM-Manipulationen bei Klick-Events.

Cumulative Layout Shift (CLS)

CLS quantifiziert, wie stark sichtbare Elemente ihre Position während des Ladens verändern. Jeder Layoutsprung — ein Bild das nachlädt und Text nach unten schiebt, ein Banner das sich einfügt, eine Schriftart die spät wechselt — wird als Verschiebungsdistanz × betroffene Fläche berechnet und aufsummiert.

Häufigste Ursachen: Bilder und Videos ohne width/height-Attribute, Nachladen von Webfonts mit sichtbarem Layoutwechsel (FOUT), dynamisch eingefügte Elemente oberhalb des sichtbaren Bereichs, und Werbebanner ohne reservierten Platz.

Alle drei Schwellwerte beziehen sich auf das 75. Percentil der Field Data — das heißt, mindestens 75 % der Seitenaufrufe müssen den Zielwert einhalten, damit Google die Seite als "gut" einstuft.

Wie man Pagespeed misst

Es gibt nicht das eine Messwerkzeug. Jedes Tool beantwortet eine andere Frage.

Lab-Tools (synthetische Messung)

Lighthouse ist Googles Open-Source-Audit, integriert in Chrome DevTools und als CLI verfügbar. Es simuliert ein Mittelklasse-Smartphone auf einer gedrosselten Verbindung (Moto G Power, 4G-Throttling) und erzeugt einen Score von 0 bis 100. Lighthouse ist reproduzierbar, aber das Ergebnis spiegelt nicht die tatsächliche Nutzererfahrung wider — es zeigt, was unter standardisierten Laborbedingungen passiert.

WebPageTest erlaubt Messungen von verschiedenen Standorten und mit unterschiedlichen Verbindungsprofilen. Es liefert Wasserfall-Diagramme, Filmstrips und detaillierte Timings, die Lighthouse nicht bietet. Nützlich für Ursachenanalyse, weniger für Monitoring.

Field-Tools (echte Nutzerdaten)

Chrome User Experience Report (CrUX) sammelt anonymisierte Performance-Daten von Chrome-Nutzern, die der Datenerfassung zugestimmt haben. CrUX ist die Datengrundlage, auf der Google die Core Web Vitals für das Ranking bewertet. Die Daten werden monatlich aggregiert und sind über die CrUX API, BigQuery und PageSpeed Insights abrufbar.

PageSpeed Insights kombiniert beide Welten: oben die Field Data aus CrUX (falls für die URL verfügbar), unten ein aktueller Lighthouse-Lab-Test. Für Seiten mit wenig Traffic fehlen die Field-Daten — dann zeigt das Tool nur Lab-Ergebnisse.

Welches Tool wann?

Ein häufiger Fehler: Lighthouse-Scores isoliert zu optimieren, ohne die Field-Daten zu prüfen. Ein Score von 95 im Lab hilft wenig, wenn die echten Nutzer auf langsamen Geräten ein anderes Erlebnis haben. Lab Data identifiziert Probleme, Field Data priorisiert sie.

Optimierungstechniken mit messbarem Effekt

Die folgenden sechs Maßnahmen decken den Großteil der Pagespeed-Probleme ab, die in der Praxis auftreten. Jede Technik ist mit der Core-Web-Vital-Metrik verknüpft, die sie primär verbessert.

1. Render-blockierende Ressourcen eliminieren (LCP)

CSS und JavaScript im <head> blockieren das Rendering — der Browser wartet mit der Darstellung, bis diese Ressourcen geladen und verarbeitet sind. Gegenmaßnahmen: kritisches CSS inline einbetten, nicht-kritisches CSS mit media-Attributen verzögert laden, JavaScript mit defer oder async markieren.

Faustregel: Alles was der Nutzer above the fold nicht sofort sieht, darf später laden.

2. Bilder optimieren (LCP + CLS)

Bilder sind auf den meisten Webseiten die schwerste Ressource. Drei Hebel:

• Format: WebP oder AVIF statt JPEG/PNG. WebP spart typischerweise 25–35 % Dateigröße bei vergleichbarer Qualität, AVIF bis zu 50 %.

• Dimensionen: Bilder in der tatsächlich dargestellten Größe ausliefern, nicht in der Originalgröße. Ein 4000 × 3000 Pixel großes Bild in einem 800 Pixel breiten Container ist Verschwendung.

• Explizite width/height: Ohne diese Attribute reserviert der Browser keinen Platz — das Bild springt beim Laden ins Layout und verursacht CLS.

Das Hero-Bild — typischerweise das LCP-Element — sollte mit fetchpriority="high" und loading="eager" geladen werden. Alle Bilder unterhalb des sichtbaren Bereichs bekommen loading="lazy".

3. Server-Antwortzeit reduzieren (TTFB → LCP)

Bevor der Browser überhaupt mit dem Rendering beginnen kann, muss der Server antworten. Drei Ansätze:

• Caching: Statische Seiten als HTML cachen statt bei jedem Request neu zu generieren. Frameworks wie Next.js bieten Incremental Static Regeneration (ISR) — die Seite wird einmal generiert und in einem konfigurierbaren Intervall im Hintergrund aktualisiert.

• CDN: Content Delivery Networks liefern gecachte Inhalte vom nächstgelegenen Edge-Server aus. Die physische Distanz zwischen Nutzer und Server bestimmt die Latenz: ein Server in Frankfurt antwortet für deutsche Nutzer 40–80 ms schneller als einer in Virginia.

• Datenbankabfragen: Langsame Queries am Server verzögern die Antwort. Indizes, Query-Optimierung und Connection Pooling sind die üblichen Stellschrauben.

4. JavaScript-Last reduzieren (INP + LCP)

Jedes Kilobyte JavaScript muss heruntergeladen, geparst, kompiliert und ausgeführt werden. Auf einem Mittelklasse-Smartphone dauert das Parsen von 200 KB JavaScript etwa 1–2 Sekunden. Techniken:

• Code Splitting: Nur den JavaScript-Code laden, den die aktuelle Seite braucht. Moderne Bundler und Frameworks (Webpack, Next.js, Vite) unterstützen das automatisch.

• Dynamic Import: Schwere Bibliotheken erst laden, wenn sie gebraucht werden — etwa eine Kartenkomponente erst beim Scrollen zur Karten-Sektion.

• Third-Party-Scripts aufschieben: Analytics, Chat-Widgets und Social-Media-Embeds nach dem initialen Seitenaufbau laden. Ein einzelnes Third-Party-Script kann den Main Thread für mehrere hundert Millisekunden blockieren.

5. Layout-Stabilität sichern (CLS)

Jedes Element, das seine Größe nach dem initialen Rendering ändert, verursacht einen Layoutsprung. Vermeidungsstrategien:

• Medien mit Dimensionen: Alle <img>, <video> und <iframe> Elemente mit expliziten width und height Attributen oder per CSS aspect-ratio versehen.

• Schriftarten: font-display: swap verhindert unsichtbaren Text, kann aber einen Layoutsprung beim Fontwechsel verursachen. font-display: optional vermeidet den Sprung, zeigt aber bei langsamer Verbindung die Fallback-Schrift.

• Dynamische Inhalte: Für Werbebanner, Cookie-Banner oder Benachrichtigungsleisten festen Platz im Layout reservieren, bevor sie laden.

6. Below-the-Fold-Inhalte verzögert laden (LCP + INP)

Inhalte die der Nutzer erst nach dem Scrollen sieht, müssen nicht beim initialen Seitenaufbau bereitstehen. Zwei Ansätze:

• Lazy Loading von Komponenten: UI-Sektionen unterhalb des sichtbaren Bereichs erst laden, wenn der Nutzer sich ihnen nähert. Das reduziert die initiale JavaScript-Menge und entlastet den Main Thread.

• content-visibility: auto (CSS): Weist den Browser an, das Rendering von Off-Screen-Elementen aufzuschieben. Der Browser reserviert geschätzten Platz, rendert aber erst bei Annäherung. Spart Rendering-Zeit ohne JavaScript.

Fallstudie: Lighthouse 60 → 95 an einem konkreten Beispiel

Die folgende Optimierung wurde im Mai 2026 an einer Production-Website durchgeführt. Die Ausgangslage: eine Landing Page mit aufwendiger Hero-Animation, mehreren interaktiven Sektionen und Drittanbieter-Integrationen (Cloudflare Turnstile, Google Analytics). Der Lighthouse-Mobile-Score lag bei 60.

Ausgangslage

Hauptproblem: Die Hero-Sektion enthielt eine Canvas-basierte Animation mit 1.129 Zeilen JavaScript, 60-fps-Rendering, SVG-Pfadberechnungen und einem backdrop-filter: blur(40px). Allein diese Komponente blockierte das Rendering für mehrere Sekunden.

Durchgeführte Maßnahmen

1. Hero-Animation: Canvas durch Video ersetzt

Die 1.129-Zeilen-Komponente wurde durch ein vorab gerendertes Video ersetzt (H.264 Baseline, 356 KB Desktop / 134 KB Mobile). Das Video lädt mit preload="auto" und einem statischen Poster-Frame als Platzhalter. Effekt: LCP sank von 10,7 s auf unter 3 s.

2. Incremental Static Regeneration statt Server-Side Rendering

Die Landing Page wurde bei jedem Request serverseitig neu generiert (force-dynamic). Umstellung auf ISR mit 60-Sekunden-Revalidierung: Die Seite wird einmal generiert und aus dem Cache ausgeliefert, im Hintergrund alle 60 Sekunden aktualisiert. Effekt: TTFB halbiert.

3. Below-the-Fold-Sektionen verzögert geladen

Drei Sektionen unterhalb des sichtbaren Bereichs (Portal-Teaser, Website-Check, FAQ) wurden in eine Client-Komponente mit ssr: false extrahiert. Die zugehörigen JavaScript-Bundles laden erst beim Scrollen. Nebeneffekt: Cloudflare Turnstile und die dazugehörige Inter-Schriftart (3 × 47 KB) werden ebenfalls erst bei Bedarf geladen.

4. Turnstile-Widget verzögert initialisiert

Auf Seiten mit Formularen (Login, Registrierung) lud das Cloudflare-Turnstile-Script sofort beim Seitenaufbau. Umstellung auf Lazy-Init: Das Script lädt erst nach einer Nutzerinteraktion (Klick, Tastendruck) oder nach 2 Sekunden Idle-Zeit.

Ergebnis

Die größte Einzelmaßnahme (Canvas → Video) war für etwa 70 % der Verbesserung verantwortlich. ISR und Lazy Loading brachten die restlichen 30 %. Die Total Blocking Time schwankt zwischen Messungen (50–260 ms), weil Cloudflare-Challenge-Scripts nicht bei jedem Request geladen werden.

Alle vier Maßnahmen zusammen benötigten weniger als einen Arbeitstag.

Fazit

Pagespeed ist kein einzelner Wert, sondern ein Zusammenspiel aus Server-Geschwindigkeit, Ressourcen-Optimierung und Rendering-Strategie. Die Core Web Vitals liefern seit 2021 einen standardisierten Rahmen, um die Nutzererfahrung messbar zu machen.

Die meisten Pagespeed-Probleme lassen sich auf eine Handvoll Ursachen zurückführen: zu große Bilder, Render-blockierendes JavaScript, fehlende Caching-Strategien und unkontrollierte Third-Party-Scripts. Die Werkzeuge zur Diagnose sind kostenlos und gut dokumentiert.

Entscheidend ist die Unterscheidung zwischen Lab Data und Field Data. Ein guter Lighthouse-Score ist ein Indikator, aber kein Beweis — erst die Daten echter Nutzer zeigen, ob die Optimierung ankommt.

Quellen

[1] Google, Find out how you stack up to new industry benchmarks for mobile page speed, 2016.

[2] Google/SOASTA, Mobile Page Speed Benchmarks, 2017.

[3] Deloitte/Google, Milliseconds Make Millions, 2020.

[4] Portent, Site Speed is (Still) Impacting Your Conversion Rate, 2022.

[5] web.dev, Defining the Core Web Vitals metrics thresholds.

[6] web.dev, Interaction to Next Paint (INP).

[7] web.dev, Optimize Largest Contentful Paint.

[8] Google Developers, Chrome User Experience Report.

[9] HTTP Archive, Web Almanac 2024 – Performance.