Core/Dash Dimensjon: URL-er
Isoler og fiks Core Web Vitals ytelsesflaskehalser ved spesifikke URL-er
Trusted by market leaders
Dimensjon: Side & Navigasjon: URL-er (u)
Dimensjonen Elementtype (LCP) (lcpet) kategoriserer noden for Largest Contentful Paint i en av fire arkitektoniske klasser: text, image, background-image eller video.
Mens Attribution Element-dimensjonen peker ut den nøyaktige DOM-noden, dikterer dimensjonen Elementtype din overordnede tekniske strategi. LCP er summen av fire tidsintervaller: TTFB, Lasteforsinkelse, Lastetid og Renderingsforsinkelse. Elementtypen forteller deg hvilket av disse intervallene som skader poengsummen din, slik at du kan velge riktig optimaliseringsprotokoll uten å gjette.
Optimalisering av Core Web Vitals etter LCP-elementtype
Etter å ha forbedret TTFB, som er uavhengig av LCP-elementtypen, bør du velge en annen tilnærming for å optimalisere LCP ved å se på ditt LCP-element.
1. Tekst
Når CoreDash rapporterer tekst som Elementtype, er båndbredde for statiske nettverksressurser sjelden flaskehalsen. Tekst ligger direkte i HTML-dokumentet, noe som betyr at innholdet er tilgjengelig umiddelbart etter den første serverresponsen (TTFB). Hvis din LCP er treg her, er problemet nesten utelukkende Renderingsforsinkelse.
For å fikse dette, fokuser utelukkende på Critical Rendering Path. Nettleseren er sannsynligvis blokkert fra å tegne teksten av tunge CSS-beregninger eller synkron JavaScript i <head>. Sjekk i tillegg strategien for lasting av fonter; hvis du ikke bruker font-display: swap eller optional, skjuler nettleseren 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 og Lastetid. 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-kilden (Server-Side Rendering) for å minimere Lasteforsinkelse. Legg til fetchpriority="high" og fjern strengt alle loading="lazy"-attributter, da disse forsinker nettleserens forespørsel. Til slutt, takle Lastetid ved å servere neste generasjons formater (AVIF/WebP) og bruke srcset for å forhindre at mobile enheter 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 parset stilarkene dine fullstendig. Dette skaper en massiv Lasteforsinkelse fordi Preload Scanner effektivt 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 dokumenthodet for å tvinge frem tidlig oppdagelse, selv om dette ofte er en vedlikeholdsbyrde sammenlignet med å bruke et innebygd bildeelement.
4. Video
Når LCP-elementet er en video, måler nettleseren tegnetiden for posterbildet eller den første rammen (hvis autoplay er på). Dette oppfører seg likt som bildetypen, men er ofte tyngre på grunn av filstørrelsen til videoressurser.
Behandle dette strengt som en bildeoptimaliseringsoppgave. Sørg for at et lett poster-attributt er til stede i HTML-en slik at nettleseren ikke trenger å laste ned videosegmenter for å rendre den første pikselen. Komprimer posterbildet 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 den samme for hver besøkende. Den endres ofte basert på brukerens enhet, noe som avslører fundamentale feil i responsivt design.
Bruk CoreDash Device Form Factor-filteret for å sammenligne elementtyper mellom mobil og desktop. Du vil ofte finne at desktop-brukere får en bilde-LCP (f.eks. en Hero Banner), mens mobilbrukere får en tekst-LCP. Dette bekrefter at din mobile CSS-layout skyver Hero Banner under folden eller skalerer den ned så betydelig at et tekstavsnitt blir det "største" elementet.
Hvis du optimaliserer hero-bildet for å forbedre mobil LCP i dette scenarioet, kaster du bort innsatsen. Nettleseren teller ikke engang bildet. Du må enten justere layouten for å bringe bildet tilbake i primærvisningen eller flytte fokuset til å optimalisere tekstrenderingen (fonter/CSS) for mobilbrukere.
