Asterisk - Unusually Webflow Template
Kunskapsbanken —
Kunskapsbanken —
Kunskapsbanken —
Kunskapsbanken —
Kunskapsbanken —
Kunskapsbanken —
Publiceringsdatum:
3/9/2026
Senast ändrad:
6/9/2026

LCP (Largest Contentful Paint) – vad Core Web Vital-måttet mäter, gränsvärden och fixar i Webflow, Next.js och Astro

Definition

LCP (Largest Contentful Paint) är ett webbprestandamått i Core Web Vitals som mäter hur lång tid det tar innan sidans största synliga element – ofta hero-bilden eller rubriken – har renderats. Under 2,5 sekunder räknas som bra, över 4 sekunder som dåligt.

LCP (Largest Contentful Paint) är det av Googles tre Core Web Vitals som besökaren märker först: när det viktigaste innehållet på sidan syns. Måttet har inget att göra med vårdtermen LCP (Liverpool Care Pathway); här handlar det uteslutande om hemsidor och webbprestanda.

Vad är LCP och varför är det en Core Web Vital?

LCP är ett av tre mått i Core Web Vitals, tillsammans med INP (interaktivitet) och CLS (visuell stabilitet). Google valde LCP som mått på upplevd tid för att ladda eftersom det fångar det som besökaren faktiskt märker: när det viktigaste innehållet syns. Äldre mått som "load" eller "DOMContentLoaded" kunde visa gröna siffror trots att skärmen var tom i flera sekunder.

Core Web Vitals ingår i Googles bedömning av sidupplevelse och är en rankningssignal, om än en svag sådan i förhållande till innehållets relevans. Den affärsmässiga effekten är ofta större än SEO-effekten: en hemsida som visar sitt innehåll snabbt tappar färre besökare innan de hunnit se erbjudandet. Hur prestanda hänger ihop med resten av den tekniska grunden går vi igenom i Checklista för hemsida 2026.

Vilka LCP-värden räknas som bra och dåliga?

Enligt web.dev gäller tre nivåer: LCP på högst 2,5 sekunder är bra, 2,5–4 sekunder behöver förbättras och över 4 sekunder är dåligt. Gränsen bedöms vid 75:e percentilen av verkliga sidladdningar, vilket betyder att tre av fyra besök måste klara 2,5 sekunder för att sidan ska bli godkänd. Mobil och desktop bedöms separat, och det är nästan alltid mobilvärdet som underkänner en sida.

Två datakällor är viktiga att hålla isär. Fältdata från Chrome User Experience Report (CrUX) visar hur riktiga besökare upplever sidan under de senaste 28 dagarna och är det som syns i GSC. Labbdata från PageSpeed Insights och Lighthouse är en simulerad laddning på en fördefinierad enhet. Fältdata avgör om du är godkänd, labbdata hjälper dig hitta orsaken.

Vad räknas som LCP-elementet på en sida?

LCP-elementet är det största synliga innehållselementet inom viewporten vid laddning. Kandidater är bilder (<img> och <image> inuti SVG), postern eller första bildrutan i en video, element med bakgrundsbild via CSS url() samt blockelement som innehåller text. Storleken mäts som den synliga ytan; delar som ligger utanför viewporten räknas inte. Bilder med mycket låg informationstäthet, som enfärgade platshållare eller gradienter, diskvalificeras som kandidater.

På de flesta företagshemsidor är LCP-elementet hero-bilden eller H1-rubriken. Vilket element webbläsaren valde ser du i PageSpeed Insights under "Diagnostik" eller i Chrome DevTools under fliken Performance. Kontrollera detta först – många lägger tid på att optimera fel bild.

Vad beror långsam LCP på – och hur bryter du ner orsaken?

Långsam LCP beror nästan alltid på en av fyra saker: långsamt serversvar, render-blockerande CSS eller JavaScript, stora ooptimerade bilder eller att innehållet renderas på klienten först efter att JavaScript kört. Chrome delar upp tiden fram till LCP i fyra delar, och att mäta dem separat visar var problemet sitter. Metoden beskrivs i Chrome DevTools-dokumentationen, och riktvärdena för hur budgeten bör fördelas finns i web.dev – Optimize LCP.

  • Time to First Byte (TTFB): tiden tills webbläsaren får första byten HTML från servern. Riktvärde: cirka 40 procent av den totala budgeten.
  • Fördröjning innan laddning (resource load delay): tiden från TTFB tills webbläsaren börjar hämta LCP-resursen. Bör vara nära noll – lazy loading eller att bilden bara finns i CSS eller JavaScript är typiska orsaker till att den växer.
  • Tid för att ladda resursen (resource load duration): hur lång tid själva nedladdningen av bilden tar. Riktvärde: cirka 40 procent av budgeten. Styrs av filstorlek, format och CDN.
  • Fördröjning innan rendering (element render delay): tiden från att resursen är hämtad tills elementet ritas ut. Växer när CSS, webbfonter eller JavaScript blockerar renderingen.

En viktig slutsats av nedbrytningen: om TTFB redan tar 2 sekunder hjälper ingen bildkomprimering. Börja i den del som är störst. Mer om hur prestanda samspelar med indexering och Crawlability finns i vår guide SEO-analys 2026 – så gör du en steg för steg.

Hur fixar du LCP i Webflow respektive Next.js och Astro?

Åtgärderna är samma i grunden – gör LCP-elementet litet, låt webbläsaren hitta det tidigt och blockera inte renderingen – men verktygen skiljer sig mellan plattformarna.

Webflow. Den vanligaste LCP-orsaken i Webflow är att alla bilder får loading="lazy" som standard, även hero-bilden. Lazy loading på LCP-elementet skjuter upp hämtningen och ökar fördröjningen innan laddning i onödan. Sätt hero-bildens laddningsläge till "Eager" i bildinställningarna och lägg till fetchpriority="high" som custom attribute eller via custom code, så att webbläsaren prioriterar just den resursen. Komprimera hero-bilden och leverera den som WebP – Webflow serverar WebP automatiskt till webbläsare som stödjer det, men en 4 000 pixlar bred originalbild blir ändå tung. Vill du gå vidare till AVIF görs det manuellt via komprimeringsverktyget i Assets-panelen. Är LCP-elementet en rubrik i stället för en bild är webbfonterna det som avgör: självhosta dem eller använd font-display: swap så texten inte hålls osynlig medan fonten laddar.

Next.js. Komponenten next/image sätter bredd och höjd automatiskt och lazy-laddar som standard. På LCP-bilden sätter du loading="eager" och fetchPriority="high" enligt Next.js-dokumentationen. I Next.js-versioner före 16 gjorde egenskapen priority samma sak i ett steg; den är numera utfasad. Se också till att hero-sektionen renderas på servern (statiskt eller via SSR) så att bilden finns i HTML-svaret från början. En hero som först dyker upp efter att klient-JavaScript kört ger dålig LCP oavsett bildstorlek.

Astro. Astro levererar statisk HTML utan JavaScript som standard, vilket ger en bra utgångspunkt för LCP. Bildkomponenten från astro:assets optimerar format och sätter dimensioner, men lazy-laddar också som standard – så sätt loading="eager" och fetchpriority="high" på LCP-bilden (attributen skickas vidare till bildelementet), se Astros bildguide. Undvik att lägga hero-innehållet i en klientkomponent med client:load om det inte måste vara interaktivt.

Oavsett plattform: mät om i fältdata efter åtgärden. Labbvärdet i PageSpeed Insights ändras direkt, medan CrUX-värdet i GSC behöver upp till 28 dagar för att spegla förändringen. LCP är en del av Teknisk SEO, men sällan hela förklaringen när en sida inte syns – fler orsaker går vi igenom i Hemsida rankar inte? 10 orsaker.

Vanliga frågor om LCP

Är LCP samma sak som laddtid?

Nej. Traditionell mätning av tid för att ladda avser när hela sidan inklusive alla resurser är klar, medan LCP mäter när det största synliga elementet har renderats. En sida kan ha bra LCP trots att skript och bilder under vecket fortsätter laddas i flera sekunder – och tvärtom kan en tekniskt "färdigladdad" sida ha dålig LCP om hero-bilden kom sist.

Mäts LCP på mobil och desktop separat?

Ja. Fältdata i Chrome User Experience Report delas upp per enhetstyp, och Google Search Console visar separata Core Web Vitals-rapporter för mobil och desktop. En sida kan vara godkänd på desktop men underkänd på mobil, vilket är det vanligaste utfallet eftersom mobila nätverk och processorer är långsammare. Prioritera alltid mobilvärdet.

Varför visar PageSpeed Insights och Search Console olika LCP?

De mäter olika saker. Search Console visar fältdata från riktiga besökare under en 28-dagarsperiod, bedömt vid 75:e percentilen. PageSpeed Insights visar samma fältdata överst men dessutom ett labbvärde från Lighthouse, som simulerar en enskild laddning på en fördefinierad enhet och uppkoppling. Labbvärdet kan vara både bättre och sämre än fältvärdet. Det är fältdatan som avgör om sidan är godkänd.

Kan en video vara LCP-elementet?

Ja. Ett videoelement kan bli LCP-kandidat via sin poster-bild, och i moderna Chrome-versioner räknas även första bildrutan i en video som spelas upp automatiskt. Att byta hero-bild mot en autoplay-video förbättrar därför inte LCP i sig – videofilen är ofta tyngre än bilden. Använd en lätt poster-bild med fetchpriority="high" och låt videon ladda efteråt.

Innehållet i detta inlägg

Redo att ta nästa steg?

Nu när du lärt dig mer om LCP kanske du känner dig nyfiken på vad ditt nästa steg borde vara.

Vi står alltid till tjänst och svarar gärna på frågor och funderingar!

Boka ett intro möte

utforska mer termer inom webbdesign & SEO

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.