Core/Dash Dimension: URL:er
Isolera och åtgärda prestandaflaskhalsar för Core Web Vitals via specifika URL:er
Trusted by market leaders
Dimension: Sida & Navigering: URL:er (u)
Dimensionen Elementtyp (LCP) (lcpet) kategoriserar noden för Largest Contentful Paint i en av fyra arkitektoniska klasser: text, image, background-image eller video.
Medan dimensionen Attribution Element pekar ut den exakta DOM-noden, dikterar dimensionen Elementtyp din övergripande tekniska strategi. LCP är summan av fyra tidsintervall: TTFB, Load Delay, Load Time och Render Delay. Elementtypen talar om för dig vilket av dessa intervall som skadar ditt resultat, vilket låter dig välja rätt optimeringsprotokoll utan att gissa.
Optimera Core Web Vitals efter LCP-elementtyp
Efter att ha förbättrat TTFB, som är oberoende av LCP-elementtypen, bör du anta ett annat tillvägagångssätt för att optimera LCP genom att titta på ditt specifika LCP-element.
1. Text
När CoreDash rapporterar text som Elementtyp är bandbredden för statiska nätverksresurser sällan flaskhalsen. Text ligger direkt i HTML-dokumentet, vilket innebär att innehållet är tillgängligt omedelbart efter den initiala serverresponsen (TTFB). Om din LCP är långsam här är problemet nästan uteslutande Render Delay.
För att åtgärda detta, fokusera helt på Critical Rendering Path. Webbläsaren blockeras sannolikt från att måla texten av tunga CSS-beräkningar eller synkron JavaScript i <head>. Kontrollera dessutom din strategi för typsnittsladdning; om du inte använder font-display: swap eller optional, döljer webbläsaren texten artificiellt (FOIT) medan den väntar på att typsnittsfilen ska laddas ner.
2. Bild (<img>)
Denna typ utlöser hela resurspipelinen: upptäckt, nedladdning och avkodning. Till skillnad från text är en bild-LCP starkt beroende av Load Delay och Load Time. Du kämpar mot fysik och nätverkslatens här, så ditt mål är att göra tillgången lättare och upptäckbar tidigare.
Optimering här kräver strikt resurshantering. Säkerställ att <img>-taggen finns i den initiala HTML-källkoden (Server-Side Rendering) för att minimera Load Delay. Lägg till fetchpriority="high" och ta strikt bort alla loading="lazy"-attribut, eftersom dessa fördröjer webbläsarens begäran. Slutligen, hantera Load Time genom att servera nästa generations format (AVIF/WebP) och använda srcset för att förhindra mobila enheter från att ladda ner filer i desktop-storlek.
3. Bakgrundsbild
Denna klassificering signalerar en arkitektonisk ineffektivitet. Eftersom bilden definieras i CSS (t.ex. background-image: url(...)), kan webbläsaren inte upptäcka URL:en förrän den helt har laddat ner och parsat dina stilmallar. Detta skapar en massiv Load Delay eftersom Preload Scanner i praktiken är blind för tillgången.
Den enda robusta tekniska lösningen är refaktorisering. Flytta den visuella tillgången från CSS till en standard HTML <img>-tagg för att exponera URL:en för webbläsaren omedelbart. Om du inte kan refaktorisera koden måste du använda <link rel="preload"> i dokumentets head för att tvinga fram tidig upptäckt, även om detta ofta är en underhållsbörda jämfört med att använda ett inbyggt bildelement.
4. Video
När LCP-elementet är en video mäter webbläsaren utritningstiden för poster-bilden eller den första bildrutan (vid autoplay). Detta beter sig liknande bildtypen men är ofta tyngre på grund av videofilernas storlek.
Behandla detta strikt som en bildoptimeringsuppgift. Se till att ett lättviktigt poster-attribut finns i HTML:en så att webbläsaren inte behöver ladda ner videosegment för att rendera den första pixeln. Komprimera poster-bilden lika aggressivt som du skulle göra med en standard LCP-bild.
Arbetsflöde: hitta LCP-problem baserat på LCP-elementtyp
LCP-elementtypen är varken statisk eller densamma för varje besökare. Den ändras ofta baserat på användarens enhet, vilket avslöjar grundläggande brister i responsiv design.
Använd CoreDash-filtret Device Form Factor för att jämföra elementtyper mellan mobil och desktop. Du kommer ofta att upptäcka att desktop-användare får en bild-LCP (t.ex. en Hero Banner), medan mobilanvändare får en text-LCP. Detta bekräftar att din mobila CSS-layout trycker ner Hero Bannern below the fold eller skalar ner den så kraftigt att ett textstycke blir det "största" elementet.
Om du optimerar hero-bilden för att förbättra mobil LCP i detta scenario slösar du bort din tid. Webbläsaren räknar inte ens med bilden. Du måste antingen justera layouten för att föra tillbaka bilden till den primära vyn eller flytta fokus till att optimera textrendering (typsnitt/CSS) för mobilanvändare.
