Dimension Core/Dash: Element Type (LCP)
Løs problemer med Largest Contentful Paint ved at filtrere trafik baseret på den arkitektoniske elementtype.
Trusted by market leaders · Client results
Dimension: Ressource: Element Type LCP (lcpet)
Dimensionen Element Type (LCP) (lcpet) kategoriserer den Largest Contentful Paint-node i en af fire arkitektoniske klasser: text, image, background-image eller video.
Mens dimensionen Attribution Element udpeger den nøjagtige DOM-node, dikterer dimensionen Element Type din overordnede ingeniørstrategi. LCP er summen af fire tidsintervaller: TTFB, Load Delay, Load Time og Render Delay. Element Type fortæller dig, hvilket af disse intervaller der skader din score, så du kan vælge den rigtige optimeringsprotokol uden at gætte.
Optimering af Core Web Vitals efter LCP-elementtype
Når du har forbedret TTFB, som er uafhængig af LCP-elementtypen, bør du have en anden tilgang til optimering af LCP ved at se på din LCP-elementtype.
1. Tekst
Når CoreDash rapporterer tekst som Element Type, er båndbredde til statiske netværksressourcer sjældent flaskehalsen. Tekst ligger direkte i HTML-dokumentet, hvilket betyder, at indholdet er tilgængeligt umiddelbart efter det første serversvar (TTFB). Hvis din LCP er langsom her, er problemet næsten udelukkende Render Delay.
For at løse dette skal du fokusere fuldstændig på den kritiske rendering-sti (Critical Rendering Path). Browseren er sandsynligvis forhindret i at tegne teksten af tunge CSS-beregninger eller synkron JavaScript i <head>. Tjek desuden din strategi for indlæsning af skrifttyper; hvis du ikke bruger font-display: swap eller optional, skjuler browseren teksten kunstigt (FOIT), mens den venter på, at skrifttypefilen downloades.
2. Billede (<img>)
Denne type udløser hele ressource-pipelinen: opdagelse, download og afkodning. I modsætning til tekst er et billed-LCP stærkt afhængig af Load Delay og Load Time. Du kæmper mod fysik og netværkslatenstid her, så dit mål er at gøre aktivet lettere og hurtigere at opdage.
Optimering her kræver streng styring af aktiver. Sørg for, at <img>-tagget findes i den indledende HTML-kildekode (Server-Side Rendering) for at minimere Load Delay. Tilføj fetchpriority="high", og fjern konsekvent alle loading="lazy"-attributter, da disse forsinker browserens anmodning. Tag til sidst fat på Load Time ved at servere næstegenerationsformater (AVIF/WebP) og bruge srcset til at forhindre mobilenheder i at downloade filer i skrivebordsstørrelse.
3. Baggrundsbillede
Denne klassifikation signalerer en arkitektonisk ineffektivitet. Fordi billedet er defineret i CSS (f.eks. background-image: url(...)), kan browseren ikke opdage URL'en, før den har downloadet og parset dine stylesheets fuldstændigt. Dette skaber et massivt Load Delay, fordi Preload Scanner effektivt er blind over for aktivet.
Den eneste robuste ingeniørløsning er refaktorering. Flyt det visuelle aktiv fra CSS til et standard HTML <img>-tag for at eksponere URL'en for browseren med det samme. Hvis du ikke kan refaktorere markuppen, skal du bruge <link rel="preload"> i dokumentets head for at fremtvinge tidlig opdagelse, selvom dette ofte er en vedligeholdelsesbyrde sammenlignet med at bruge et indbygget billedelement.
4. Video
Når LCP-elementet er en video, måler browseren tegnetiden for plakatbilledet (poster image) eller den første frame (hvis autoplay er aktiveret). Dette opfører sig på samme måde som billedelementet, men er ofte tungere på grund af videofileres filstørrelse.
Behandl dette strengt som en opgave til billedoptimering. Sørg for, at der er en let plakatattribut (poster attribute) til stede i HTML'en, så browseren ikke behøver at downloade videosegmenter for at gengive den første pixel. Komprimer plakatbilledet lige så aggressivt, som du ville gøre med et standard LCP-billede.
Arbejdsgang: Sådan finder du LCP-problemer baseret på LCP-elementtype
LCP-elementtypen er ikke statisk og er ikke den samme for alle besøgende. Den ændres ofte baseret på brugerens enhed, hvilket afslører fundamentale fejl i det responsive design.
Brug filteret CoreDash Device Form Factor til at sammenligne elementtyper mellem mobil og skrivebord. Du vil ofte opleve, at skrivebordsbrugere får et billed-LCP (f.eks. et Hero-banner), mens mobilbrugere får et tekst-LCP. Dette bekræfter, at dit mobile CSS-layout skubber Hero-banneret under folden eller skalerer det ned så markant, at et afsnit med tekst bliver det "Største" element.
Hvis du optimerer hero-billedet for at forbedre mobil-LCP i dette scenarie, spilder du din tid. Browseren tæller ikke engang billedet med. Du skal enten justere layoutet for at bringe billedet tilbage i den primære visning eller skifte fokus til optimering af tekstrendering (skrifttyper/CSS) for mobilbrugere.
