Core/Dash Dimension: Urls
Isoler og ret Core Web Vitals performance-flaskehalse efter specifikke Urls
Trusted by market leaders
Dimension: Side & Navigation: URLs (u)
Element Type (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 nøjagtige DOM-node, dikterer Element Type dimensionen din overordnede engineering-strategi. 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, hvilket giver dig mulighed for at vælge den korrekte optimeringsprotokol uden at gætte.
Optimering af Core Web Vitals efter LCP element type
Efter at have forbedret TTFB, som er uafhængig af LCP element type, bør du anlægge en anden tilgang til optimering af LCP ved at se på dit LCP element.
1. Tekst
Når CoreDash rapporterer tekst som Element Type, er statisk netværksressource-båndbredde sjældent flaskehalsen. Tekst befinder sig direkte i HTML-dokumentet, hvilket betyder, at indholdet er tilgængeligt umiddelbart efter den indledende serverrespons (TTFB). Hvis din LCP er langsom her, er problemet næsten udelukkende Render Delay.
For at rette dette skal du fokusere fuldstændigt på Critical Rendering Path. Browseren er sandsynligvis blokeret fra at male teksten på grund af tunge CSS-beregninger eller synkron JavaScript i <head>. Tjek desuden din font-loading strategi; hvis du ikke bruger font-display: swap eller optional, skjuler browseren kunstigt teksten (FOIT), mens den venter på, at font-filen downloades.
2. Billede (<img>)
Denne type udløser hele ressource-pipelinen: opdagelse, download og afkodning. I modsætning til tekst er en billede-LCP stærkt afhængig af Load Delay og Load Time. Du kæmper mod fysik og netværkslatens her, så dit mål er at gøre aktivet lettere og opdageligt hurtigere.
Optimering her kræver streng asset management. Sørg for, at <img> tagget findes i den oprindelige HTML-kilde (Server-Side Rendering) for at minimere Load Delay. Tilføj fetchpriority="high" og fjern konsekvent alle loading="lazy" attributter, da disse forsinker browserens forespørgsel. Håndter endelig Load Time ved at servere next-gen formater (AVIF/WebP) og bruge srcset for at forhindre mobile enheder i at downloade filer i desktop-størrelse.
3. Baggrundsbillede
Denne klassificering signalerer en arkitektonisk ineffektivitet. Da 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 fuldt ud. Dette skaber en massiv Load Delay, fordi Preload Scanneren reelt er blind over for aktivet.
Den eneste robuste tekniske løsning er refactoring. 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 refactorere markuppen, skal du bruge <link rel="preload"> i dokumentets head for at tvinge tidlig opdagelse igennem, selvom dette ofte er en vedligeholdelsesbyrde sammenlignet med at bruge et native billedelement.
4. Video
Når LCP-elementet er en video, måler browseren paint-tiden for poster-billedet eller det første frame (hvis autoplaying). Dette opfører sig ligesom Billede-typen, men er ofte tungere på grund af filstørrelsen på video-assets.
Behandl dette strengt som en billedoptimeringsopgave. Sørg for, at en letvægts 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 standard LCP-billede.
Workflow: Find LCP-problemer baseret på LCP element type
LCP Element Type er hverken statisk eller den samme for hver besøgende. Den ændrer sig ofte baseret på brugerens enhed, hvilket afslører fundamentale fejl i responsivt design.
Brug CoreDash Device Form Factor filteret til at sammenligne Element Types mellem Mobil og Desktop. Du vil ofte opleve, at Desktop-brugere får en billede-LCP (f.eks. et Hero Banner), mens Mobil-brugere får en tekst-LCP. Dette bekræfter, at dit mobile CSS-layout skubber Hero Banneret below the fold eller skalerer det så kraftigt ned, at et tekstafsnit bliver det "Største" element.
Hvis du optimerer hero-billedet for at forbedre mobil LCP i dette scenarie, spilder du kræfterne. Browseren tæller ikke engang billedet med. Du skal enten justere layoutet for at bringe billedet tilbage i den primære visning eller flytte dit fokus til at optimere tekst-rendering (fonts/CSS) for mobilbrugere.
