Inhaltsverzeichnis
Largest Contentful Paint (LCP) misst, wie schnell das größte sichtbare Element Ihrer Seite gerendert wird. Bei einem Schwarzwald-Hotelportal ist das oft das Hero-Bild der Außenansicht, bei einem Heidelberger Pharma-Distributor das Produkt-Headline-Visual, bei einer Konstanzer Automotive-Konfigurator-Page häufig der erste Konfigurator-Block. Ein guter LCP-Wert ist seit 2021 ranking-relevant — und entscheidet auf Mobile über Verweildauer und Conversion.
LCP in einem Satz
Zeit vom Navigationsbeginn bis das größte Element im sichtbaren Bereich vollständig dargestellt ist.
Bewertung
| Bewertung | Wert |
|---|---|
| Gut | ≤ 2,5 s |
| Verbesserungswürdig | 2,5 – 4 s |
| Schlecht | > 4 s |
Was typischerweise das LCP-Element ist
- Hero-Bilder — emotionales Bildmotiv über dem Fold
- Hintergrundbilder — CSS-
background-image - Video-Poster — Vorschaubild eines Embed-Videos
- Große Textblöcke — Headlines, Hero-Texte
- SVG-Logos und Illustrationen — sofern groß genug
LCP-Element identifizieren
Chrome DevTools:
- F12 → Performance Tab
- Seite mit “Slow 3G”-Throttling neu laden
- Timeline → “LCP”-Marker → Element-Quelle
Lighthouse:
- Audit ausführen
- Diagnostics → “Largest Contentful Paint element”
Die vier Hauptursachen für schlechten LCP
1. Langsame Server-Antwortzeit (TTFB)
Der Server braucht zu lange für die erste Antwort. Bei einem Heidelberger Pharma-Großhändler mit ungecachtem Live-Datenbank-Zugriff auf hunderttausend Artikelnummern ist das ein Dauerproblem.
Lösungen:
- Server-seitiges Caching (Page Cache, Object Cache via Redis)
- CDN für statische Ressourcen
- Hosting-Provider-Wechsel bei strukturellem Problem
- Datenbank-Indizes und N+1-Queries beheben
# Nginx-Caching für statische Assets
location ~* \.(jpg|jpeg|png|webp|avif|gif|ico|css|js)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
2. Render-Blocking Resources
CSS und JavaScript blockieren den ersten Render.
Lösungen:
- Critical CSS inline einbinden (Above-the-fold)
- Restliches CSS verzögert via
preload onload - JavaScript mit
deferoderasync
<style>
/* Critical CSS — Hero, Above-the-fold */
.hero { ... }
</style>
<link rel="preload" href="styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
3. Langsam ladende Ressourcen
Bilder und Fonts brauchen zu lange. Bodensee-Hotelportale mit unkomprimierten 8-MB-Hero-Bildern sind der Klassiker.
Lösungen:
- WebP/AVIF statt JPEG (siehe Bildoptimierung)
- Responsive Images via
srcset font-display: swapund Font-Preload- Preload der kritischen Hero-Ressource
4. Client-side Rendering-Verzögerung
JavaScript baut den sichtbaren Inhalt erst im Browser auf — typisches Symptom in SPA-getriebenen Marketing-Sites.
Lösungen:
- Server-Side Rendering (SSR) — Next.js, Astro, Nuxt
- Static Site Generation (SSG) für Marketing-Pages
- Hydration-Strategien — Astro-Islands, React Server Components
fetchpriority — der einfachste Quick-Win
<img
src="hero.jpg"
alt="Headline-Visual"
fetchpriority="high"
loading="eager"
width="1920"
height="1080"
>
Werte
high— höhere Priorität als normallow— niedrigere Prioritätauto— Browser-Default
Preload für kritische Ressourcen
<head>
<!-- LCP-Bild vorladen -->
<link rel="preload" href="/hero.webp"
as="image" type="image/webp"
fetchpriority="high">
<!-- Critical Font vorladen -->
<link rel="preload" href="/fonts/main.woff2"
as="font" type="font/woff2" crossorigin>
</head>
Wann Preload sinnvoll ist
- LCP-Bilder
- Critical Fonts (Body-Schrift)
- Critical CSS (wenn nicht inline)
- JavaScript, das Above-the-fold-Content rendert
Bilder für LCP optimieren
Responsive Images
<img
src="hero-800.jpg"
srcset="
hero-400.jpg 400w,
hero-800.jpg 800w,
hero-1200.jpg 1200w,
hero-1600.jpg 1600w
"
sizes="100vw"
alt="Hero"
width="1600"
height="900"
fetchpriority="high"
>
Moderne Formate
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Hero" fetchpriority="high">
</picture>
Richtig dimensionieren
Niemals 4000-px-Bilder für 1200-px-Container ausliefern. Ein Tübinger Biotech-Spezialist mit detailreichen Mikroskop-Aufnahmen sollte die Bilder exakt auf maximale Darstellungsgröße zuschneiden.
Fonts und LCP
Wenn Text das LCP-Element ist (Hero-Headline), verzögern Schriften den Render.
font-display: swap
@font-face {
font-family: 'CorporateSans';
src: url('/fonts/corporate.woff2') format('woff2');
font-display: swap;
}
Font preloaden
<link rel="preload" href="/fonts/corporate.woff2"
as="font" type="font/woff2" crossorigin>
CDN — wann es lohnt
Für Hidden Champions mit international verteilter Kundschaft (DACH, FR, IT, USA, Asien) ist ein CDN Pflicht. Edge-Caching reduziert TTFB für entfernte Nutzer um 200-500 ms.
Empfohlene CDNs
- Cloudflare — kostenfreier Plan ausreichend für die meisten KMU
- Bunny.net — Premium-Performance, EU-Datenschutz-konform
- AWS CloudFront — wenn AWS-Stack ohnehin vorhanden
- Fastly — Enterprise mit Edge-Computing-Optionen
LCP messen und überwachen
PageSpeed Insights
https://pagespeed.web.dev/
Lab- und Field-Daten plus konkrete Empfehlungen.
Chrome DevTools
F12 → Performance Tab → Throttling auf “Slow 3G” → Seite neu laden → LCP-Marker.
Web-Vitals JavaScript
import { onLCP } from 'web-vitals';
onLCP(metric => {
console.log('LCP:', metric.value);
// An Analytics senden (GA4, Sentry, eigenes Logging)
});
Checkliste
- LCP-Element identifiziert
-
fetchpriority="high"für LCP-Bild gesetzt - Bild in WebP UND AVIF
- Critical CSS inline
- JavaScript mit
defer/async - Fonts preloaded und mit
font-display: swap - CDN aktiv
- Server-Caching auf Page- und Object-Level
- TTFB unter 800 ms
- Field-Daten in Search Console grün
Häufige LCP-Fehler
1. Lazy Loading auf LCP-Bild
<!-- FALSCH -->
<img src="hero.jpg" loading="lazy">
<!-- RICHTIG -->
<img src="hero.jpg" loading="eager" fetchpriority="high">
2. Mega-Hero ohne Optimierung
5-MB-Hero auch auf Glasfaser zu langsam. Targetwert: unter 200 KB für Hero-Bilder.
3. JavaScript blockiert Render
Analytics, Tag-Manager und A/B-Test-Tools synchron im Head — fataler Performance-Killer. Alles defer oder async.
4. Fehlende Preload-Hints
Browser entdeckt das LCP-Bild erst nach CSS-Parse. Mit Preload sparen Sie 100-300 ms.
Fazit
LCP ist Ranking-Faktor und Conversion-Hebel zugleich. Mit den richtigen Maßnahmen — fetchpriority, Preloading, Bildoptimierung, CDN, sauberes Server-Caching — bringen Sie LCP unter 2,5 Sekunden. Für Hidden Champions zwischen Schwarzwald und Bodensee, für Pharma-Distributoren am Neckar und Hotellerie auf der Schwäbischen Alb zahlt sich jede eingesparte Millisekunde direkt aus.
Eine vollständige PageSpeed-Optimierung durch unser Team analysiert Ihre LCP-Ursachen, priorisiert Quick-Wins und implementiert die strukturellen Fixes. Stuttgart-Region: vertiefend bei SEO Stuttgart, Webdesign-Performance bei webdesigner-halle.de. Verwandte Beiträge: Bildoptimierung, CLS vermeiden, Mobile-First Indexing.
FAQ
Wie finde ich mein LCP-Element?
Chrome DevTools (Performance Tab, “LCP”-Marker) oder PageSpeed Insights (Audits → “Largest Contentful Paint element”). Beide zeigen das konkrete DOM-Element und seine Render-Zeit.
Ist LCP von 3 Sekunden schlecht?
Fällt in “verbesserungswürdig”. Google empfiehlt unter 2,5 s, idealerweise unter 2 s. Für Wettbewerbsumfelder mit hohen Conversion-Raten lohnt der Push.
Kann JavaScript das LCP-Element sein?
Ja, bei SPAs, die den größten sichtbaren Inhalt clientseitig rendern. Lösung: SSR oder SSG.
Hilft ein CDN immer?
Vor allem bei geografisch verteilter Nutzerschaft. Für rein regionale BW-Sites bleibt der Cache-Vorteil — die Latenz-Verbesserung fällt geringer aus, lohnt aber meist trotzdem.