LCP-Bilder verbessern: Engpass messen statt blind komprimieren

Das LCP-Element wirklich bestimmen

Das größte sichtbare Element kann ein Bild, ein Textblock oder je nach Seitenzustand ein anderes Element sein. Beginnen Sie deshalb mit einer konkreten URL und einem dokumentierten mobilen beziehungsweise Desktop-Test. Die Annahme, das Titelbild müsse immer der LCP-Kandidat sein, kann die Arbeit auf das falsche Problem lenken.

Notieren Sie Viewport, Gerät beziehungsweise Testprofil, Zeitpunkt und das identifizierte Element. Laborwerte helfen bei der Diagnose unter kontrollierten Bedingungen. Verfügbare Felddaten beschreiben dagegen reale Nutzung über ihren jeweiligen Erfassungszeitraum. Stellen Sie beide nebeneinander, ohne einen einzelnen Labortest als vollständigen Nutzerbeleg auszugeben.

Die Verzögerung in sinnvolle Abschnitte zerlegen

Die web.dev-Dokumentation unterscheidet bei bildbasiertem LCP unter anderem Antwortzeit, Verzögerung bis zum Ressourcenstart, eigentliche Übertragung und Verzögerung bis zur Darstellung. Diese Zerlegung ist praktisch: Ein kleineres Bild verkürzt nicht automatisch eine späte Entdeckung oder eine blockierte Darstellung.

Liegt das wichtigste Bild bereits im anfänglichen HTML, kann der Browser es früher erkennen als bei einer spät eingefügten JavaScript-Konstruktion. Prüfen Sie außerdem, ob ein Lazy-Loading-Mechanismus gerade das sofort benötigte Bild zurückhält. Verwenden Sie Priorisierung gezielt für den tatsächlichen Kandidaten, statt allen Bildern gleichermaßen hohe Priorität zu geben.

Die passende Grundlage erläutert Bild-SEO: Dateinamen, Alt-Texte und Bildkontext.

Entscheidungen am konkreten Befund festmachen

Den LCP-Befund vor und nach einer Einzeländerung festhalten

Erstellen Sie eine Messzeile mit URL, Viewport, Testprofil, LCP-Element und dominierender Ladephase. Ergänzen Sie die tatsächlich geladene Bildadresse, Bildabmessungen und den Start der Anforderung. Ändern Sie zuerst nur den untersuchten Engpass, damit das Ergebnis interpretierbar bleibt. Wird die Datei kleiner, aber ihr Start bleibt verspätet, dokumentieren Sie beide Beobachtungen statt die Hypothese nachträglich umzudeuten. Halten Sie außerdem fest, ob Felddaten vorhanden sind. „Keine Daten“ ist keine gute oder schlechte gemessene Nutzererfahrung, sondern eine fehlende Grundlage für genau diese Aussage.

Praxisfall: neue Kompression ohne messbaren Nutzen

Ein fiktives Team halbiert die Dateigröße des Titelbilds, sieht im gleichen Laborprofil aber kaum eine Verbesserung. Die Ressourcenansicht zeigt: Der Download beginnt weiterhin erst nach einem Skriptablauf. Die erste Maßnahme hat einen realen Übertragungsvorteil, aber den dominierenden Engpass nicht beseitigt.

Als nächste Änderung macht das Team die Bildressource früh erkennbar und prüft den Kandidaten erneut. Beide Änderungen werden getrennt dokumentiert. So bleibt nachvollziehbar, welche Hypothese untersucht wurde. Aus dem Beispiel folgt kein allgemein gültiger Zeitgewinn; er muss an der konkreten Seite tatsächlich gemessen werden.

Bildqualität, passende Abmessungen und Wiederholungen prüfen

Liefern Sie passend zur Darstellung geeignete responsive Größen. Ein unnötig großes Bild verschwendet Übertragungsvolumen; ein zu kleines Bild verliert sichtbare Qualität. Prüfen Sie neben Dateigröße auch srcset, sizes, Seitenverhältnis und die tatsächlich gewählte Ressource im jeweiligen Viewport.

Vergleichen Sie mehrere Messungen unter gleichen Bedingungen und notieren Sie geänderte Randbedingungen. Kontrollieren Sie anschließend, ob Lesbarkeit, Bildaussage oder andere wichtige Ressourcen leiden. Eine Leistungsmaßnahme ist erst abgenommen, wenn der technische Befund verbessert wurde und die Seite weiterhin in ihrem freigegebenen Design funktioniert.

Die passende Grundlage erläutert Core Web Vitals im Content-Prozess berücksichtigen.

Häufige Fragen.