Core/Dash Dimension: Element Type (LCP)
Beheben Sie den Largest Contentful Paint, indem Sie den Traffic basierend auf dem architektonischen Elementtyp filtern.
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 lokalisiert, bestimmt die Dimension Elementtyp Ihre übergeordnete Engineering-Strategie. LCP ist die Summe von vier Zeitintervallen: TTFB, Load Delay, Load Time und Render Delay. Der Elementtyp zeigt Ihnen, welches dieser Intervalle Ihren Score verschlechtert, sodass Sie das richtige Optimierungsprotokoll ohne Raten auswählen können.
Optimierung der Core Web Vitals nach LCP-Elementtyp
Nachdem Sie die TTFB verbessert haben, die unabhängig vom LCP-Elementtyp ist, sollten Sie einen anderen Ansatz zur Optimierung des LCP wählen, indem Sie Ihren LCP-Elementtyp betrachten.
1. Text
Wenn CoreDash Text als Elementtyp meldet, ist die statische Netzwerkressourcen-Bandbreite selten der Engpass. Text befindet sich direkt im HTML-Dokument, was bedeutet, dass der Inhalt sofort nach der anfänglichen Serverantwort (TTFB) verfügbar ist. Wenn Ihr LCP hier langsam ist, liegt das Problem fast ausschließlich beim Render Delay.
Um dies zu beheben, konzentrieren Sie sich vollständig auf den Critical Rendering Path. Der Browser wird wahrscheinlich durch rechenintensive CSS-Kalkulationen oder synchrones JavaScript im <head> daran gehindert, den Text zu rendern. Überprüfen Sie außerdem Ihre Strategie zum Laden von Schriftarten; wenn Sie nicht font-display: swap oder optional verwenden, versteckt der Browser den Text künstlich (FOIT), während er auf den Download der Schriftartdatei wartet.
2. Bild (<img>)
Dieser Typ löst die vollständige Ressourcen-Pipeline aus: Discovery, Download und Decode. Im Gegensatz zu Text hängt ein Bild-LCP stark von Load Delay und Load Time ab. Sie kämpfen hier gegen Physik und Netzwerklatenz, Ihr Ziel ist es also, das Asset leichter und schneller auffindbar zu machen.
Die Optimierung erfordert hier striktes Asset-Management. Stellen Sie sicher, dass das <img>-Tag im anfänglichen HTML-Quellcode (Server-Side Rendering) vorhanden ist, um das Load Delay zu minimieren. Fügen Sie fetchpriority="high" hinzu und entfernen Sie konsequent alle loading="lazy"-Attribute, da diese die Anfrage des Browsers verzögern. Gehen Sie schließlich die Load Time an, indem Sie Next-Gen-Formate (AVIF/WebP) bereitstellen und srcset verwenden, um zu verhindern, dass mobile Geräte Dateien in Desktop-Größe herunterladen.
3. Hintergrundbild
Diese Klassifizierung signalisiert eine architektonische Ineffizienz. Da das Bild in CSS definiert ist (z. B. background-image: url(...)), kann der Browser die URL erst entdecken, wenn er Ihre Stylesheets vollständig heruntergeladen und geparst hat. Dies erzeugt ein massives Load Delay, da der Preload Scanner das Asset praktisch nicht sehen kann.
Die einzige robuste technische Lösung ist Refactoring. Verschieben Sie das visuelle Asset von CSS in ein standardmäßiges HTML-<img>-Tag, um die URL dem Browser sofort offenzulegen. Wenn Sie das Markup nicht umstrukturieren können, müssen Sie <link rel="preload"> im Document Head verwenden, um eine frühe Entdeckung zu erzwingen, was jedoch im Vergleich zur Verwendung eines nativen Bildelements oft ein Wartungsaufwand ist.
4. Video
Wenn das LCP-Element ein Video ist, misst der Browser die Paint-Zeit des Poster-Bildes oder des ersten Frames (bei Autoplay). Dies verhält sich ähnlich wie der Bild-Typ, ist jedoch aufgrund der Dateigröße von Video-Assets oft schwerer.
Behandeln Sie dies strikt als Aufgabe zur Bildoptimierung. Stellen Sie sicher, dass ein leichtgewichtiges Poster-Attribut im HTML vorhanden ist, damit der Browser keine Videosegmente herunterladen muss, um das erste Pixel zu rendern. Komprimieren Sie das Poster-Bild so aggressiv, wie Sie es bei einem Standard-LCP-Bild tun würden.
Workflow: Finden von LCP-Problemen basierend auf dem LCP-Elementtyp
Der LCP-Elementtyp ist weder statisch noch für jeden Besucher gleich. Er ändert sich häufig basierend auf dem Gerät des Benutzers und deckt grundlegende Fehler im Responsive Design auf.
Verwenden Sie den CoreDash-Filter für den Formfaktor des Geräts (Device Form Factor), um Elementtypen zwischen Mobile und Desktop zu vergleichen. Sie werden oft feststellen, dass Desktop-Benutzer einen Bild-LCP (z. B. ein Hero-Banner) erhalten, während mobile Benutzer einen Text-LCP haben. Dies bestätigt, dass Ihr mobiles CSS-Layout das Hero-Banner in den nicht sichtbaren Bereich (below the fold) schiebt oder es so stark herunterskaliert, dass ein Textabsatz zum "größten" Element wird.
Wenn Sie in diesem Szenario das Hero-Bild optimieren, um den mobilen LCP zu verbessern, verschwenden Sie Ihre Zeit. Der Browser zählt das Bild nicht einmal. Sie müssen entweder das Layout anpassen, um das Bild wieder in den primären Sichtbereich zu bringen, oder Ihren Fokus auf die Optimierung des Text-Renderings (Schriftarten/CSS) für mobile Benutzer verlagern.
