Largest Contentful Paint (LCP) er tiden, indtil det største element på siden vises på skærmen. Google regner op til 2,5 s som godt, så 3,0 s på mobil lignede et problem, der skulle løses. Før vi løste noget, tjekkede vi, hvad PageSpeed præcis måler. Det viste sig, at det meste af de tre sekunder ikke skyldtes hjemmesiden.
Hvad PageSpeed viste
Resultatet på mobil: 94 point i ydeevne, FCP 1,2 s og LCP 3,0 s. Det største element var sidehovedets baggrundsbillede, en fil på 17 KB.
Opdelingen af LCP i rapporten var overraskende. Billedet begyndte at blive hentet efter 90 ms, blev hentet på 75 ms og ventede derefter 1,1 s på at blive vist. Serveren svarede med det samme, billedet var klar næsten med det samme, og alligevel viste browseren det ikke.
Sådan beregner Lighthouse LCP
PageSpeed Insights bruger Lighthouse. Som standard gør Lighthouse ikke siden langsommere for alvor. Den indlæser siden hurtigt, optager, hvad der skete, og anslår så ud fra optagelsen, hvor lang tid det samme ville tage på en langsom 4G-forbindelse og en processor, der er fire gange langsommere.
For at anslå LCP medregner modellen alt, hvad der skete i den hurtige indlæsning, før det største element blev vist: hentede filer og kørte scripts. Hvis den første visning kom sent i den hurtige indlæsning, efter at al JavaScript var kørt, antager modellen, at billedet måtte vente på al den kode. I vores tilfælde var det omkring 360 KB, inklusive hele frameworket.
Det centrale spørgsmål blev derfor: hvorfor viste browseren ingenting så længe i den hurtige indlæsning?
Hvor den sene første visning kom fra
I Lighthouses optagelser var siden helt indlæst efter 0,5–0,8 s, mens det første billede kom frem på skærmen efter 0,9–2,4 s. Browserens hovedtråd lavede næsten ingenting imens. Billederne var klar, men browseren viste dem cirka én gang i sekundet.
Vi genskabte det samme symptom uden for Lighthouse ved at starte Chrome med præcis de flag, som Lighthouse bruger. Ved at slå dem fra ét ad gangen kom vi frem til ét enkelt:
--disable-features=RenderDocument
Med kun det flag kom den første visning af vores side efter omkring 2,4 s hver gang. Uden det efter 0,4–0,6 s. Vi så en lignende effekt på andre hjemmesider bygget med Next.js, blandt andet react.dev og nextjs.org. På en simpel side uden JavaScript, som example.com, ændrede flaget ingenting.
RenderDocument er den måde, moderne Chrome opretter et nyt dokument på ved hvert sideskift. Slår man det fra, skifter browseren til en ældre tilstand, som ingen af dine brugere kører.
Vi ved ikke præcis, hvordan PageSpeed starter Chrome på sine servere. Vi ved kun, at rapporten viste det samme symptom: 1,1 s ventetid på at vise et billede, der allerede var hentet.
Hvor lang tid indlæsningen reelt tager
Lighthouse kan også gøre forbindelsen og processoren langsommere for alvor i stedet for at anslå. Med de samme indstillinger, langsom 4G og en processor, der er fire gange langsommere, viser den samme version af vores hjemmeside hovedbilledet efter 1,7–1,8 s. Det er inden for grænsen på 2,5 s, som Google regner som god.
Husk også, at vurderingen af Core Web Vitals i søgeresultaterne bygger på data fra rigtige Chrome-brugere, ikke på en laboratorietest. PageSpeed viser de data i et særskilt afsnit af rapporten, når hjemmesiden har trafik nok.
Hvad du kan gøre
Se på data fra rigtige brugere. Viser PageSpeed dem, er de vigtigere end laboratorieresultatet.
Mål med reel nedsættelse af hastigheden. Lighthouse kørt fra kommandolinjen kan gøre siden langsommere for alvor i stedet for at simulere:
npx lighthouse https://din-hjemmeside.dk --throttling-method=devtools
Optimer ikke efter en målefejl. Vi prøvede blandt andet at lægge al CSS direkte i HTML’en. Med reel nedsættelse blev teksten vist tidligere, men det simulerede resultat blev 0,15 s dårligere, fordi Next.js så sender CSS’en to gange, og siden bliver tungere. En ændring, der hjælper brugerne, kan gøre resultatet dårligere, og omvendt.
Skær ned på det, der indlæses før den første visning. Det hjælper i begge målinger. For os betød det at flytte kode, der først skal bruges senere, som træk og slip af elementer og validering af formularer, så den først indlæses, når den bliver brugt.
Vi tjekkede resultaterne i september 2026 på Chrome 153, Lighthouse 12 og Lighthouse 13.5 i PageSpeed Insights. Med nyere versioner kan de se anderledes ud.
Har din hjemmeside et lignende problem, eller vil du have den hurtig fra starten, så se, hvordan vi bygger hjemmesider.
Lad os tale om dit projekt
Den første samtale tager 30 minutter og er gratis. Bagefter ved du, om vi kan hjælpe, og hvad det vil koste.
Book samtale
