Core/Dash-dimensjon: Elementtype (LCP)
Fiks Largest Contentful Paint ved å filtrere trafikk basert på den arkitektoniske elementtypen.
Trusted by market leaders · Client results
Dimensjon: Ressurs: Elementtype LCP (lcpet)
Dimensjonen elementtype (LCP) (lcpet) kategoriserer Largest Contentful Paint-noden i én av fire arkitektoniske klasser: text, image, background-image eller video.
Mens dimensjonen Attribution Element peker ut den nøyaktige DOM-noden, dikterer dimensjonen for elementtype den overordnede tekniske strategien din. LCP er summen av fire tidsintervaller: TTFB, lasteforsinkelse (Load Delay), lastetid (Load Time) og renderingsforsinkelse (Render Delay). Elementtypen forteller deg hvilket av disse intervallene som ødelegger poengsummen din, slik at du kan velge riktig optimaliseringsprotokoll uten å gjette.
Optimalisere Core Web Vitals etter LCP-elementtype
Etter å ha forbedret TTFB-en, som er uavhengig av LCP-elementtypen, bør du ta en annen tilnærming til å optimalisere LCP-en ved å se på LCP-elementtypen din.
1. Tekst
Når CoreDash rapporterer tekst som elementtype, er båndbredden for statiske nettverksressurser sjelden flaskehalsen. Tekst ligger direkte i HTML-dokumentet, noe som betyr at innholdet er tilgjengelig umiddelbart etter det første serversvaret (TTFB). Hvis LCP-en din er treg her, skyldes problemet nesten utelukkende renderingsforsinkelse (Render Delay).
For å fikse dette må du fokusere utelukkende på den kritiske renderingsveien (Critical Rendering Path). Nettleseren blokkeres sannsynligvis fra å tegne teksten av tunge CSS-beregninger eller synkron JavaScript i <head>. Sjekk også strategien din for fontlasting. Hvis du ikke bruker font-display: swap eller optional, vil nettleseren skjule teksten kunstig (FOIT) mens den venter på at fontfilen skal lastes ned.
2. Bilde (<img>)
Denne typen utløser hele ressurspipelinen: oppdagelse, nedlasting og dekoding. I motsetning til tekst er en bilde-LCP sterkt avhengig av lasteforsinkelse (Load Delay) og lastetid (Load Time). Her kjemper du mot fysikk og nettverkslatens, så målet ditt er å gjøre ressursen lettere og oppdagbar tidligere.
Optimalisering her krever streng ressursstyring. Sørg for at <img>-taggen finnes i den opprinnelige HTML-kildekoden (Server-Side Rendering) for å minimere lasteforsinkelsen (Load Delay). Legg til fetchpriority="high" og fjern alle loading="lazy"-attributter konsekvent, da disse forsinker nettleserens forespørsel. Til slutt takler du lastetiden (Load Time) ved å levere neste-generasjons formater (AVIF/WebP) og bruke srcset for å forhindre at mobilenheter laster ned filer i desktop-størrelse.
3. Bakgrunnsbilde
Denne klassifiseringen signaliserer en arkitektonisk ineffektivitet. Fordi bildet er definert i CSS (f.eks. background-image: url(...)), kan ikke nettleseren oppdage URL-en før den har lastet ned og parsert stilarkene dine fullstendig. Dette skaper en enorm lasteforsinkelse (Load Delay) fordi Preload Scanner i praksis er blind for ressursen.
Den eneste robuste tekniske løsningen er refaktorering. Flytt den visuelle ressursen fra CSS til en standard HTML-<img>-tagg for å eksponere URL-en for nettleseren umiddelbart. Hvis du ikke kan refaktorere markupen, må du bruke <link rel="preload"> i dokumentets head for å tvinge frem tidlig oppdagelse, selv om dette ofte er en vedlikeholdsbyrde sammenlignet med å bruke et standard bildeelement.
4. Video
Når LCP-elementet er en video, måler nettleseren tegnetiden for poster-bildet eller den første bilderammen (hvis den spilles av automatisk). Dette fungerer på samme måte som bilde-typen, men er ofte tyngre på grunn av filstørrelsen til videoressursene.
Behandle dette utelukkende som en bildeoptimaliseringsoppgave. Sørg for at et lett poster-attributt er til stede i HTML-koden, slik at nettleseren slipper å laste ned videosegmenter for å rendre den første pikselen. Komprimer poster-bildet like aggressivt som du ville gjort med et standard LCP-bilde.
Arbeidsflyt: finne LCP-problemer basert på LCP-elementtype
LCP-elementtypen er verken statisk eller lik for alle besøkende. Den endres ofte basert på brukerens enhet, noe som avslører grunnleggende svakheter i det responsive designet.
Bruk CoreDash-filteret for enhetsformfaktor (Device Form Factor) til å sammenligne elementtyper mellom mobil og desktop. Du vil ofte oppdage at desktop-brukere får en bilde-LCP (f.eks. et hero-banner), mens mobilbrukere får en tekst-LCP. Dette bekrefter at det mobile CSS-oppsettet ditt skyver hero-banneret under bretten (below the fold), eller skalerer det så mye ned at et tekstavsnitt blir det «største» elementet.
Hvis du optimaliserer hero-bildet for å forbedre mobil LCP i dette scenariet, kaster du bort krefter. Nettleseren teller ikke engang bildet. Du må enten justere oppsettet for å bringe bildet tilbake i det primære visningsfeltet, eller flytte fokuset to å optimalisere tekstrenderingen (fonter/CSS) for mobilbrukere.
