CoreDash Dimension: Urls
Isolieren und beheben Sie Core Web Vitals Performance-Engpässe basierend auf spezifischen Urls
Trusted by market leaders
Dimension: Seite & Navigation: URLs (u)
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 identifiziert, bestimmt die Dimension Elementtyp Ihre übergeordnete Engineering-Strategie. LCP ist die Summe aus 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
Nach der Verbesserung des TTFB, der unabhängig vom LCP Elementtyp ist, sollten Sie einen anderen Ansatz zur Optimierung des LCP wählen, indem Sie Ihre verschiedenen LCP Elemente analysieren.
1. Text
Wenn CoreDash Text als Elementtyp meldet, ist die Bandbreite statischer Netzwerkressourcen selten der Engpass. Text befindet sich direkt im HTML Dokument, was bedeutet, dass der Inhalt sofort nach der ersten Serverantwort (TTFB) verfügbar ist. Wenn Ihr LCP hier langsam ist, liegt das Problem fast ausschließlich am Render Delay.
Um dies zu beheben, konzentrieren Sie sich vollständig auf den Critical Rendering Path. Der Browser wird wahrscheinlich durch umfangreiche CSS Berechnungen oder synchrones JavaScript im <head> am Paint des Textes gehindert. Überprüfen Sie zusätzlich Ihre Font-Loading-Strategie; wenn Sie nicht font-display: swap oder optional verwenden, verbirgt der Browser den Text künstlich (FOIT), während er auf den Download der Font-Datei wartet.
2. Image (<img>)
Dieser Typ löst die vollständige Ressourcen-Pipeline aus: Discovery, Download und Decode. Im Gegensatz zu Text ist ein Image-LCP stark von Load Delay und Load Time abhängig. Hier kämpfen Sie gegen die Physik und Netzwerklatenz, daher ist es Ihr Ziel, das Asset leichter und früher auffindbar zu machen.
Die Optimierung erfordert hier ein striktes Asset-Management. Stellen Sie sicher, dass der <img> Tag im ursprünglichen HTML Quellcode vorhanden ist (Server-Side Rendering), um den Load Delay zu minimieren. Fügen Sie fetchpriority="high" hinzu und entfernen Sie konsequent alle loading="lazy" Attribute, da diese den Request des Browsers verzögern. Minimieren Sie schließlich die Load Time, 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. Background Image
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 verursacht einen massiven Load Delay, da der Preload Scanner das Asset praktisch nicht sieht.
Der einzige robuste Engineering-Fix ist ein Refactoring. Verschieben Sie das visuelle Asset von CSS zu einem Standard-HTML <img> Tag, um die URL für den Browser sofort sichtbar zu machen. 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, obwohl dies im Vergleich zur Verwendung eines nativen Image-Elements oft einen Wartungsaufwand bedeutet.
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 Typ Image, ist aber aufgrund der Dateigröße von Video-Assets oft schwerfälliger.
Behandeln Sie dies strikt als eine Bildoptimierungsaufgabe. Stellen Sie sicher, dass ein leichtgewichtiges Poster-Attribut im HTML vorhanden ist, damit der Browser keine Video-Segmente herunterladen muss, um das erste Pixel zu rendern. Komprimieren Sie das Poster-Bild genauso aggressiv wie ein Standard-LCP Bild.
Workflow: LCP Probleme basierend auf dem LCP Elementtyp finden
Der LCP Elementtyp ist weder statisch noch für jeden Besucher gleich. Er ändert sich häufig basierend auf dem Gerät des Nutzers und offenbart fundamentale Mängel im Responsive Design.
Nutzen Sie den CoreDash Device Form Factor Filter, um die Elementtypen zwischen Mobile und Desktop zu vergleichen. Sie werden oft feststellen, dass Desktop-Nutzer einen Image-LCP erhalten (z. B. einen Hero Banner), während Mobile-Nutzer einen Text-LCP erhalten. Dies bestätigt, dass Ihr mobiles CSS Layout den Hero Banner unter den Fold schiebt oder ihn so stark verkleinert, dass ein Textabsatz zum „größten“ Element wird.
Wenn Sie in diesem Szenario das Hero-Image optimieren, um den mobilen LCP zu verbessern, verschwenden Sie Mühe. Der Browser zählt das Bild nicht einmal. Sie müssen entweder das Layout anpassen, um das Bild wieder in die primäre Ansicht zu bringen, oder Ihren Fokus auf die Optimierung des Text-Renderings (Fonts/CSS) für mobile Nutzer verlagern.
