Core/Dash Dimension: Elementtype (LCP)
Fiks Largest Contentful Paint ved at filtrere trafik baseret på den arkitektoniske elementtype.
Trusted by market leaders · Client results
Dimension: Resource: Elementtype LCP (lcpet)
Elementtype (LCP)-dimensionen (lcpet) kategoriserer Largest Contentful Paint-noden i en af fire arkitektoniske klasser: text, image, background-image eller video.
Mens Attribution Element-dimensionen udpeger den præcise DOM-node, dikterer Elementtype-dimensionen din overordnede tekniske strategi. LCP er summen af fire tidsintervaller: TTFB, indlæsningsforsinkelse, indlæsningstid og renderingsforsinkelse. Elementtypen 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 baseret på LCP-elementtype
Efter du har forbedret din TTFB, som er uafhængig af LCP-elementtypen, skal du optimere LCP forskelligt baseret på din LCP-elementtype.
1. Tekst
Når CoreDash rapporterer tekst som elementtype, er båndbredden til statiske netværksressourcer sjældent flaskehalsen. Tekst ligger direkte i HTML-dokumentet. Det betyder, at indholdet er tilgængeligt umiddelbart efter det første serversvar (TTFB). Hvis din LCP er langsom her, skyldes det næsten udelukkende renderingsforsinkelse.
Fokuser udelukkende på Critical Rendering Path for at løse dette. Browseren er sandsynligvis blokeret fra at tegne teksten af tunge CSS-beregninger eller synkron JavaScript i <head>. Tjek også din font-indlæsningsstrategi. Hvis du ikke bruger font-display: swap eller optional, skjuler browseren teksten kunstigt (FOIT), mens den venter på, at fontfilen downloades.
2. Billede (<img>)
Denne type udløser hele ressource-pipelinen: opdagelse, download og afkodning. I modsætning til tekst afhænger et billede-LCP i høj grad af indlæsningsforsinkelse og indlæsningstid. Du kæmper mod fysik og netværkslatens her. Dit mål er at gøre ressourcen lettere og hurtigere at opdage.
Optimering her kræver streng ressourcestyring. Sørg for, at <img>-tagget findes i den oprindelige HTML-kilde (Server-Side Rendering) for at minimere indlæsningsforsinkelsen. Tilføj fetchpriority="high", og fjern helt eventuelle loading="lazy"-attributter, da de forsinker browserens anmodning. Løs til sidst indlæsningstiden ved at levere næste-generations formater (AVIF/WebP) og bruge srcset, så mobile enheder ikke downloader filer i desktopstørrelse.
3. Baggrundsbillede
Denne klassificering signalerer en arkitektonisk ineffektivitet. Fordi billedet er defineret i CSS (f.eks. background-image: url(...)), kan browseren ikke finde URL'en, før den har downloadet og parset dine stylesheets helt. Dette skaber en massiv indlæsningsforsinkelse, fordi Preload Scanneren reelt er blind over for ressourcen.
Den eneste robuste tekniske løsning er refaktorering. Flyt det visuelle element fra CSS til et almindeligt HTML-<img>-tag for at eksponere URL'en for browseren med det samme. Hvis du ikke kan refaktorere din markup, skal du bruge <link rel="preload"> i dokumentets head for at tvinge en tidlig opdagelse igennem. Det er dog ofte en vedligeholdelsesbyrde sammenlignet med at bruge et almindeligt billedeelement.
4. Video
Når LCP-elementet er en video, måler browseren renderingstiden for poster-billedet eller det første frame (ved autoplay). Dette minder om Billede-typen, men er ofte tungere på grund af videofilernes størrelse.
Behandl dette udelukkende som en billedoptimeringsopgave. Sørg for, at en let poster-attribut er til stede i HTML'en, så browseren ikke behøver at downloade videosegmenter for at rendere den første pixel. Komprimer poster-billedet lige så aggressivt, som du ville gøre med et almindeligt LCP-billede.
Workflow: Sådan finder du LCP-problemer baseret på LCP-elementtype
LCP-elementtypen er hverken statisk eller den samme for alle besøgende. Den ændrer sig ofte baseret på brugerens enhed, hvilket afslører fundamentale fejl i det responsive design.
Brug CoreDash-filteret Device Form Factor til at sammenligne elementtyper mellem mobil og desktop. Du vil ofte opleve, at desktop-brugere får et billede-LCP (f.eks. et hero-banner), mens mobilbrugere får et tekst-LCP. Det bekræfter, at dit mobile CSS-layout skubber dit hero-banner under folden eller skalerer det så meget ned, at et tekstafsnit 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 tilpasse layoutet for at få billedet tilbage i det primære visningsområde, eller flytte dit fokus til at optimere tekstrenderingen (fonte/CSS) for mobilbrugere.
