LCP & INP gezielt optimieren

LCP verbesserst du, indem du das größte sichtbare Element früh anforderst, klein hältst und nichts davorstellst, was das Rendern blockiert; INP verbesserst du, indem du weniger JavaScript ausführst und lange Aufgaben zerteilst. Beide Werte zerfallen in Phasen – und wer weiß, in welcher Phase die Zeit verloren geht, spart sich das Optimieren auf Verdacht.

Die Core Web Vitals im Überblick zeigen, was LCP, INP und CLS messen. Diese Seite geht in die Tiefe bei den beiden, die in der Praxis am meisten Arbeit machen. CLS ist mit festen Bildmaßen meist schnell erledigt – diese zwei nicht immer. In den öffentlichen Auswertungen echter Chrome-Daten ist LCP regelmäßig der Wert, an dem die meisten Seiten scheitern: Rund die Hälfte aller mobil gemessenen Websites besteht alle drei Kernwerte, und wenn eine daran scheitert, dann meist am Ladegefühl.

Das Wichtigste in Kürze

• Zielwerte: LCP ≤ 2,5 s, INP ≤ 200 ms – jeweils im 75. Perzentil echter Besuche.
• Erst messen, dann schrauben: Beide Werte zerfallen in Phasen. Die Phase mit dem größten Anteil ist deine Baustelle.
• LCP-Faustregel: Server-Antwort und Bildladen dürfen je rund 40 Prozent des Budgets kosten, Warten und Rendern je unter 10 Prozent.
• Der häufigste LCP-Fehler ist ein loading="lazy" am wichtigsten Bild.
• Der häufigste INP-Fehler ist zu viel JavaScript am Stück – oft aus Drittanbieter-Skripten, die niemand mehr überblickt.
• Feld schlägt Labor: Für die Bewertung zählen die Daten echter Besucher. INP lässt sich im Labor überhaupt nicht messen, nur schätzen.

LCP: erst herausfinden, welches Element gemeint ist

Bevor man optimiert, muss man wissen, was eigentlich gemessen wird. Der Largest Contentful Paint ist der Zeitpunkt, zu dem das größte Inhaltselement im sichtbaren Bereich fertig gezeichnet ist. Das ist überraschend oft kein Bild, sondern ein Textblock – eine große Überschrift oder der erste Absatz. Und das ändert die Strategie vollständig: Bei einem Text-LCP nützt Bildoptimierung nichts, dann sind Schriftladen und render-blockierendes CSS die Stellschrauben.

Herausfinden lässt es sich in Sekunden:

• PageSpeed Insights nennt unter „Diagnose“ das LCP-Element im Klartext.
• In den Chrome-DevTools zeigt der Performance-Bereich nach einer Aufzeichnung eine LCP-Markierung; ein Klick darauf hebt das Element im DOM hervor.
• Im Feld liefert die JavaScript-Bibliothek web-vitals in der Attribution-Variante sowohl das Element als auch die Aufteilung nach Phasen.

Die vier LCP-Phasen und ihre Budgets

Phase 1 – Server-Antwort (TTFB)

Alles, was hier verloren geht, fehlt nachher überall. Als Richtwert gilt ein TTFB unter 800 Millisekunden; darüber wird ein guter LCP zur Glückssache.

Die wirksamsten Hebel sind unspektakulär: statisches HTML statt Rendern bei jedem Aufruf, Kompression (Brotli oder gzip), vernünftige Cache-Header, ein Server in der Nähe der Zielgruppe. Und: Weiterleitungsketten abbauen. Jede Umleitung – http → https → www → Zielseite – kostet eine volle Rundreise, oft mehr, als die ganze Bildoptimierung danach einspart.

Phase 2 – Warten, bis das Bild überhaupt angefordert wird

Diese Phase ist die undankbarste, weil in ihr nichts passiert: Der Browser hat das HTML, aber weiß noch nicht, dass er das Heldenbild braucht. Ursachen sind fast immer dieselben:

• Das Bild steckt in einem CSS-Hintergrund – der Browser findet es erst, wenn das CSS geladen und geparst ist.
• Das Bild wird per JavaScript nachgeladen – dann kommt es noch später.
• Das Bild ist auf loading="lazy" gesetzt.

Deshalb gilt: Das LCP-Bild gehört als echtes <img> ins ausgelieferte HTML, nicht auf „lazy“ und mit Vorrang versehen:

<img
  src="/img/held-800.webp"
  srcset="/img/held-800.webp 800w, /img/held-1600.webp 1600w"
  sizes="(min-width: 56rem) 800px, 100vw"
  width="800"
  height="450"
  fetchpriority="high"
  alt="…"
/>

fetchpriority="high" reicht in den meisten Fällen. Ein zusätzliches <link rel="preload" as="image"> lohnt nur dann, wenn das Bild für den Parser tatsächlich unsichtbar ist – etwa als CSS-Hintergrund. Wichtig dabei: Beim Preload eines responsiven Bildes müssen imagesrcset und imagesizes mitgegeben werden, sonst lädt der Browser die falsche Größe doppelt.

Ein Detail, das ich schon oft als Ursache gefunden habe: Viele Bausteine setzen loading="lazy" pauschal auf jedes Bild – Baukästen, CMS-Plugins, Bildkomponenten von Frameworks. Genau dann trifft es zuverlässig auch das wichtigste Bild oben.

Phase 3 – Ladedauer der Ressource

Hier zählen Kilobytes, sonst nichts. Modernes Format (WebP oder AVIF), passende Maße per srcset/sizes, kein 3000-Pixel-Foto für einen 800-Pixel-Platz. Als grober Anhaltspunkt: Wer das LCP-Bild unter etwa 150 KB hält, hat auf einer Mobilverbindung Luft. Die Details stehen unter Bild-SEO und moderne Formate.

Zwei weitere Punkte in dieser Phase: Ressourcen von der eigenen Domain laden (jede fremde Domain kostet vorher DNS, TCP und TLS – oder ein preconnect), und das Stylesheet kleiner halten als das LCP-Bild, weil sonst das CSS zum eigentlichen Flaschenhals wird.

Phase 4 – Renderverzögerung

Das Bild ist da, aber nichts erscheint: Dann blockiert etwas das Rendern. Typische Verdächtige sind ein synchrones <script> im <head>, ein riesiges Stylesheet, das erst vollständig geladen sein will, oder eine Anwendung, die den Inhalt erst per JavaScript in die Seite schreibt.

Bei einem Text-LCP ist es fast immer die Schrift: Solange die Webschrift lädt, zeigt der Browser je nach font-display gar keinen Text (block) oder den Fallback (swap). Selbst hosten, als WOFF2 ausliefern, font-display: swap setzen und die eine wirklich nötige Schriftdatei vorladen:

<link
  rel="preload"
  as="font"
  type="font/woff2"
  href="/fonts/plus-jakarta-sans.woff2"
  crossorigin
/>

Das crossorigin ist kein Schmuck: Ohne dieses Attribut lädt der Browser die Schrift ein zweites Mal.

INP: drei Phasen pro Interaktion

Interaction to Next Paint misst, wie schnell die Seite sichtbar auf eine Eingabe reagiert – über alle Klicks, Taps und Tastatureingaben eines Besuchs hinweg, gewertet wird die langsamste. Jede Interaktion zerfällt in drei Phasen:

1. Eingabeverzögerung: Der Hauptthread ist noch mit etwas anderem beschäftigt. Der Klick liegt in der Warteschlange, bevor überhaupt ein Handler startet.
2. Verarbeitung: Deine Event-Handler laufen.
3. Darstellungsverzögerung: Der Browser rechnet Layout und Malen aus und zeichnet das nächste Bild.

Die Reihenfolge ist wichtig, weil sie erklärt, warum „mein Klickhandler ist doch schnell“ kein Gegenargument ist: Wenn 260 ms Eingabeverzögerung davorliegen, ist das Rennen gelaufen, bevor der eigene Code startet.

Hebel 1: weniger JavaScript

Der wirksamste Hebel ist der naheliegendste. Wer Verhalten nativ löst statt es nachzubauen – siehe die erste Regel von ARIA und details/summary –, hat weniger Code, der hängen kann. Ein Akkordeon aus HTML kostet null Millisekunden Eingabeverzögerung.

Besonders lohnend ist der Blick auf Drittanbieter: Consent-Banner, Tag-Manager, Chat-Widgets, Heatmap-Tools. Sie laufen im selben Hauptthread wie alles andere, werden aber selten überprüft. Ein Consent-Banner, das beim Klick erst ein ganzes Tag-Management nachlädt, ist ein Klassiker für schlechte INP-Werte – gemessen wird ausgerechnet die Interaktion, die fast jeder Besuch ausführt.

Hebel 2: lange Aufgaben zerteilen

Arbeit über 50 ms am Stück blockiert spürbar. Teile sie auf und gib dem Browser zwischendurch Luft. Die moderne Variante heißt scheduler.yield(); sie ist noch nicht in allen Browsern verfügbar (Safari fehlt), lässt sich aber sauber mit setTimeout absichern:

// Gibt den Hauptthread frei: modern per scheduler.yield, sonst per setTimeout.
function luftHolen() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function zeilenVerarbeiten(zeilen) {
  for (let i = 0; i < zeilen.length; i++) {
    verarbeite(zeilen[i]);
    if (i % 50 === 49) await luftHolen(); // alle 50 Zeilen abgeben
  }
}

Hebel 3: zuerst reagieren, dann rechnen

Ein Muster, das in der Praxis mehr bringt als jede Mikrooptimierung: Erst die sichtbare Rückmeldung, dann die Arbeit. Der Browser darf dazwischen zeichnen – und genau das misst INP.

filterButton.addEventListener('click', async () => {
  filterButton.setAttribute('aria-busy', 'true'); // 1. sofort sichtbar reagieren
  await luftHolen(); //                              2. Browser zeichnen lassen
  const treffer = filtereProdukte(daten); //          3. erst danach rechnen
  zeigeTreffer(treffer);
  filterButton.removeAttribute('aria-busy');
});

Nicht-Dringendes gehört ganz ans Ende: Analytics-Ereignisse, Nachladen von Empfehlungen, Protokollierung. Nichts davon muss vor dem nächsten Bild passieren.

Hebel 4: Darstellung billig halten

Die dritte Phase wird teuer, wenn der Browser bei jeder Interaktion viel neu berechnen muss:

• DOM klein halten. Zehntausende Knoten machen jede Layoutberechnung teuer.
• content-visibility: auto für lange, weit unten liegende Bereiche – der Browser überspringt deren Layout, bis sie gebraucht werden.
• Layout-Thrashing vermeiden: nicht abwechselnd Maße lesen (offsetWidth) und Stile schreiben. Erst alles lesen, dann alles schreiben.
• Animationen über transform und opacity statt über top/width – die laufen ohne neues Layout.

Randnotiz – Statik gewinnt fast geschenkt. Eine Seite, die „Zero JS by default“ ausliefert, hat kaum etwas, das den Hauptthread blockieren könnte. Genau deshalb erreichen statische, semantische Seiten gute INP-Werte, ohne dass man eigens dafür kämpfen muss. Diese Website hier ist der Beleg: Ihre Total Blocking Time liegt bei 0 ms – nicht als Ergebnis von Optimierung, sondern weil nichts da ist, das blockieren könnte.

Messen: Feld vor Labor

Für die Bewertung zählen Felddaten echter Besucher (Chrome User Experience Report), nicht die Laborwerte aus Lighthouse. Nutze das Labor zum Finden der Ursache, das Feld als Wahrheit.

Bei INP ist der Laborwert grundsätzlich nur eine Schätzung, weil im Labortest niemand klickt – Lighthouse zeigt ersatzweise die Total Blocking Time. Wer INP wirklich verstehen will, braucht Felddaten. Für kleine Websites ohne ausreichend Chrome-Traffic gilt: Es gibt keine Felddaten, und dann ist ein sauberer Labortest unter gedrosselten Bedingungen die beste verfügbare Näherung.

Und eine Geduldsprobe gehört dazu: Die Felddaten sind ein rollierendes 28-Tage-Fenster. Eine Verbesserung von heute wird frühestens in einigen Wochen vollständig sichtbar.

Ein realistisches Vorgehen

1. Seiten priorisieren: Templates statt Einzelseiten. Eine Korrektur am Artikeltemplate hebt hunderte URLs gleichzeitig.
2. LCP-Element bestimmen – Bild oder Text? Danach richtet sich alles Weitere.
3. Phasen aufschlüsseln und die größte angehen. Ein TTFB von 1,8 s lässt sich nicht mit Bildkompression heilen.
4. INP-Verursacher suchen: Welche Interaktion ist die langsamste? Meist sind es wenige (Menü öffnen, Filtern, Consent-Banner).
5. Nach 28 Tagen nachschauen – und nicht vorher an fünf Stellen gleichzeitig drehen, sonst weiß man hinterher nicht, was gewirkt hat.

Häufige Fehler

• LCP-Bild auf loading="lazy" – verzögert genau das, was zählt.
• Riesiges Heldenbild ohne moderne Kompression und ohne srcset.
• Bild als CSS-Hintergrund, wodurch der Browser es zu spät entdeckt.
• Weiterleitungsketten, die vor dem ersten Byte eine Rundreise kosten.
• Preload ohne crossorigin bei Schriften – die Datei wird doppelt geladen.
• Alles JavaScript sofort laden, auch was warten könnte.
• Drittanbieter-Skripte nie hinterfragen – sie blockieren denselben Thread.
• Nur Lighthouse anschauen und die Felddaten ignorieren.

Häufige Fragen

Warum ist mein Lighthouse-LCP gut, der echte aber schlecht?

Lighthouse misst unter Idealbedingungen an einem Punkt. Echte Besucher haben langsamere Geräte, schlechtere Netze, kalte Caches und kommen über Umleitungen. Maßgeblich sind die Felddaten im 75. Perzentil.

Was bringt bei INP am meisten?

Weniger und kleineres JavaScript sowie das Zerteilen langer Aufgaben. Wenn du nur eine Sache tun kannst: Sieh dir an, was beim ersten Klick alles nachgeladen wird.

Brauche ich preload für mein LCP-Bild?

Meist nicht. Steht das Bild als <img> im HTML, genügt fetchpriority="high". Preload lohnt, wenn das Bild für den Parser unsichtbar ist – etwa als CSS-Hintergrund oder wenn es per Skript eingesetzt wird.

Hilft ein CDN?

Beim TTFB ja, spürbar bei geografisch verteilter Zielgruppe. Es ersetzt aber weder kleine Bilder noch wenig JavaScript – ein CDN liefert dieselben Fehler nur schneller aus.

Zählt INP wirklich erst seit Kurzem?

INP hat im März 2024 die ältere Kennzahl FID abgelöst und misst strenger: alle Interaktionen eines Besuchs statt nur der ersten, und die vollständige Dauer statt nur der Eingabeverzögerung.

Wie viel bringen die Werte fürs Ranking?

Ein moderates Signal, kein Hebel. Der eigentliche Gewinn sind weniger Abbrüche. Die Einordnung steht ausführlich unter Core Web Vitals.

Fazit

LCP verbesserst du in vier Schritten: schnell ausliefern (TTFB unter 800 ms), das wichtigste Bild früh auffindbar machen (fetchpriority, nie „lazy“), es klein halten und nichts davorstellen, was das Rendern blockiert. INP verbesserst du durch weniger JavaScript, das Zerteilen langer Aufgaben und das Muster „erst sichtbar reagieren, dann rechnen“. Gemessen wird im Feld, bewertet im 75. Perzentil – und eine statische, schlanke Seite bringt von beidem viel schon mit.

Quellen

• Optimize Largest Contentful Paint (web.dev – Phasenmodell und Budget-Richtwerte)
• Optimize Interaction to Next Paint (web.dev – Phasen einer Interaktion, Yielding, Rendering-Kosten)