Core/Dash-Dimension: Elementtyp (LCP)
Behebe Probleme mit dem Largest Contentful Paint, indem du den Traffic nach dem architektonischen Elementtyp filterst.
Trusted by market leaders · Client results
Dimension: Ressource: Elementtyp LCP (lcpet)
Die Dimension „Elementtyp (LCP)“ (lcpet) kategorisiert den Largest Contentful Paint-Knoten in eine von vier architektonischen Klassen: text, image, background-image oder video.
Während die Dimension Attribution-Element den exakten DOM-Knoten bestimmt, gibt die Dimension „Elementtyp“ deine übergeordnete technische Strategie vor. Der LCP ist die Summe aus vier Zeitintervallen: TTFB, Ladeverzögerung, Ladezeit und Renderverzögerung. Der Elementtyp verrät dir, welches dieser Intervalle deinen Wert verschlechtert. So kannst du ohne Rätselraten das richtige Optimierungsprotokoll auswählen.
Optimierung der Core Web Vitals nach LCP-Elementtyp
Die TTFB-Verbesserung ist unabhängig vom LCP-Elementtyp. Danach erfordert die LCP-Optimierung einen anderen Ansatz: Schau auf deinen LCP-Elementtyp.
1. Text
Wenn CoreDash „text“ als Elementtyp meldet, ist die Bandbreite für statische Netzwerkressourcen selten der Flaschenhals. Text befindet sich direkt im HTML-Dokument. Der Inhalt ist also sofort nach der ersten Serverantwort (TTFB) verfügbar. Wenn dein LCP hier langsam ist, liegt das fast ausschließlich an der Renderverzögerung.
Konzentriere dich zur Behebung vollständig auf den Critical Rendering Path. Der Browser wird wahrscheinlich durch rechenintensive CSS-Berechnungen oder synchrones JavaScript im <head> beim Rendern des Textes blockiert. Prüfe außerdem deine Font-Loading-Strategie. Wenn du nicht font-display: swap oder optional nutzt, versteckt der Browser den Text künstlich (FOIT), während er auf den Download der Schriftdatei wartet.
2. Bild (<img>)
Dieser Typ stößt die komplette Ressourcen-Pipeline an: Erkennung, Download und Dekodierung. Im Gegensatz zu Text hängt ein Bild-LCP stark von Ladeverzögerung und Ladezeit ab. Du kämpfst hier gegen Physik und Netzwerklatenz. Mach das Asset leichter und sorge dafür, dass es früher entdeckt wird.
Die Optimierung erfordert hier ein striktes Asset-Management. Stelle sicher, dass das <img>-Tag im initialen HTML-Quellcode (Server-Side Rendering) vorhanden ist, um die Ladeverzögerung zu minimieren. Füge fetchpriority="high" hinzu und entferne konsequent alle loading="lazy"-Attribute, da diese die Anfrage des Browsers verzögern. Gehe schließlich die Ladezeit an. Liefere Next-Gen-Formate (AVIF/WebP) aus und nutze srcset, um zu verhindern, dass Mobilgeräte Bilder in Desktop-Größe herunterladen.
3. Hintergrundbild
Diese Klassifizierung signalisiert eine architektonische Ineffizienz. Da das Bild im CSS definiert ist (z. B. background-image: url(...)), kann der Browser die URL erst entdecken, wenn er deine Stylesheets vollständig heruntergeladen und geparst hat. Das führt zu einer massiven Ladeverzögerung, da der Preload-Scanner für das Asset blind ist.
Die einzige robuste technische Lösung ist ein Refactoring. Verschiebe das visuelle Asset aus dem CSS in ein Standard-HTML-<img>-Tag, um die URL für den Browser sofort sichtbar zu machen. Wenn du das Markup nicht anpassen kannst, musst du <link rel="preload"> im Head-Bereich des Dokuments nutzen, um eine frühe Erkennung zu erzwingen. Im Vergleich zu einem nativen Bild-Element erhöht dies jedoch oft den Wartungsaufwand.
4. Video
Wenn das LCP-Element ein Video ist, misst der Browser die Paint-Zeit des Poster-Bildes oder des ersten Frames (bei Autoplay). Das verhält sich ähnlich wie beim Bild-Typ, ist aber wegen der Dateigröße von Video-Assets oft schwerer.
Behandle dies strikt als Bildoptimierung. Sorge für ein leichtes poster-Attribut im HTML, damit der Browser keine Videosegmente herunterladen muss, um das erste Pixel darzustellen. Komprimiere das Poster-Bild genauso aggressiv wie ein normales LCP-Bild.
Workflow: LCP-Probleme anhand des LCP-Elementtyps finden
Der LCP-Elementtyp ist weder statisch noch für jeden Besucher gleich. Er ändert sich häufig je nach Gerät des Nutzers und offenbart so grundlegende Schwächen im Responsive Design.
Nutze den CoreDash-Filter „Device Form Factor“, um die Elementtypen zwischen Mobil- und Desktop-Geräten zu vergleichen. Oft wirst du feststellen, dass Desktop-Nutzer einen Bild-LCP haben (z. B. einen Hero-Banner), während Mobilnutzer einen Text-LCP erhalten. Dies bestätigt, dass dein mobiles CSS-Layout den Hero-Banner aus dem direkt sichtbaren Bereich verschiebt oder ihn so stark verkleinert, dass ein Textabsatz zum „größten“ Element wird.
Wenn du in diesem Szenario das Hero-Bild optimierst, um den mobilen LCP zu verbessern, ist das verschwendete Mühe. Der Browser berücksichtigt das Bild nicht einmal. Passe entweder das Layout an, um das Bild wieder in den primären Sichtbereich zu bringen, oder fokussiere dich auf die Optimierung des Text-Renderings (Fonts/CSS) für mobile Nutzer.
