Core/Dash-dimension: Elementtyp (LCP)
Åtgärda Largest Contentful Paint genom att filtrera trafik baserat på arkitektonisk elementtyp.
Trusted by market leaders · Client results
Dimension: Resurs: Elementtyp LCP (lcpet)
Dimensionen Elementtyp (LCP) (lcpet) kategoriserar Largest Contentful Paint-noden i en av fyra arkitektoniska klasser: text, image, background-image eller video.
Medan dimensionen Attribution Element pekar ut den exakta DOM-noden, styr dimensionen Elementtyp din övergripande tekniska strategi. LCP är summan av fyra tidsintervall: TTFB, laddningsfördröjning, laddningstid och renderingsfördröjning. Elementtypen talar om vilket av dessa intervall som skadar ditt resultat, vilket gör att du kan välja rätt optimeringsprotokoll utan att gissa.
Optimera Core Web Vitals baserat på LCP-elementtyp
Efter att du har förbättrat TTFB, som är oberoende av LCP-elementtypen, bör du optimera LCP på ett annat sätt. Titta på din LCP-elementtyp.
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 direkt efter det första serversvaret (TTFB). Om din LCP är långsam här beror problemet nästan uteslutande på renderingsfördröjning.
För att åtgärda detta, fokusera helt på den kritiska renderingssökvägen. Webbläsaren blockeras troligen från att rita ut texten av tunga CSS-beräkningar eller synkron JavaScript i <head>. Kontrollera även din strategi för laddning av typsnitt. Om du inte använder font-display: swap eller optional döljer webbläsaren texten på konstgjord väg (FOIT) medan typsnittsfilen laddas ner.
2. Bild (<img>)
Denna typ triggar hela resurspipelinen: upptäckt, nedladdning och avkodning. Till skillnad från text är en bild-LCP starkt beroende av laddningsfördröjning och laddningstid. Här kämpar du mot fysik och nätverkslatens. Ditt mål är att göra resursen lättare och upptäckbar tidigare.
Optimering här kräver strikt resurshantering. Se till att taggen <img> finns i den ursprungliga HTML-källkoden (Server-Side Rendering) för att minimera laddningsfördröjningen. Lägg till fetchpriority="high" och ta helt bort alla loading="lazy"-attribut, eftersom dessa fördröjer webbläsarens förfrågan. Hantera slutligen laddningstiden genom att servera nästa generations format (AVIF/WebP) och använda srcset så att mobila enheter slipper ladda ner filer i skrivbordsstorlek.
3. Bakgrundsbild
Den här klassificeringen 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 har laddat ner och tolkat dina stilmallar helt. Detta skapar en enorm laddningsfördröjning eftersom Preload Scanner i praktiken är blind för resursen.
Den enda robusta tekniska lösningen är refaktorering. Flytta den visuella resursen från CSS till en vanlig HTML-tagg <img> för att exponera URL:en för webbläsaren direkt. Om du inte kan refaktorera HTML-koden måste du använda <link rel="preload"> i dokumentets head för att tvinga fram tidig upptäckt. Detta är dock ofta en underhållsbörda jämfört med att använda ett inbyggt bild-element.
4. Video
När LCP-elementet är en video mäter webbläsaren renderingstiden för poster-bilden eller den första bildrutan (om den spelas upp automatiskt). Detta fungerar ungefär som för bild-typen, men är ofta tyngre på grund av videofilernas filstorlek.
Hantera detta strikt som en bildoptimering. Se till att ett lättviktigt poster-attribut finns i HTML-koden så att webbläsaren slipper ladda ner videosegment för att rendera den första pixeln. Komprimera poster-bilden lika aggressivt som du skulle göra med en vanlig LCP-bild.
Arbetsflöde: Hitta LCP-problem baserat på LCP-elementtyp
LCP-elementtypen är varken statisk eller densamma för alla besökare. Den ändras ofta beroende på användarens enhet, vilket avslöjar grundläggande brister i din responsiva design.
Använd CoreDash-filtret Device Form Factor för att jämföra elementtyper mellan mobil och dator. Du kommer ofta upptäcka att datoranvändare får en bild-LCP (t.ex. en hero-banner), medan mobilanvändare får en text-LCP. Detta bekräftar att din CSS-layout för mobiler skjuter ner din hero-banner under skärmkanten eller skalar ner den så pass mycket att ett textstycke blir det ”största” elementet.
Om du optimerar hero-bilden för att förbättra mobil LCP i det här scenariot slösar du bara tid. Webbläsaren räknar inte ens med bilden. Du måste antingen justera layouten för att få tillbaka bilden i den primära vyn, eller flytta ditt fokus till att optimera textrenderingen (typsnitt/CSS) för mobilanvändare.
