Largest Contentful Paint (LCP) – hva Core Web Vital-målet måler, grenseverdier og løsninger i Webflow, Next.js og Astro

Definisjon

Largest Contentful Paint (LCP) er et mål på nettytelse i Core Web Vitals som måler hvor lang tid det tar før sidens største synlige element – ofte hero-bildet eller overskriften – er gjengitt. Under 2,5 sekunder regnes som bra, over 4 sekunder som dårlig.

Largest Contentful Paint (LCP) er den av Googles tre Core Web Vitals som den besøkende merker først: når det viktigste innholdet på siden blir synlig. Målet har ingenting å gjøre med helsebegrepet LCP (Liverpool Care Pathway); her handler det utelukkende om nettsider og nettytelse.

Hva er Largest Contentful Paint, og hvorfor er det en Core Web Vital?

LCP er ett av tre mål i Core Web Vitals, sammen med INP (interaktivitet) og CLS (visuell stabilitet). Google valgte LCP som mål på opplevd lastetid fordi det fanger det den besøkende faktisk merker: når det viktigste innholdet blir synlig. Eldre mål som «load» eller «DOMContentLoaded» kunne vise grønne tall selv om skjermen var tom i flere sekunder.

Core Web Vitals inngår i Googles vurdering av sideopplevelse og er et rangeringssignal, om enn et svakt et sammenlignet med hvor relevant innholdet er. Den forretningsmessige effekten er ofte større enn SEO-effekten: en nettside som viser innholdet sitt raskt, mister færre besøkende før de har rukket å se tilbudet. Hvordan ytelse henger sammen med resten av det tekniske grunnlaget, går vi gjennom i Sjekkliste for nettside 2026.

Hvilke LCP-verdier regnes som gode og dårlige?

Ifølge web.dev gjelder tre nivåer: LCP på høyst 2,5 sekunder er bra, 2,5–4 sekunder trenger forbedring, og over 4 sekunder er dårlig. Grensen vurderes ved 75. persentil av faktiske sidelastinger, som betyr at tre av fire besøk må klare 2,5 sekunder for at siden skal bli godkjent. Mobil og desktop vurderes hver for seg, og det er nesten alltid mobilverdien som underkjenner en side.

To datakilder er viktige å holde fra hverandre. Feltdata fra Chrome User Experience Report (CrUX) viser hvordan ekte besøkende opplever siden de siste 28 dagene, og er det som vises i GSC. Labdata fra PageSpeed Insights og Lighthouse er en simulert lasting på en forhåndsdefinert enhet. Feltdata avgjør om du er godkjent, labdata hjelper deg å finne årsaken.

Hva regnes som LCP-elementet på en side?

LCP-elementet er det største synlige innholdselementet innenfor viewporten ved lasting. Kandidater er bilder (<img> og <image> inne i SVG), posteren eller første bilde i en video, elementer med bakgrunnsbilde via CSS url() samt blokkelementer som inneholder tekst. Størrelsen måles som den synlige flaten; deler som ligger utenfor viewporten, teller ikke. Bilder med svært lav informasjonstetthet, som ensfargede plassholdere eller gradienter, diskvalifiseres som kandidater.

På de fleste bedriftsnettsider er LCP-elementet hero-bildet eller H1-overskriften. Hvilket element nettleseren valgte, ser du i PageSpeed Insights under «Diagnostikk» eller i Chrome DevTools under fanen Performance. Sjekk dette først – mange bruker tid på å optimalisere feil bilde.

Hva skyldes treg LCP, og hvordan bryter du ned årsaken?

Treg LCP skyldes nesten alltid én av fire ting: treg serverrespons, CSS eller JavaScript som blokkerer gjengivelsen, store uoptimaliserte bilder eller at innholdet gjengis på klienten først etter at JavaScript har kjørt. Chrome deler tiden frem til LCP inn i fire deler, og å måle dem hver for seg viser hvor problemet sitter. Metoden er beskrevet i dokumentasjonen til Chrome DevTools, og retningsverdiene for hvordan budsjettet bør fordeles, finnes i web.dev – Optimize LCP.

• Time to First Byte (TTFB): tiden til nettleseren får første byte HTML fra serveren. Retningsverdi: rundt 40 prosent av det totale budsjettet.
• Forsinkelse før lasting (resource load delay): tiden fra TTFB til nettleseren begynner å hente LCP-ressursen. Bør være nær null – lazy loading, eller at bildet bare finnes i CSS eller JavaScript, er typiske årsaker til at den vokser.
• Tid for å laste ressursen (resource load duration): hvor lang tid selve nedlastingen av bildet tar. Retningsverdi: rundt 40 prosent av budsjettet. Styres av filstørrelse, format og CDN.
• Forsinkelse før gjengivelse (element render delay): tiden fra ressursen er hentet til elementet tegnes opp. Vokser når CSS, nettfonter eller JavaScript blokkerer gjengivelsen.

En viktig konklusjon av nedbrytningen: hvis TTFB alene tar 2 sekunder, hjelper ingen bildekomprimering. Begynn med den delen som er størst. Mer om hvordan ytelse spiller sammen med indeksering og crawlbarhet finner du i guiden vår SEO-analyse 2026 – slik gjør du den trinn for trinn.

Hvordan fikser du LCP i Webflow, Next.js og Astro?

Tiltakene er de samme i bunn – gjør LCP-elementet lite, la nettleseren finne det tidlig og ikke blokker gjengivelsen – men verktøyene er forskjellige fra plattform til plattform.

Webflow. Den vanligste LCP-årsaken i Webflow er at alle bilder får loading="lazy" som standard, også hero-bildet. Lazy loading på LCP-elementet utsetter hentingen og øker forsinkelsen før lasting unødvendig. Sett lastemodusen for hero-bildet til «Eager» i bildeinnstillingene, og legg til fetchpriority="high" som custom attribute eller via custom code, slik at nettleseren prioriterer akkurat den ressursen. Komprimer hero-bildet og lever det som WebP – Webflow serverer WebP automatisk til nettlesere som støtter det, men et originalbilde på 4 000 piksler i bredden blir likevel tungt. Vil du gå videre til AVIF, gjøres det manuelt via komprimeringsverktøyet i Assets-panelet. Er LCP-elementet en overskrift i stedet for et bilde, er det nettfontene som avgjør: host dem selv eller bruk font-display: swap, slik at teksten ikke holdes usynlig mens fonten laster.

Next.js. Komponenten next/image setter bredde og høyde automatisk og lazy-laster som standard. På LCP-bildet setter du loading="eager" og fetchPriority="high" ifølge dokumentasjonen til Next.js. I Next.js-versjoner før 16 gjorde egenskapen priority det samme i ett steg; den er nå faset ut. Sørg også for at hero-seksjonen gjengis på serveren (statisk eller via SSR), slik at bildet finnes i HTML-svaret fra starten. En hero som først dukker opp etter at klient-JavaScript har kjørt, gir dårlig LCP uansett bildestørrelse.

Astro. Astro leverer statisk HTML uten JavaScript som standard, og det gir et godt utgangspunkt for LCP. Bildekomponenten fra astro:assets optimaliserer format og setter dimensjoner, men lazy-laster også som standard – så sett loading="eager" og fetchpriority="high" på LCP-bildet (attributtene sendes videre til bildeelementet), se bildeguiden til Astro. Unngå å legge hero-innholdet i en klientkomponent med client:load hvis det ikke må være interaktivt.

Uansett plattform: mål på nytt i feltdata etter tiltaket. Labverdien i PageSpeed Insights endres med en gang, mens CrUX-verdien i GSC trenger opptil 28 dager for å gjenspeile endringen. LCP er en del av teknisk SEO, men sjelden hele forklaringen når en side ikke er synlig – flere årsaker går vi gjennom i Synlighet på nett: 10 grunner til at nettsiden ikke rangerer.