Core Web Vitals optimieren: Web-Performance Guide

Schnelle Ladezeiten und eine reibungslose Nutzererfahrung sind längst kein Nice-to-have mehr – sie sind ein direkter Rankingfaktor. Google bewertet mit den Core Web Vitals drei zentrale Metriken, die über Sichtbarkeit und Conversion entscheiden. Wer seine Web-Performance nicht aktiv optimiert, verliert Nutzer und Rankings. Dieser Guide zeigt, wie du LCP, INP und CLS systematisch misst, analysierst und mit konkreten Maßnahmen gezielt verbesserst.

Was sind Core Web Vitals?

Core Web Vitals sind drei nutzerzentrierte Metriken, die Google seit 2021 als Rankingsignal heranzieht. Sie messen, wie schnell eine Seite lädt, wie reaktionsschnell sie auf Interaktionen reagiert und wie visuell stabil sie während des Ladevorgangs bleibt.

Die drei Metriken im Überblick

• LCP (Largest Contentful Paint): Misst, wann das größte sichtbare Element im Viewport vollständig gerendert ist. Zielwert: unter 2,5 Sekunden.
• INP (Interaction to Next Paint): Erfasst die Reaktionszeit auf Nutzerinteraktionen über den gesamten Seitenbesuch hinweg. Zielwert: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift): Bewertet unerwartete Layout-Verschiebungen während der gesamten Lebensdauer der Seite. Zielwert: unter 0,1.

INP hat im März 2024 die ältere Metrik FID (First Input Delay) vollständig abgelöst und ist deutlich aussagekräftiger, da es nicht nur die erste, sondern alle Interaktionen berücksichtigt.

Core Web Vitals messen und analysieren

Bevor du optimierst, brauchst du verlässliche Daten. Dabei unterscheidet man zwischen Labordaten (synthetische Tests) und Felddaten (echte Nutzerdaten aus dem Chrome UX Report).

Tools für die Messung

Mit Google PageSpeed Insights erhältst du beide Datenquellen auf einen Blick:

# Schnelle Analyse per API
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&locale=de"

Für die kontinuierliche Überwachung eignet sich die Google Search Console unter dem Reiter „Core Web Vitals". Dort siehst du, welche URL-Gruppen als „gut", „verbesserungswürdig" oder „schlecht" eingestuft werden.

Für detaillierte Laboranalysen ist Lighthouse im Chrome DevTools unerlässlich:

# Lighthouse über die CLI ausführen
npx lighthouse https://example.com --view --preset=desktop --locale=de

Zusätzlich kannst du mit der Web Vitals JavaScript-Bibliothek echte Nutzerdaten direkt in dein Analytics-System senden:

import {onLCP, onINP, onCLS} from 'web-vitals';

function sendToAnalytics(metric) {
  console.log(`${metric.name}: ${metric.value}`);
  // An eigenes Monitoring senden
  navigator.sendBeacon('/analytics', JSON.stringify(metric));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

LCP optimieren: Schnelleres Laden des Hauptinhalts

Der Largest Contentful Paint hängt von vier Faktoren ab: Serverantwortzeit, Render-blockierende Ressourcen, Ladezeit der Ressource und clientseitiges Rendering.

Server-Antwortzeit mit Caching reduzieren

Eine schnelle TTFB (Time to First Byte) ist die Grundlage für einen guten LCP. Konfiguriere aggressives Caching auf deinem Nginx-Server:

server {
    # Statische Assets langfristig cachen
    location ~* \.(css|js|woff2|webp|avif|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        add_header Vary "Accept-Encoding";
    }

    # HTML-Seiten kurz cachen
    location ~* \.html$ {
        expires 10m;
        add_header Cache-Control "public, no-cache";
    }
}

Brotli-Komprimierung aktivieren

Brotli komprimiert durchschnittlich 15–20 % besser als Gzip. Die Nginx-Konfiguration:

# Brotli-Komprimierung aktivieren
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

# Gzip als Fallback
gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/json;

LCP-Bild priorisieren

Das größte sichtbare Element ist häufig ein Hero-Bild. Sorge dafür, dass der Browser es sofort priorisiert:

<!-- LCP-Bild mit fetchpriority vorladen -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Im HTML: kein Lazy Loading für das LCP-Element -->
<img src="/hero.webp" alt="Hero-Bild" width="1200" height="600" fetchpriority="high">

Verwende moderne Bildformate wie WebP oder AVIF und liefere über <picture> das jeweils passende Format aus:

<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="Hero" width="1200" height="600" fetchpriority="high">
</picture>

INP optimieren: Reaktionsschnelle Interaktionen

Ein schlechter INP-Wert entsteht, wenn der Main Thread durch langes JavaScript blockiert wird. Das Ziel: Jede Interaktion sollte in unter 200 ms visuelles Feedback liefern.

Long Tasks identifizieren und aufbrechen

Öffne Chrome DevTools → Performance Tab und suche nach roten Balken (Long Tasks > 50 ms). Große JavaScript-Bundles solltest du per Code-Splitting aufteilen:

// Statt alles synchron zu laden
// import { heavyModule } from './heavyModule';

// Dynamischer Import – lädt erst bei Bedarf
const button = document.querySelector('#action-btn');
button.addEventListener('click', async () => {
  const { heavyModule } = await import('./heavyModule.js');
  heavyModule.run();
});

Yield to Main Thread

Bei komplexen Berechnungen solltest du dem Browser regelmäßig Kontrolle zurückgeben:

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Alle 5 Elemente dem Browser Luft zum Atmen geben
    if (i % 5 === 0) await yieldToMain();
  }
}

Third-Party-Scripts verzögern

Tracking-Pixel und Chat-Widgets sind häufig INP-Killer. Lade sie erst nach der initialen Interaktivität:

<script>
  // Third-Party erst nach User-Interaktion oder nach 5 Sekunden laden
  const loadThirdParty = () => {
    const script = document.createElement('script');
    script.src = 'https://analytics.example.com/tracker.js';
    document.head.appendChild(script);
  };

  window.addEventListener('scroll', loadThirdParty, { once: true });
  setTimeout(loadThirdParty, 5000);
</script>

CLS optimieren: Visuell stabile Seiten

Layout-Verschiebungen entstehen, wenn Elemente ihre Position oder Größe ändern, nachdem sie bereits sichtbar sind. Das frustriert Nutzer und verschlechtert den CLS-Wert.

Feste Dimensionen für Medien definieren

Die einfachste und wirkungsvollste Maßnahme gegen CLS:

<!-- Immer width und height angeben -->
<img src="/produkt.webp" alt="Produkt" width="400" height="300" loading="lazy">

<!-- Für responsive Bilder per CSS -->
<style>
  .responsive-img {
    aspect-ratio: 16 / 9;
    width: 100%;
    height: auto;
    object-fit: cover;
  }
</style>

Platzhalter für dynamische Inhalte

Werbebanner und eingebettete Inhalte sollten reservierten Platz erhalten:

/* Container mit fester Mindesthöhe für Ads */
.ad-slot {
  min-height: 250px;
  background-color: #f0f0f0;
  contain: layout;
}

/* Skeleton-Screen für nachgeladene Inhalte */
.skeleton {
  min-height: 200px;
  border-radius: 8px;
  background: linear-gradient(90deg, #e0e0e0 25%, #f5f5f5 50%, #e0e0e0 75%);
  background-size: 200% 100%;
  animation: shimmer 1.5s infinite;
}

Web Fonts ohne Layout-Shift

Schriftarten verursachen häufig CLS durch FOUT (Flash of Unstyled Text):

/* Font-Display swap vermeidet unsichtbaren Text, kann aber CLS auslösen */
/* Besser: optional für nicht-kritische Schriften */
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: optional;
}

Kombiniere das mit Preloading der kritischen Schrift:

<link rel="preload" href="/fonts/custom.woff2" as="font" type="font/woff2" crossorigin>

Lazy Loading strategisch einsetzen

Lazy Loading ist ein zweischneidiges Schwert: Richtig eingesetzt spart es Bandbreite, falsch eingesetzt verschlechtert es den LCP.

<!-- Above-the-fold: KEIN Lazy Loading, hohe Priorität -->
<img src="/hero.webp" alt="Hero" fetchpriority="high" width="1200" height="600">

<!-- Below-the-fold: Lazy Loading aktivieren -->
<img src="/teaser.webp" alt="Teaser" loading="lazy" width="600" height="400">

<!-- Iframes ebenfalls lazy laden -->
<iframe src="https://www.youtube.com/embed/xyz" loading="lazy" title="Video"></iframe>

Performance-Budget in der CI/CD-Pipeline

Damit sich die PageSpeed-Werte nicht schleichend verschlechtern, integriere Performance-Checks in deine Build-Pipeline:

# GitHub Actions: Lighthouse CI
name: Performance Audit
on: [push]
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lighthouse CI
        uses: treosh/lighthouse-ci-action@v11
        with:
          urls: |
            https://example.com/
            https://example.com/produkte/
          budgetPath: ./budget.json
          temporaryPublicStorage: true

Das zugehörige Budget definiert Schwellwerte:

[
  {
    "path": "/*",
    "timings": [
      { "metric": "largest-contentful-paint", "budget": 2500 },
      { "metric": "interactive", "budget": 3500 }
    ],
    "resourceSizes": [
      { "resourceType": "script", "budget": 150 },
      { "resourceType": "total", "budget": 500 }
    ]
  }
]

Fazit

Die Optimierung der Core Web Vitals ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Starte mit der Messung über PageSpeed Insights und die Search Console, identifiziere die größten Schwachstellen und arbeite sie systematisch ab: Brotli-Komprimierung und Caching für den LCP, Code-Splitting und verzögertes Laden von Third-Party-Scripts für den INP, feste Dimensionen und Font-Strategien gegen CLS. Integriere Performance-Budgets in deine CI/CD-Pipeline, damit gewonnene Verbesserungen nicht wieder verloren gehen. Schon einzelne Maßnahmen wie das korrekte Preloading des LCP-Elements oder die Aktivierung von Lazy Loading für Below-the-fold-Inhalte können die Web-Performance spürbar verbessern – und damit sowohl Rankings als auch Nutzerzufriedenheit steigern.