PageSpeed Insights + Core Web Vitals: Praxis-Guide für Tester

Du hast deine Website durch Google PageSpeed Insights geschickt und einen Score zwischen 30 und 70 bekommen. Jetzt steht die Frage im Raum: ist das schlimm, und falls ja, wo fangen wir an. Die Empfehlungslisten sind lang, die Begriffe wie LCP, INP und CLS klingen technisch, und ein konkreter Plan fehlt.

Dieser Guide zeigt, was PageSpeed Insights wirklich misst, wie du die Core Web Vitals interpretierst und welche Optimierungen tatsächlich Wirkung haben. Geschrieben aus Sicht von Performance-Tests in Kundenprojekten, mit Code-Beispielen für die CI/CD-Pipeline und einer ehrlichen Einordnung wann der Score etwas bedeutet und wann nicht.

Wenn du Performance Testing (ISTQB-Begriff: Performanztest) ernst nimmst, gehört Frontend-Performance dazu. PageSpeed Insights ist dabei dein synthetischer Lab-Check vor dem Deploy, kein Ersatz für echten Lasttest.

Was ist Google PageSpeed Insights?

PageSpeed Insights (PSI) ist Googles kostenloses Web-Tool zur Performance-Analyse einer einzelnen URL. Du gibst eine Adresse ein, das Tool misst und liefert zwei Arten von Daten:

• Lab-Daten aus einem synthetischen Lighthouse-Test in einer kontrollierten Umgebung (gedrosselte Verbindung, definiertes Gerät). Reproduzierbar, aber nicht aus echtem Nutzerverhalten.
• Field-Daten aus dem Chrome User Experience Report (CrUX): aggregierte Messwerte echter Chrome-Nutzer der letzten 28 Tage. Nur verfügbar wenn deine Seite genug Traffic hat, und genau das was Google für das Ranking bewertet.

Die Trennung zwischen Lab und Field ist der wichtigste Punkt für eine seriöse Interpretation. Eine grüne Lab-Messung mit rotem Field bedeutet: dein Tool ist schnell, aber deine Nutzer erleben das nicht so. Das passiert oft bei Sites mit dynamischen User-Cohorten oder schlechtem Mobilfunk-Empfang in deren Zielregion.

Für kontinuierliches Real-User-Monitoring abseits von PSI ist Application Performance Monitoring (APM) die ergänzende Lösung. PSI gibt dir 28-Tage-Aggregate aus CrUX, APM liefert Live-Daten pro Session.

Die drei Core Web Vitals: LCP, INP, CLS

Die Core Web Vitals sind die drei Metriken, die Google für das Ranking heranzieht. Seit März 2024 hat INP den älteren First Input Delay (FID) abgelöst. Aktueller Stand:

Damit eine Seite als Web-Vitals-konform gilt, müssen alle drei Werte im grünen Bereich liegen. Eine rote Metrik genügt, um die Seite als nicht bestanden zu klassifizieren.

LCP in der Praxis

LCP wird in 80 Prozent der Fälle durch ein einziges Element bestimmt: das Hero-Bild oder die größte Überschrift im sichtbaren Bereich. Typische Verstöße in Kundenprojekten:

• Hero-Bild im JPEG mit 2 MB statt 200 KB in AVIF oder WebP.
• Render-blockierendes CSS, das den ersten Paint um eine Sekunde verzögert.
• Hero-Bild wird über JavaScript nachgeladen statt direkt im HTML referenziert.
• Server-Antwortzeit (TTFB) über 600 ms, weil kein CDN aktiv ist.

INP in der Praxis

INP misst, wie lange der Browser nach einem Klick oder einer Tastatureingabe braucht, um die nächste Frame-Render-Aktualisierung zu liefern. Lange JavaScript-Tasks (Long Tasks > 50 ms) sind die Hauptursache für schlechte INP-Werte. Typische Treiber:

• Schwere Drittanbieter-Skripte (Tracking, Chat-Widgets, A/B-Test-Tools).
• Große JavaScript-Bundles ohne Code-Splitting.
• Synchrone Operationen auf großen DOM-Strukturen (Listen mit hunderten Einträgen ohne Virtualisierung).

CLS in der Praxis

CLS entsteht durch Elemente, die nachträglich Platz wegnehmen und den bereits gerenderten Inhalt verschieben. Die häufigsten Ursachen:

• Bilder ohne width und height oder ohne aspect-ratio-CSS.
• Web-Fonts ohne font-display: optional oder swap, die FOIT oder FOUT auslösen.
• Werbe-Container, deren Höhe erst nach dem Ad-Server-Call feststeht.
• Cookie-Banner oder Newsletter-Pop-ups, die nach dem ersten Paint erscheinen.

Lighthouse: die Engine hinter PageSpeed Insights

PSI ist im Kern ein Web-Frontend für Lighthouse, Googles Open-Source-Audit-Tool. Lighthouse läuft headless in Chrome, fährt definierte Test-Szenarien ab und produziert einen Bericht in vier bis fünf Kategorien (Performance, Accessibility, Best Practices, SEO, optional Progressive Web App).

Lighthouse gibt es in drei Varianten:

• PageSpeed Insights: Web-UI, einzelne URLs, kostenlos, nicht skriptbar.
• Chrome DevTools: Tab „Lighthouse", lokal ausführbar, gut für ad-hoc-Tests.
• Lighthouse CLI und Lighthouse CI: Node-basierte Tools für Automatisierung, perfekt für die CI/CD-Pipeline. Mehr dazu im Abschnitt zur Pipeline weiter unten.

Der Unterschied: PSI nutzt Google-Server in einer fixen Region und kann nur öffentlich erreichbare URLs testen. Lighthouse CLI testet auch localhost und Staging-Umgebungen mit eigenem Netzwerk-Throttling.

Weitere Metriken: FCP, TBT, Speed Index

Neben den Core Web Vitals zeigt PSI weitere Lab-Metriken. Sie zählen nicht direkt fürs Ranking, helfen aber bei der Diagnose:

Praktisch: TBT ist deine wichtigste Lab-Metrik wenn du INP optimieren willst. INP wird nur in Field-Daten gemessen, TBT im Lab. Eine niedrige TBT korreliert stark mit guter INP.

Score-Interpretation: warum 100/100 keine Geschäftsmetrik ist

PSI fasst die Lab-Metriken zu einem Performance-Score von 0 bis 100 zusammen. Die Bewertung:

• 90 bis 100: gut. Grün im Tool, akzeptabel für die meisten Geschäftsmodelle.
• 50 bis 89: verbesserungswürdig. Orange im Tool.
• 0 bis 49: schlecht. Rot im Tool.

Hier kommt der unbequeme Teil: der Score allein ist keine Geschäftsmetrik. Eine 92er-Site mit 8 Prozent Conversion ist wertvoller als eine 100er-Site mit 0,5 Prozent. Was du dir aus dem Tool wirklich mitnehmen solltest:

1. Field-Daten zuerst. Wenn CrUX vorhanden ist, schau dort hin. Das ist was Google rankt und was deine Nutzer erleben.
2. Bestand alle drei Web Vitals? Wenn ja, ist der Lab-Score zweitrangig.
3. Welche Empfehlung hat den höchsten Estimated Savings? Konzentriere dich auf die Top drei, ignoriere die Long-Tail-Tipps.
4. Reproduziert sich die Messung? PSI variiert pro Run. Lass drei Messungen laufen, nimm den Median.

In Kundenprojekten sehen wir regelmäßig Sites, die einen 95er-Score haben aber bei echten Nutzern auf Smartphones mit 4G ein LCP von 5 Sekunden produzieren. Der Grund: Lighthouse simuliert Slow 4G und Moto G4, deine echten Nutzer haben aber 5G-iPhones in München und 3G-Android-Geräte in Vorarlberg. Beide werden vom Lab-Score nicht abgebildet.

Optimierungs-Hebel mit echter Wirkung

PSI listet oft 15 bis 25 Empfehlungen. Die Wahrheit: 4 Hebel bringen 80 Prozent der Verbesserung. In aufsteigender Reihenfolge nach Aufwand:

1. Bilder optimieren (höchster Hebel für LCP)

• Konvertiere Hero-Bilder zu AVIF oder WebP. AVIF bringt typischerweise 30 Prozent kleinere Dateien als WebP bei gleicher Qualität.
• Setze loading="lazy" auf alle Bilder unterhalb des Folds. Für das Hero-Bild aber Pflicht: fetchpriority="high" und ein <link rel="preload"> im Head.
• Liefere Bilder in der tatsächlich angezeigten Größe. Ein 4000px breites Bild auf 800px Anzeige skaliert verschwendet 75 Prozent der Bytes.
• Setze width und height als HTML-Attribute. Das verhindert CLS und ermöglicht dem Browser, Platz zu reservieren.

2. Render-blockierende Ressourcen entfernen

• CSS, das nur unterhalb des Folds gebraucht wird, asynchron laden (media="print" onload="this.media='all'").
• Critical CSS inline ins HTML einbetten, Rest extern laden.
• Drittanbieter-Skripte (Tracking, Chat) mit defer oder async versehen, wenn möglich erst nach dem ersten Interaktions-Event laden.

3. JavaScript-Bundle reduzieren (höchster Hebel für INP)

• Identifiziere die größten Bundles via Webpack Bundle Analyzer oder Vite Build-Stats.
• Code-Splitting nach Route oder Komponente.
• Tree-Shaking aktiv prüfen: importierst du eine ganze Library für eine Funktion?
• Lange JavaScript-Tasks (> 50 ms) mit scheduler.yield() oder requestIdleCallback aufbrechen.

4. CDN + Edge-Caching aufsetzen

• Statische Assets über CDN ausliefern (Cloudflare, BunnyCDN, Fastly).
• HTML mit kurzer TTL cachen (60 Sekunden bis 5 Minuten), Assets mit langer TTL plus Cache-Busting.
• HTTP/3 (QUIC) am Edge aktivieren, falls noch nicht Standard beim Provider.

Eine kompakte Übersicht der Tool-Landschaft für Performance Testing findest du in unserem Artikel zu Performance Testing Tools. Dort steht auch wann du PSI verlässt und auf echte Last-Werkzeuge umschaltest.

Web Vitals automatisiert messen: CI/CD-Pipeline

Manuelles Klicken in PSI vor jedem Deploy skaliert nicht. Drei Bausteine machen Performance-Messung zum festen CI-Schritt.

Lighthouse CI für Page-Level-Audits

Lighthouse CI fährt nach jedem Deploy automatisch Lighthouse-Audits gegen definierte URLs und vergleicht das Ergebnis mit einem Budget. Pull Request rot, wenn LCP über 2,5 s oder Performance-Score unter 90.

{
  "ci": {
    "collect": {
      "url": ["https://staging.example.de/", "https://staging.example.de/produkt"],
      "numberOfRuns": 3,
      "settings": {
        "preset": "desktop"
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["error", {"maxNumericValue": 200}]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Playwright für End-to-End-Web-Vitals-Messung

Lighthouse misst eine Page-Load. Realistische User-Journeys (Login, Suche, Checkout) brauchen E2E-Steuerung. Playwright kann mit der web-vitals-Library aus dem Browser-Kontext echte Vitals-Werte holen.

import { test, expect } from '@playwright/test';

test('Checkout-Flow erfüllt Core Web Vitals', async ({ page }) => {
  await page.goto('https://staging.example.de/checkout');

  const vitals = await page.evaluate(() => {
    return new Promise<Record<string, number>>((resolve) => {
      const result: Record<string, number> = {};
      // @ts-expect-error: web-vitals via CDN für Demo
      import('https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js').then(
        ({ onLCP, onCLS, onINP }) => {
          onLCP(({ value }) => (result.LCP = value));
          onCLS(({ value }) => (result.CLS = value));
          onINP(({ value }) => (result.INP = value));
          setTimeout(() => resolve(result), 5000);
        }
      );
    });
  });

  expect(vitals.LCP).toBeLessThan(2500);
  expect(vitals.CLS).toBeLessThan(0.1);
});

GitHub Actions als Gate

Den Lighthouse-CI-Run als Quality Gate vor dem Production-Deploy einbinden. Bei Verstoß bricht der Workflow ab.

name: performance-gate
on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - run: npx @lhci/cli@0.14.x autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Wer Web Vitals als Teil seiner DevOps-Strategie ernst nimmt, kombiniert das mit Backend-Performance-Tests im selben Workflow. Mehr dazu in Performance Testing in DevOps.

Frontend-Performance versus Backend-Lasttest: wann was?

Die häufigste Verwechslung in Teams: PageSpeed Insights wird mit „Performance-Test" gleichgesetzt. Das ist falsch. PSI ist ein synthetischer Single-User-Lab-Test. Was es nicht zeigt:

• Wie sich deine Seite unter 500 parallelen Nutzern verhält.
• Wann deine Datenbank zum Bottleneck wird.
• Wo dein API-Gateway throttelt.
• Wie Cache-Invalidierungen unter Last reagieren.

Für diese Fragen brauchst du echten Lasttest mit Tools wie k6, JMeter oder Gatling. Beide Disziplinen sind nicht austauschbar, sondern komplementär:

Praxis-Take: wir empfehlen Kunden beide Disziplinen als Teil derselben CI/CD-Pipeline zu fahren. Lighthouse CI für jeden Pull Request, Lasttest gegen Staging vor jedem Release-Cut. Wer nur eines macht, optimiert blind.

Fazit

PageSpeed Insights ist ein nützliches Diagnose-Werkzeug, kein Ranking-Hebel. Der Score allein ist keine Geschäftsmetrik. Was zählt sind die Core Web Vitals im Field, gemessen über CrUX oder Real-User-Monitoring, plus eine Performance-CI die jeden Pull Request gegen Lighthouse-Budgets prüft.

Frontend-Performance und Backend-Lasttest sind zwei getrennte Disziplinen mit zwei getrennten Tooling-Stacks. Wer PSI als „Performance-Test" begreift und auf Lasttest verzichtet, kauft sich ein falsches Sicherheitsgefühl. Wer nur Lasttest fährt und Frontend ignoriert, verliert User vor dem ersten Klick.

Wenn du beides systematisch in deine CI/CD-Pipeline einbauen willst, unterstützen wir dich bei der Performance-Engineering-Beratung: Tool-Auswahl, Pipeline-Integration, Performance-Budgets, Reporting. Vom ersten Lighthouse-CI-Lauf bis zum dauerhaften Quality Gate.

FAQ

Brauchen wir auf jeder Seite einen Score von 100/100?

Nein. Ein Score zwischen 90 und 100 ist gut genug, und der Sprung von 92 auf 100 kostet oft mehr als er bringt. Wichtiger: bestehe die Core Web Vitals (LCP, INP, CLS) im Field. Das ist was Google für das Ranking nutzt. Lab-Score ist Diagnose-Werkzeug, nicht Endziel.

Wie oft sollten wir PageSpeed Insights messen?

Manuell vor jedem Major Release plus vor jedem strukturellen Change am Frontend (neue Library, Theme-Update, Werbe-Integration). Automatisiert via Lighthouse CI bei jedem Pull Request. Im laufenden Betrieb ergänzend Real-User-Monitoring (RUM), idealerweise via APM, weil PSI nur 28-Tage-Aggregate liefert.

Was misst PageSpeed Insights nicht?

Verhalten unter Last, Server-Side-Verfügbarkeit, Backend-Reaktion auf parallele Requests, API-Latenzen bei vielen gleichzeitigen Clients, Datenbank-Locks, Memory-Leaks im Backend. Für all das brauchst du Lasttest plus Monitoring, nicht PSI.

PageSpeed Insights, Lighthouse, WebPageTest: was nehmen wir wann?

PSI für schnelle Public-URL-Checks ohne Setup. Lighthouse CI für skriptbare Audits in der CI/CD-Pipeline, auch gegen Staging. WebPageTest für tiefe Analyse mit Filmstrip-Vergleich, Multi-Step-Journeys und Tests aus verschiedenen geografischen Regionen. Die drei ergänzen sich, einer ersetzt nicht den anderen.

Was ist der Unterschied zwischen Lab- und Field-Daten?

Lab-Daten kommen aus einem synthetischen Lighthouse-Lauf in kontrollierter Umgebung. Reproduzierbar und gut für Regressions-Erkennung. Field-Daten kommen aus dem Chrome User Experience Report (CrUX): aggregierte Messungen echter Nutzer der letzten 28 Tage. Field ist was Google bewertet und was deine Nutzer erleben, Lab ist was du in der Pipeline messen kannst.