Largest Contentful Paint verbessern: die langsamste LCP-Phase gezielt beheben

Verbessern Sie Largest Contentful Paint, indem Sie das bestimmende Element identifizieren und messen, was sein Erscheinen verzögert. Trennen Sie bei einem Bild die Wartezeit auf HTML, den verzögerten Anfragestart, den Download und die verbleibende Zeit bis zur Darstellung. Beheben Sie anschließend die tatsächlich langsame Phase, statt alle Bildoptimierungen gleichzeitig anzuwenden.

LCP gilt bei höchstens 2,5 Sekunden am 75. Perzentil als gut. Dieses Ziel beschreibt ein Ergebnis für Besucher. Es verrät noch nicht, ob ein langsamer Server, ein spät entdecktes Foto oder bis zum JavaScript-Ende versteckter Inhalt die Ursache ist.

Finden Sie das Element vor der Änderung der Auslieferung

Zeichnen Sie in Chrome DevTools einen Seitenaufruf mit der relevanten Fenstergröße auf. Prüfen Sie das LCP-Ereignis und das zugehörige Element. Vergleichen Sie es mit dem sichtbaren Inhalt der Aufzeichnung: Während des Ladens kann ein späterer, größerer Kandidat hinzukommen.

Zu den Kandidaten gehören Bilder und Textblöcke, mit zusätzlichen Regeln für Hintergrundbilder und Videos. LCP ist weder einfach der größte DOM-Knoten noch die letzte Netzwerkanfrage. Ein großer leerer Container wird durch seine Abmessungen nicht zu bedeutungsvollem Inhalt.

Wiederholen Sie die Prüfung für relevante Vorlagen und Geräte. Eine Überschrift kann auf Mobilgeräten LCP bestimmen, ein Produktbild auf Desktopgeräten. Auch Experimente oder der Einwilligungsstatus können die sichtbare Seite verändern. Dokumentieren Sie die Bedingungen mit dem Element, damit der nächste Test dasselbe Szenario prüft.

In einem Projekt mit dem Attribution-Build von web-vitals protokolliert dieses Diagnosemodul die Bild-URL und verfügbare Phasenzeiten.

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  console.table({
    lcp: value,
    resource: attribution.url ?? 'Text or no image resource',
    ttfb: attribution.timeToFirstByte,
    loadDelay: attribution.resourceLoadDelay,
    loadDuration: attribution.resourceLoadDuration,
    renderDelay: attribution.elementRenderDelay
  });
});

Das Modul unterstützt Beobachtungen, ist aber kein vollständiger Monitoringdienst. Es benötigt ein installiertes kompatibles Paket und eine Buildumgebung, die die Importe auflöst. Felddatenerfassung braucht zusätzlich einen sorgfältig entworfenen Endpunkt und Aggregation. Prüfen Sie Bibliotheksversion und Attribution-Schnittstelle beim Einbau.

Wählen Sie die erste Maßnahme anhand der vier Phasen

Googles Leitfaden zur LCP-Optimierung zerlegt bildbasierten LCP nach unterschiedlichen Arbeitsarten. Bei textbasiertem LCP gibt es möglicherweise keinen Bilddownload. Erfinden Sie keinen, nur damit der Fall ins Modell passt.

Eine hilfreiche Änderung verkürzt den gesamten Weg bis zum sichtbaren Inhalt. Lädt ein Bild früher fertig, wartet aber auf dieselbe lange Renderingaufgabe, sinkt die Downloadzeit und steigt die anschließende Wartezeit. Der endgültige LCP bleibt nahezu unverändert. Das ist ein konkreter Befund, kein Beweis gegen Bildkomprimierung.

Bewahren Sie die ursprüngliche Aufzeichnung auf. Der Vergleich sollte zeigen, welche Phase sich änderte und ob weiterhin das vorgesehene Element LCP bestimmt. Wird ein anderes Element zum Kandidaten, untersuchen Sie den Wechsel, statt verschiedene Ressourcen kommentarlos zu vergleichen.

Verkürzen Sie die Zeit bis zum HTML

Gewöhnliche Dokumentressourcen kann der Browser erst entdecken, wenn genügend HTML eingetroffen ist. Verfolgen Sie Navigation, Weiterleitungen, Verbindungsaufbau und endgültige Antwort. Eine Weiterleitungskette kann die Entdeckung auch bei schneller Anwendung verzögern.

Vergleichen Sie gecachte und ungecachte Antworten. Eine warme Startseite kann langsame Anwendungsausführung auf seltenen URLs verdecken. Prüfen Sie, ob das CDN HTML oder nur statische Ressourcen speichert und ob Cookies öffentliches Caching unerwartet umgehen.

Machen Sie personalisierte Seiten nicht öffentlich, nur um einen Zeitwert zu verbessern. Caching muss Sitzungen, Berechtigungen und korrekte Inhalte erhalten. Der Leitfaden zur Serverantwortzeit erklärt diese Trennung und die Messung der durch Cache-Treffer vermiedenen Arbeit.

Auch serverseitiges Rendering braucht Kontext. Nutzbares Markup kann clientseitige Entdeckungsarbeit reduzieren, eine teure Renderpipeline aber TTFB erhöhen. Messen Sie Antwort und anschließende Darstellung. Eine schnelle leere Hülle ist nicht das Ziel.

Machen Sie das wichtige Bild sofort auffindbar

Eine Bild-URL im ursprünglichen HTML steht der Ressourcenerkennung des Browsers zur Verfügung. Ein erst durch JavaScript erzeugtes Bild übernimmt diese Abhängigkeit. Ein CSS-Hintergrundbild kann erst nach Empfang und Verarbeitung des Stylesheets entdeckt werden.

Bevorzugen Sie für bedeutungsvolle Inhalte ein gewöhnliches Bildelement, wenn Gestaltung und Semantik dazu passen. Geben Sie passende Alternativtexte und Abmessungen an. Verwenden Sie für das Bild im ersten sichtbaren Bereich nicht allein deshalb loading="lazy", weil andere Medien verzögert laden.

Dieses Beispiel geht von höchstens 960 CSS-Pixeln Bildbreite und einem schmaleren mobilen Layout aus. Die genannten Dateien sind beispielhafte Projektressourcen, die Ihr Build bereitstellen muss.

<img
  src="/images/guide-960.webp"
  srcset="/images/guide-640.webp 640w,
          /images/guide-960.webp 960w,
          /images/guide-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A browser displaying a highlighted content panel"
>

Der Browser wählt anhand von sizes, Kandidatenbreiten und Geräteeigenschaften. sizes muss das tatsächliche Layout beschreiben; es setzt nicht die CSS-Breite. Nimmt das Bild nur eine halbe Spalte ein, kann die Angabe voller Fensterbreite einen unnötig großen Download auslösen.

fetchpriority="high" kennzeichnet eine besonders wichtige Anfrage. Es macht keine verborgene Ressource auffindbar. Viele konkurrierende Bilder mit hoher Priorität schwächen die beabsichtigte Steuerung. Beginnen Sie beim gemessenen LCP-Kandidaten und prüfen Sie anschließend den Wasserfall.

Laden Sie nur bei nachgewiesenem Entdeckungsverzug vor

Preload eignet sich für eine kritische Ressource, die sonst zu spät entdeckt würde. Es ist keine Aufforderung, sämtliche sichtbaren Dateien vor jeder eigenen Browserplanung abzurufen.

Bei einem tatsächlich kritischen CSS-Hintergrund kann ein Bild-Preload die Anfrage vor der Stylesheetverarbeitung starten. Beide Teile verwenden dieselbe URL, damit die Anfrage wiederverwendet werden kann.

<link rel="preload" as="image" href="/images/banner.webp"
      fetchpriority="high">

.banner {
  min-height: 18rem;
  background-image: url('/images/banner.webp');
  background-size: cover;
  background-position: center;
}

Die Abmessungen sind Gestaltungsentscheidungen, keine Leistungsgrenzwerte. Verwenden Sie stattdessen ein semantisches Bildelement, wenn das Motiv Informationen vermittelt, die Alternativtext benötigen.

Responsive Bilder brauchen beim Vorladen eine passende Auswahl. Eine feste Preload-URL kann Bandbreite verschwenden, wenn das Bildelement einen anderen Kandidaten auswählt. Prüfen Sie URLs, Ressourcentypen und Zugangsdatenverhalten. Ähnliche Bildverweise bedeuten nicht automatisch eine einzige Übertragung.

Kontrollieren Sie nach dem Hinweis, ob die nützliche Anfrage früher begann und andere kritische Arbeit verdrängt wurde. Eine Warnung zu ungenutztem Preload verlangt eine Untersuchung der Umsetzung, nicht bloß das Ausblenden der Meldung.

Reduzieren Sie Bildbytes ohne inhaltlichen Qualitätsverlust

Ist die Entdeckung rechtzeitig, prüfen Sie ausgewählte Abmessungen und Übertragungsgröße. Exportieren Sie Varianten für die tatsächliche Fläche und vorgesehene Pixeldichte. Hochauflösende Displays können mehr Bildpixel als CSS-Breite benötigen. Beide Zahlen müssen nicht grundsätzlich identisch sein.

Vergleichen Sie geeignete Formate und Kompressionseinstellungen am konkreten Bild. AVIF oder WebP sind mögliche Optionen, doch Inhalt, Qualitätsbedarf und Kodierung beeinflussen das Ergebnis. Feine Schrift, Diagramme und Fotos reagieren nicht gleich auf Komprimierung.

Prüfen Sie das Ergebnis in Anzeigegröße. Unscharfe Produktdetails, beschädigte Schrift und sichtbare Artefakte sind nicht allein wegen kleinerer Dateien akzeptabel. Bewahren Sie das Original auf und machen Sie Exporte reproduzierbar, damit spätere Bearbeitungen die Optimierung nicht aufheben.

Ein Bild-CDN oder eine CMS-Pipeline kann Varianten automatisieren. Überprüfen Sie dennoch erzeugtes Markup und gewählte Anfrage. Eine Funktion namens responsiv beweist keine Übereinstimmung von sizes und Theme. Der Leitfaden zur Bildoptimierung erläutert Formate und responsive Auszeichnung.

Vergleichen Sie Byteänderungen mit dem Bildersparnis-Rechner. Er schätzt Übertragungsersparnisse anhand Ihrer Eingaben, keine Millisekunden LCP-Verbesserung. Paralleles Laden, Caching und andere Phasen bleiben relevant.

Untersuchen Sie die Lücke zwischen Download und Darstellung

Ist das Bild angekommen, erscheint aber später, suchen Sie die Renderingblockade. Stylesheets könnten noch fehlen, JavaScript den Hauptthread belegen oder eine Komponente bis zu Animation, Initialisierung oder Clientzustand unsichtbar bleiben.

Entfernen Sie unnötige Sichtbarkeitsabhängigkeiten. Ein wichtiges Bild sollte nicht auf fremde Karusselllogik warten, wenn das erste Motiv in normalem HTML darstellbar ist. Prüfen Sie Ladeüberlagerungen über fertigem Inhalt und Eingangsanimationen, die nur die Kennzahl verzögern.

Untersuchen Sie renderblockierendes CSS sorgfältig. Es geht nicht darum, sämtliche Stylesheets zu entfernen oder alle Stile zu verschieben. Der erste sichtbare Bereich braucht korrekte Regeln gegen Aufblitzen und Bewegungen. Ermitteln Sie ungenutzte oder unkritische Ressourcen und erhalten Sie notwendige Stile.

Hauptthreadarbeit kann Rendering auch nach fertigem Netzwerktransfer verzögern. Suchen Sie große Skripte, Hydration und synchrone Initialisierung um den relevanten Zeitpunkt. Der Leitfaden zu renderblockierenden Ressourcen unterscheidet leicht verwechselbare Entdeckungs- und Ausführungsabhängigkeiten.

Untersuchen Sie bei textbasiertem LCP Schriften und Textsichtbarkeit. Ein Fontabruf beeinflusst möglicherweise den Überschriftzeitpunkt, Ersatzschriftmetriken das Layout. Alle Schriften vorzuladen ist nicht automatisch richtig: Sie können dringendere Ressourcen verdrängen.

Prüfen Sie die tatsächlich ausgelieferten Varianten

Testen Sie lange und kurze Überschriften sowie Artikel mit und ohne Hauptbild. Beziehen Sie Einwilligung, Werbung und Sprache ein, wenn sie das sichtbare Layout verändern. Gemeinsamer Code kann je nach Inhalt verschiedene LCP-Kandidaten erzeugen.

Ein schmales Fenster kann das Desktopbild beschneiden oder verbergen, während es wegen widersprüchlichem Markup und CSS weiter heruntergeladen wird. Umgekehrt kann ein mobiles Bild zu spät angefordert werden, wenn ein Skript es erst nach dem Start auswählt. Prüfen Sie tatsächliche Anfragen, nicht allein die fertige Seite.

In Sprachfassungen können Schriftabdeckung und Zeilenumbrüche Kandidat und Renderingabhängigkeiten ändern. Verwenden Sie dieselbe Diagnose je Ausgabe, statt eine englische Verbesserung als Beweis für alle Sprachen zu betrachten.

Prüfen Sie eine Hypothese mit vergleichbarer Aufzeichnung

Formulieren Sie vor dem Bearbeiten die Hypothese, etwa dass eine Komponente das LCP-Bild erst nach der Initialisierung einfügt. Nehmen Sie die kleinste Änderung vor, die diese Erklärung prüft, und zeichnen Sie dasselbe Szenario erneut auf.

Vergleichen Sie Ressourcenstart, Übertragungsende, Darstellung und gesamten LCP. Wiederholen Sie mit gleichen Fenster-, Drosselungs- und Cachebedingungen. Halten Sie Fehler sichtbar: Eine wichtige ausgefallene Funktion kann die Seite aus dem falschen Grund schneller wirken lassen.

Prüfen Sie nach Veröffentlichung Nutzerdaten über deren Erfassungsfenster. Feld-LCP kann durch Geräte, Verbindungen, Region und Navigation vom Laborszenario abweichen. Eine Laborverbesserung ist hilfreich, ersetzt aber das Feldergebnis nicht.

Machen Sie das Ergebnis wartbar

Dokumentieren Sie relevantes Element, Entdeckungsweg und beabsichtigte Optimierung. Eine kurze Notiz kann verhindern, dass ein Bildplugin Lazy Loading wieder aktiviert oder ein Redesign die Fläche ohne Anpassung von sizes verändert.

Behalten Sie eine repräsentative Seite, den erwarteten Bildkandidaten, Entdeckungsweg und gespeicherten Trace in Ihrer Prüfroutine. Nutzen Sie die Core-Web-Vitals-Referenzleitfäden, wenn eine andere Kennzahl begrenzt. Die nächste Aufgabe sollte aus der nächsten gemessenen Verzögerung folgen, nicht aus einem weiteren allgemeinen Optimierungsschalter.