Varför PageSpeed visar 3 s LCP fast sidan laddar på 1,7 s

Largest Contentful Paint (LCP) är tiden tills sidans största element visas på skärmen. Google räknar upp till 2,5 s som bra, så 3,0 s i mobilen såg ut som ett problem att åtgärda. Innan vi åtgärdade något kontrollerade vi vad PageSpeed faktiskt mäter. Det visade sig att det mesta av de tre sekunderna inte berodde på webbplatsen.

Vad PageSpeed visade

Resultatet i mobilen: 94 poäng i prestanda, FCP 1,2 s och LCP 3,0 s. Det största elementet var sidhuvudets bakgrundsbild, en fil på 17 KB.

Uppdelningen av LCP i rapporten var överraskande. Bilden började laddas ner efter 90 ms, laddades ner på 75 ms och väntade sedan 1,1 s på att visas. Servern svarade direkt, bilden var klar nästan på en gång, och ändå visade webbläsaren den inte.

Så räknar Lighthouse ut LCP

PageSpeed Insights använder Lighthouse. Som standard saktar Lighthouse inte ner sidan på riktigt. Den laddar sidan snabbt, spelar in vad som hände och uppskattar sedan utifrån inspelningen hur lång tid samma sak skulle ta på en långsam 4G-uppkoppling och en processor som är fyra gånger långsammare.

För att uppskatta LCP tar modellen med allt som hände i den snabba laddningen innan det största elementet visades: nedladdade filer och körda skript. Om den första bilden på skärmen kom sent i den snabba laddningen, efter att all JavaScript körts, antar modellen att bilden måste vänta på all den koden. I vårt fall var det omkring 360 KB, inklusive hela ramverket.

Den viktiga frågan blev alltså: varför visade webbläsaren ingenting på så länge i den snabba laddningen?

Varifrån den sena första bilden kom

I Lighthouses inspelningar var sidan helt laddad efter 0,5–0,8 s, medan den första bildrutan kom upp på skärmen efter 0,9–2,4 s. Webbläsarens huvudtråd gjorde nästan ingenting under tiden. Bildrutorna var klara, men webbläsaren visade dem ungefär en gång per sekund.

Vi återskapade samma symptom utanför Lighthouse genom att starta Chrome med exakt de flaggor som Lighthouse använder. Genom att stänga av dem en i taget kom vi fram till en enda:

--disable-features=RenderDocument

Med bara den flaggan kom den första bilden av vår sida efter omkring 2,4 s varje gång. Utan den, efter 0,4–0,6 s. Vi såg en liknande effekt på andra webbplatser byggda med Next.js, bland annat react.dev och nextjs.org. På en enkel sida utan JavaScript, som example.com, ändrade flaggan ingenting.

RenderDocument är sättet som dagens Chrome skapar ett nytt dokument på vid varje sidbyte. Stänger man av det växlar webbläsaren till ett äldre läge som ingen av dina användare kör.

Vi vet inte exakt hur PageSpeed startar Chrome på sina servrar. Vi vet bara att rapporten visade samma symptom: 1,1 s väntan på att visa en bild som redan var nedladdad.

Hur lång tid laddningen faktiskt tar

Lighthouse kan också sakta ner uppkopplingen och processorn på riktigt i stället för att uppskatta. Med samma inställningar, långsam 4G och en processor fyra gånger långsammare, visar samma version av vår webbplats huvudbilden efter 1,7–1,8 s. Det ligger inom gränsen på 2,5 s som Google räknar som bra.

Kom också ihåg att bedömningen av Core Web Vitals i sökresultaten bygger på data från verkliga Chrome-användare, inte på ett labbtest. PageSpeed visar den datan i en egen del av rapporten när webbplatsen har tillräckligt med trafik.

Vad du kan göra

Titta på data från verkliga användare. Visar PageSpeed den, är den viktigare än labbresultatet.

Mät med verklig nedsaktning. Lighthouse körd från kommandoraden kan sakta ner sidan på riktigt i stället för att simulera:

npx lighthouse https://din-webbplats.se --throttling-method=devtools

Optimera inte för ett mätfel. Vi provade bland annat att lägga all CSS direkt i HTML:en. Med verklig nedsaktning visades texten tidigare, men det simulerade resultatet blev 0,15 s sämre, eftersom Next.js då skickar CSS:en två gånger och sidan blir tyngre. En ändring som hjälper användarna kan göra resultatet sämre, och tvärtom.

Minska det som laddas före den första bilden. Det hjälper i båda mätningarna. För oss innebar det att flytta kod som behövs först senare, som dra och släpp av element och formulärvalidering, så att den laddas först när den används.

Vi kontrollerade resultaten i september 2026 med Chrome 153, Lighthouse 12 och Lighthouse 13.5 i PageSpeed Insights. Med nyare versioner kan de se annorlunda ut.

Har din webbplats ett liknande problem, eller vill du att den ska vara snabb från början, se hur vi bygger webbplatser.