Posted inSEO Suchmaschinenoptimierung

Largest Contentful Paint (LCP) verbessern

Largest Contentful Paint (LCP) verbessern

Largest Contentful Paint (LCP) verbessern: Der ultimative Guide für 2026

Moin, ihr Performance-Junkies und SEO-Fans! Wer hätte gedacht, dass uns ein einzelner Browser-Wert auch 2026 noch so viele schlaflose Nächte bereiten kann? Während sich die SEO-Welt gerade wieder von den Nachbeben des Google Core Updates vom März 2026 erholt – ja, es war ordentlich turbulent in den Serps – bleibt ein Fels in der Brandung: die Core Web Vitals. Und der mit Abstand zickigste Messwert unter ihnen ist und bleibt der Largest Contentful Paint (LCP).

Google hat es inzwischen mehrfach klargestellt: Page Experience ist ein offizieller Ranking-Faktor, und die Nutzererfahrung zählt stärker denn je. Klar, ein langsames LCP killt nicht automatisch jede Seite – aber wer schnelle Seiten anbietet, hat einen handfesten Vorteil. Also schnappt euch einen Kaffee (oder Tee, ich verurteile nicht), wir zerlegen das Thema LCP gemeinsam in seine Einzelteile. Versprochen: Am Ende wisst ihr genau, wo ihr ansetzen müsst.

Was ist der LCP überhaupt – und warum macht er so viel Ärger?

Stellt euch vor, ihr betretet einen Raum und der erste Eindruck zählt. Genau das misst der LCP: die Zeit, bis das größte sichtbare Element einer Seite im Viewport dargestellt wird. Das kann ein hero-Image sein, ein Video-Poster, ein riesiges Heading oder ein Background-Bild. Wenn dieses Element zu lange auf sich warten lässt, haben Besucher sofort das Gefühl: „Hier läuft was schief.“ Und dieses Gefühl überträgt Google eins zu eins auf euer Ranking.

Das Ziel ist klar: Der LCP soll bei der 75. Perzentil unter 2,5 Sekunden liegen. Einfacher gesagt: Bei drei von vier Messungen sollte die Seite blitzschnell laden. Klingt machbar? Ist es auch – wenn man weiß, wo man anpackt.

Der LCP-Spielverlauf in 2026 folgt in der Regel diesem Drehbuch:

  1. Der Server braucht zu lange, um überhaupt zu antworten (TTFB).
  2. Die kritischen Ressourcen (CSS, JavaScript, Fonts) blockieren das Rendering.
  3. Das LCP-Bild selbst lädt einfach zu gemütlich.
  4. Und schwupps: 4,2 Sekunden stehen auf der Uhr.

Gut zu wissen: Welches Element als LCP-Element zählt, kann sich übrigens mit dem Seitenzustand ändern. Deshalb lohnt es sich, auf dem Radar zu behalten, welches Element aktuell der „Hauptdarsteller“ ist.

// LCP-Element im Browser auslesen – schnellster Weg
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log("LCP:", entry.startTime, "ms");
    console.log("Element:", entry.element);
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

Schritt 1: Den TTFB unter Kontrolle bringen

Alles fängt beim Server an. Ein TTFB (Time To First Byte) von 800 Millisekunden ist kein Grund zur Freude, sondern ein Warnsignal. Bevor auch nur ein Pixel gemalt wird, muss der Server ja erstmal liefern. Das, liebe Leute, ist die perfekte Gelegenheit, in ein schnelleres Hosting zu investieren oder zumindest ordentlich am Caching zu drehen.

Kurz gesagt: Weniger Arbeit auf dem Server, schnelleres Ergebnis. Ein paar Stellschrauben:

  • HTTP/2 oder HTTP/3: Moderne Protokolle, die Verbindungen bündeln und Latenzen senken.
  • Server-Side Caching: Eure Seite muss nicht bei jedem Aufruf von Null neu gebaut werden.
  • CDN: Der Content wohnt überall, der Nutzer bekommt ihn vom nächsten Server.

Und natürlich die Basics: Datenbank-Indexe prüfen, unnötige Plugins rausschmeißen und die Server-Konfiguration aufräumen. Wer unter WordPress lebt, kennt das Ritual.

Schritt 2: Kritische Ressourcen priorisieren

Hier beginnt die eigentliche Kunst. Stellt euch eure HTML-Antwort als ein Drehbuch vor: Der Browser muss zuerst wissen, was er zeichnen soll, bevor er irgendetwas zeichnet. Alles, was dafür nötig ist, ist „kritisch“. Alles andere darf warten.

Das wirft direkt die wichtigste Frage auf: Warum lädt meine Seite eigentlich 300 KB CSS, wenn davon nur 20 KB für den ersten Screenshot relevant sind? Genau deshalb solltet ihr euer CSS aufteilen (Critical CSS) und das Unkritische asynchron nachladen lassen.

<!-- Kritische Styles direkt einbetten -->
<style>
  header { background: #1a1a2e; }
  .hero img { width: 100%; height: auto; }
</style>

<!-- Der Rest darf gerne später kommen -->
<link rel="preload" href="/styles/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

Und beim JavaScript gilt die goldene Regel: Renderer nicht blockieren. Ob defer oder async – beides besser als ein stinknormales Skript im Head, das den Browser zwingt, stillzuhalten, bis es fertig geladen ist.

<!-- Blockierend – so bitte nicht -->
<script src="/scripts/main.js"></script>

<!-- Besser: Das Skript wartet, bis der Parser fertig ist -->
<script src="/scripts/main.js" defer></script>

Schritt 3: Das LCP-Bild wird zum Leichtgewicht

Jetzt kommt das Herzstück: Das LCP-Bild selbst. Ich sehe es immer wieder – ein Hero-Bild in Original-Qualität von 4 MB, direkt vom Smartphone hochgeladen. Freunde, das ist kein Kunstwerk, das ist eine Performance-Sünde. Das Bild muss aufs Diät-Programm, und zwar konsequent.

Die drei magischen Wörter lauten: Komprimieren, Konvertieren, Responsive.

  • Komprimieren: Tools wie AVIF oder WebP schrumpfen Bilder um 50 % und mehr, ohne dass es jemandem auffällt.
  • Konvertieren: Moderne Formate nutzen bessere Kompressionsalgorithmen als das uralte JPEG.
  • Responsive: Ein Desktop-Bild muss nicht auch auf dem Handy geladen werden. srcset regelt.
<img
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, 800px"
  width="800" height="450"
  fetchpriority="high"
  alt="Moderne Bürolandschaft im Sonnenuntergang"
>

Ja, ihr habt richtig gelesen: fetchpriority="high". Das ist euer VIP-Ticket für das LCP-Bild. Der Browser weiß dann sofort: „Das hier ist wichtig, das lade ich zuerst.“ Für alle Nicht-LCP-Bilder gilt dagegen loading="lazy" – die dürfen sich gerne Zeit lassen.

Und noch ein Detail, das gerne übersehen wird: Gebt euren Bildern festen Platz (width und height), sonst verschiebt sich beim Laden das Layout – und der böse Cousin CLS klopft an die Tür.

Schritt 4: Fonts zähmen

Webfonts sind wie Katzen: wunderschön, aber sie machen was sie wollen. Oft blockieren sie das Rendering, weil der Browser erst abwartet, bis die Schrift geladen ist, bevor er Text zeichnet. Die Lösung: font-display: swap in der @font-face-Regel. So erscheint der Text sofort mit einer Fallback-Schrift und wechselt elegant zur Wunsch-Schrift, sobald diese da ist.

@font-face {
  font-family: "MeineSchrift";
  src: url("/fonts/meine-schrift.woff2") format("woff2");
  font-display: swap;
  font-weight: 400;
}

Dazu: Nur die Schriftschnitte laden, die ihr wirklich nutzt. woff2 ist das kompakteste Format und sollte euer Standard sein. Und ganz wichtig: Fonts per preload ankündigen, damit sie sich nicht hinten anstellen müssen.

Schritt 5: Messen, was verbessert werden soll

Ein Satz, den ihr garantiert schon einmal gehört habt, der aber trotzdem stimmt: „Was du nicht misst, kannst du nicht verbessern.“ Und im Fall vom LCP gilt das doppelt, denn Feld- und Labormessung können sich ordentlich unterscheiden.

Mein persönliches Mess-Setup in 2026:

  • PageSpeed Insights: Der Klassiker, liefert Labor- und Felddaten in einem Rutsch.
  • Google Search Console: Die Core-Web-Vitals-Berichte zeigen, wo echte Nutzer hängen bleiben.
  • CrUX (Chrome UX Report): Die Datenbasis dahinter, mit realen Messungen aus Chrome.
  • DevTools Performance-Tab: Für die Detailanalyse im Browser.

Der Workflow ist simpel: Erst schauen, welches der vier LCP-Teilstücke (TTFB, Rendering, Ressourcen, Bild) am meisten Zeit frisst, dann gezielt dort ansetzen. Oft reicht es schon, das LCP-Bild zu optimieren oder die Server-Antwortzeit zu drücken, um den Wert unter die 2,5 Sekunden zu kriegen.

# LCP-Logfile schnell auf das Wesentliche prüfen
# Angenommen: WebPageTest CSV-Export
awk -F',' 'NR==1 || /(LCP|TTFB|FCP)/ { print $1, $2 }' vitals.csv

Und was ist mit den kleinen Perfektionisten unter euch?

Für alle, die noch einen drauflegen wollen: Es gibt 2026 ein paar richtig coole Möglichkeiten, die Sache auf das nächste Level zu heben. Wie wäre es mit preconnect für eure CDN- oder Bild-Domains, damit die Verbindung schon steht, bevor sie gebraucht wird? Oder mit dem Priority Hints, die wir eben schon beim fetchpriority angesprochen haben?

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preload" href="/hero-800.webp" as="image" fetchpriority="high">

Und wer wirklich alles rausholen will, schaut sich experimentelle Sachen wie fetchpriority="high" mit render-blocking-Hinweisen oder den Einsatz von Service Workern fürs Offline-Caching an. Aber Vorsicht: Mit Optimierungen ist es wie mit Gewürzen – zu viel ruiniert den Brei. Erst die Basisschrauben drehen, dann feintunen.

Fazit: Der LCP ist kein Monster, nur ein sehr bestimmter Kollege

Der LCP mag 2026 immer noch die ungeliebte Hausaufgabe der Core Web Vitals sein, aber er ist kein unlösbares Rätsel. Die Rechnung ist simpel: Schneller Server, weniger Blockade durch CSS und JavaScript, ein schlankes Bild mit VIP-Behandlung und Fonts mit guter Manieren. Das war’s – mehr steckt nicht dahinter.

Und der Lohn? Eine schnellere Seite, die Nutzer wirklich mögen, bessere Werte im Search-Console-Report und ein kleines, feines Plus im Ranking-Wettbewerb – gerade jetzt, wo Google auch 2026 wieder beweist, dass Page Experience ein Thema ist, das man nicht auf die lange Bank schiebt. Also: Messt, optimiert, und wenn ihr denkt „jetzt reicht’s“, dann dreht noch eine Schraube. Euer künftiges Ich im Core-Web-Vitals-Report wird es euch danken.