Back

Core Web Vitals: So optimieren Sie LCP

Core Web Vitals: So optimieren Sie LCP

Largest Contentful Paint (LCP) misst, wie schnell Ihr Hauptinhalt lädt—das Hero-Bild, die Schlagzeile oder das Video, das Besucher zuerst sehen. Wenn dies länger als 2,5 Sekunden dauert, nehmen Nutzer Ihre Website als langsam wahr, die Absprungrate steigt und Ihre Core Web Vitals-Werte leiden. Dieser Leitfaden erklärt detailliert, wie Sie LCP-Probleme in allen vier Phasen des Ladeprozesses diagnostizieren und beheben.

Wichtige Erkenntnisse

  • LCP misst die Renderzeit des größten sichtbaren Inhaltselements vor Nutzerinteraktion
  • Google verlangt, dass 75% der Seitenbesuche LCP unter 2,5 Sekunden erreichen für gute Core Web Vitals
  • Die Optimierung umfasst vier Phasen: TTFB, Ressourcenerkennung, Ladedauer und Render-Verzögerung
  • Laden Sie niemals Above-the-fold-Inhalte lazy—das ist der häufigste LCP-Fehler

Was ist Largest Contentful Paint (LCP)?

LCP verfolgt die Renderzeit des größten sichtbaren Inhaltselements im Viewport vor Nutzerinteraktion. Dies könnte ein <img>, <video> oder Textblock sein. Im Gegensatz zu abstrakten Metriken spiegelt LCP wider, was Nutzer tatsächlich erleben—wann sich die Seite „geladen” anfühlt.

Google setzt klare Schwellenwerte:

  • Gut: Unter 2,5 Sekunden
  • Verbesserungsbedürftig: 2,5-4,0 Sekunden
  • Schlecht: Über 4,0 Sekunden

Um Core Web Vitals zu bestehen, müssen 75% Ihrer Seitenbesuche „gute” LCP-Werte erreichen. Dies wirkt sich direkt auf SEO-Rankings aus, da Google Core Web Vitals als Ranking-Signal verwendet.

Die vier Phasen der LCP-Optimierung

LCP ist keine einzelne Metrik—es ist die Summe von vier unterschiedlichen Phasen. Das Verständnis dieser Aufschlüsselung ist entscheidend für gezielte Optimierung:

  1. Time to First Byte (TTFB): Server-Antwortzeit (~40% des gesamten LCP)
  2. Resource Load Delay: Zeit zwischen TTFB und Start des LCP-Ressourcen-Downloads (<10%)
  3. Resource Load Duration: Tatsächliche Download-Zeit (~40%)
  4. Element Render Delay: Zeit vom Abschluss des Downloads bis zur visuellen Darstellung (<10%)

Die „Verzögerungs”-Phasen sollten sich null nähern. Jede Wartezeit ist pure Verschwendung.

Phase 1: Server-Antwortzeit optimieren (TTFB)

Ein langsamer TTFB untergräbt alles andere. Wenn Ihr Server 3 Sekunden für eine Antwort benötigt, wird ein 2,5-Sekunden-LCP unmöglich.

Häufige TTFB-Probleme:

  • Mehrere Weiterleitungen (jede fügt 100-500 Millisekunden hinzu)
  • Server weit entfernt von Nutzern
  • Ineffizienter Backend-Code
  • Datenbank-Engpässe

Lösungen:

  • Server-seitiges Caching implementieren
  • CDN verwenden, um Inhalte von Edge-Standorten zu liefern
  • Weiterleitungen minimieren—direkt das finale URL-Format verwenden
  • Datenbankabfragen und Backend-Verarbeitung optimieren

Profi-Tipp: CDNs können Server-Probleme verbergen. Testen Sie mit URL-Parametern (z.B. ?test=123), um CDN-Caches zu umgehen und die wahre Server-Performance zu enthüllen.

Phase 2: Ressourcenerkennungs-Verzögerungen eliminieren

Der Browser muss Ihre LCP-Ressource sofort finden. Jede Erkennungsverzögerung ist verschwendete Zeit.

Kritischer Fehler: Lazy-Loading des LCP-Bildes. Verwenden Sie niemals loading="lazy" bei Above-the-fold-Inhalten—es verzögert absichtlich Ihr wichtigstes Element.

Ressourcen auffindbar machen:

<!-- Gut: Bild in HTML -->
<img fetchpriority="high" src="/hero.webp" alt="...">

<!-- Schlecht: Versteckt in CSS -->
.hero { background-image: url('/hero.webp'); }

Für CSS-Hintergrundbilder (vermeiden Sie diese für LCP wenn möglich), preloaden Sie sie:

<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">

Das fetchpriority="high"-Attribut teilt Browsern mit, diese Ressource über andere zu priorisieren. Ohne es laden Bilder oft standardmäßig mit „niedriger” Priorität herunter.

Phase 3: Ressourcen-Ladedauer reduzieren

Kleinere Dateien laden schneller herunter. Diese Phase ist reine Physik—reduzieren Sie Bytes, reduzieren Sie Zeit.

Bildoptimierung:

  • Moderne Formate verwenden (WebP, AVIF)
  • Responsive Bilder mit srcset implementieren
  • Ohne sichtbaren Qualitätsverlust komprimieren
  • Bilder korrekt dimensionieren—laden Sie keine 4K-Bilder für Mobilgeräte

Schriftart-Optimierung für Text-LCP:

  • font-display: swap verwenden, um Text sofort anzuzeigen
  • Schriftarten auf erforderliche Zeichen reduzieren
  • Kritische Schriftarten preloaden

CDN-Überlegungen:

  • Bild-CDNs optimieren automatisch Formate und Komprimierung
  • Same-Origin-Bereitstellung vermeidet Verbindungsoverhead
  • CDN-Proxy-Features verwenden, wenn verfügbar

Phase 4: Render-Blocking minimieren

Selbst mit heruntergeladenen Ressourcen kann das Rendering aufgrund von Main-Thread-Überlastung stocken.

Häufige Blocker:

  • Render-blockierendes CSS in <head>
  • Synchrone JavaScript-Ausführung
  • Lange Aufgaben von Drittanbieter-Skripten

Lösungen:

Kritisches CSS inline einbetten:

<style>
  /* Nur Above-the-fold-Styles */
  .hero { /* styles */ }
</style>

Nicht-kritisches JavaScript verzögern:

<script defer src="/app.js"></script>

Für textbasierte LCP-Elemente, die von Web-Fonts blockiert werden, Fallback-Rendering sicherstellen:

@font-face {
  font-family: 'Custom';
  font-display: swap; /* Zeigt Fallback sofort */
  src: url('/font.woff2') format('woff2');
}

Sonderfälle: Video und Hintergrundbilder

Video-Elemente: Das Poster-Bild oder der erste Frame wird zum LCP-Kandidaten. Optimieren Sie das Poster-Bild wie jedes andere Bild und stellen Sie sicher, dass die Video-Kodierung effizient ist.

CSS-Hintergrundbilder: Diese erzeugen inhärente Erkennungsverzögerungen. Der Browser kann nicht preloaden, was er noch nicht geparst hat. Konvertieren Sie kritische Hintergrundbilder zu <img>-Elementen oder preloaden Sie sie explizit.

LCP messen und überwachen

Labordaten (PageSpeed Insights, Lighthouse) helfen bei der Problemdiagnose, aber Felddaten (CrUX, RUM) zeigen die echte Nutzererfahrung. Priorisieren Sie immer Felddaten—das ist was Google für Rankings verwendet.

Verwenden Sie das Chrome DevTools Performance-Panel, um LCP-Aufschlüsselungen lokal zu sehen. Die web-vitals JavaScript-Bibliothek ermöglicht benutzerdefinierte Überwachung:

import {onLCP} from 'web-vitals';

onLCP(({value, entries}) => {
  console.log('LCP:', value, entries[0].element);
});

Fazit

Die Optimierung von LCP erfordert systematische Aufmerksamkeit für alle vier Phasen. Beginnen Sie mit TTFB—keine Optimierung ist wichtig, wenn Ihr Server langsam ist. Stellen Sie sofortige Ressourcenerkennung sicher, minimieren Sie Dateigrößen und eliminieren Sie render-blockierende Ressourcen. Am wichtigsten: Laden Sie niemals Ihr LCP-Element lazy. Mit diesen Optimierungen wird das Erreichen eines sub-2,5-Sekunden-LCP nicht nur möglich, sondern vorhersagbar.

Häufig gestellte Fragen

Labor-Tools wie PageSpeed Insights testen unter kontrollierten Bedingungen mit spezifischen Netzwerkgeschwindigkeiten und Geräten. Echte Nutzer haben unterschiedliche Verbindungen, Geräte und geografische Standorte. Felddaten von CrUX spiegeln tatsächliche Nutzererfahrungen wider, was Google für Rankings verwendet.

Ja, JavaScript-Frameworks können LCP verzögern, wenn sie Inhalte client-seitig rendern. Der Browser muss JavaScript herunterladen, parsen und ausführen, bevor Inhalte angezeigt werden. Server-seitiges Rendering oder statische Generierung kann LCP für Framework-basierte Websites erheblich verbessern.

Grundsätzlich ja. Lazy Loading von Below-the-fold-Bildern reduziert das anfängliche Seitengewicht und verbessert die Performance. Stellen Sie nur sicher, dass Sie niemals Above-the-fold-Inhalte lazy laden, besonders nicht Ihr LCP-Element. Verwenden Sie loading=lazy für Bilder außerhalb des anfänglichen Viewports.

Drittanbieter-Skripte können den Main-Thread blockieren und sowohl das Laden von Ressourcen als auch das Rendering verzögern. Sie können auch render-blockierende Ressourcen einschleusen. Laden Sie Drittanbieter-Skripte asynchron, verzögern Sie nicht-kritische und erwägen Sie Web Workers für schwere Verarbeitungsaufgaben.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay