Core/Dash Dimension: LCP-prioritet

Løs LCP Load Delay ved at gennemgå den specifikke indlæsningsstrategi for dit største indholdselement.

Prøv gratis

Trusted by market leaders · Client results

erasmusmcloopearplugsmy work featured on web.devsaturnkpnperionmarktplaatsnina caredpg mediahappyhorizonebayharvardworkivafotocasasnvadevintamonarchvpnaleteianestlecomparewhowhatwear

Dimension: Ressource: LCP-prioritet

Dimensionen LCP-prioritet segmenterer performancedata baseret på, hvordan browseren opdagede og prioriterede LCP-ressourcen. Mens dimensionen "Element Type" fortæller dig, hvad elementet er (Tekst vs. Billede), fortæller denne dimension dig, hvorfor browseren forsinkede indlæsningen af det.

Dette er dit primære auditværktøj til Load Delay. Det afslører, om dit LCP-aktiv kæmper om båndbredde, eller om det forsinkes kunstigt af forkerte HTML-attributter.

coredash metric table urls

Prioritetshierarkiet

Browseren tildeler en downloadprioritet til hver ressource. Denne dimension knytter LCP-elementet til en af fem specifikke indlæsningstilstande, rangeret fra mest destruktiv (Lazy Loaded) til mest optimal (Tekst/High Priority).

Baggrund: Når en bruger vender tilbage til din side via "Tilbage"- eller "Genindlæs"-knappen, returnerer de fleste browsere dem til deres tidligere vertikale position. Hvis denne position er under folden, er dit optimerede hero-billede ikke længere LCP. I stedet måler browseren det største element i den aktuelle visningsport (viewport). Dette skaber et uundgåeligt sæt af "Not Preloaded"-hændelser i dit datasæt. Og det er helt fint!

1. Lazy Loaded

Hvis mere end 10 % af dine LCP-elementer vises i denne kategori, har du identificeret et problem. Billeder med lazy loading sættes i kø meget senere (af den langsomme DOM-parser og ikke den hurtige preload-scanner). Attributten loading="lazy" instruerer browseren i at vente med downloadet, indtil layoutet er beregnet, og elementet er tæt på visningsporten (viewporten).

Løsningen: Du skal fjerne denne indlæsningsattribut. LCP-elementet bør aldrig være lazy-loaded.

<!-- FORKERT -->
<img src="hero.jpg" loading="lazy" alt="Hero Image" />

<!-- KORREKT -->
<img src="hero.jpg" fetchpriority="high" alt="Hero Image" />

2. Not Preloaded

Dette repræsenterer standardadfærden i browseren. Browseren opdagede billedet i din HTML under den indledende parsing, men modtog ikke noget signal om at prioritere det over andre billeder.

Indvirkningen på pagespeed afhænger af kompleksiteten af din webside. LCP-billedet indgår i en kø, hvor der er kamp om ressourcerne. Hvis din side har mange scripts, skrifttyper, andre ikke-lazy billeder eller styles, der skal downloades, kan browseren forsinke downloadet af dette billede, hvilket øger din Load Delay.

3. Preloaded

Dette indikerer, at ressourcen blev opdaget via et <link rel="preload">-tag i dokumentets head. Disse preload-links betyder grundlæggende en tidlig opdagelse, selvom billedreferencen er begravet dybt i DOM'en eller skjult i en CSS-fil (baggrundsbillede).

Preloading er den mest effektive måde at fremtvinge et tidligt download på. Preloading kræver dog vedligeholdelse af et separat link-tag, som skal matche billedets URL nøjagtigt. Hvis de afviger fra hinanden, downloader du et aktiv to gange.

4. High fetchpriority

Dette er den moderne tekniske standard. Browseren blev instrueret via attributten fetchpriority="high" i at behandle dette specifikke billede som en kritisk ressource.

Strategien: Dette er måltilstanden for en billedbaseret LCP. Den signalerer vigtighed direkte på elementet og løfter det over andre aktiver i downloadkøen uden vedligeholdelsesbyrden fra manuelle preload-tags.

5. Ikke et billede

Status: Tekstnode / SVG

LCP-elementet er en tekstblok (h1, p) eller en rå SVG. Dette er den ideelle arkitektoniske tilstand, fordi tekst medfører nul Load Delay (det er allerede til stede i HTML-dokumentet).

Optimeringen: Hvis din LCP er i denne kategori, men stadig er langsom, er flaskehalsen udelukkende Render Delay. Du skal optimere din Critical Rendering Path (CSS/JS-blokering) eller din strategi for indlæsning af skrifttyper (font-display: swap), da der ikke er nogen billedfil at downloade.

Workflow: Optimering af Load Delay

Brug denne dimension til at validere din frontend-ressourcestrategi.

  1. Eliminer Lazy Loading: Filtrer efter Lazy Loaded. Hvis denne værdi er større end 0 %, skal du finde komponenten, der tilføjer loading="lazy" til hero-billedet, og fjerne den. Dette er almindeligt i CMS-skabeloner, der anvender lazy loading globalt på alle medier.
  2. Migrer til Fetchpriority: Flyt trafik fra Not Preloaded og Preloaded til High fetchpriority. Hvis du erstatter <link rel="preload"> med fetchpriority="high", rydder du op i din <head> og kobler prioritetslogikken direkte til komponenten.
  3. Gennemgå baggrundsbilleder: Hvis du har en stor volumen i Not Preloaded, og din LCP er et baggrundsbillede, opdager browseren det for sent (først efter at CSS er parset). Du skal omstrukturere dette til et HTML <img>-tag med fetchpriority="high" eller gennemtvinge en Preload-header.

Teknisk tommelfingerregel

Dit fordelingsmål for denne dimension er strengt:

  • <10 % Lazy Loaded
  • > 90 % High fetchpriority (for billed-LCP'er)
  • 100 % Ikke et billede (for tekst-LCP'er)

Enhver trafik, der falder ind under "Not Preloaded", repræsenterer en uoptimeret tilstand, hvor du overgiver kontrollen over ressourceprioriteten til browserens standardheuristik.


Dimension: LCP-prioritetCore Web Vitals Dimension: LCP-prioritet