Sidehastighet har gått fra å være en hygienefaktor til å bli et reelt rangeringssignal og en avgjørende del av brukeropplevelsen. Google har med Core Web Vitals gitt oss tre konkrete måltall som fanger essensen av hvordan brukere opplever ytelsen: hvor raskt innholdet laster (LCP), hvor responsivt det er å interagere med (INP), og hvor stabilt visuelt oppsett er (CLS). Ifølge Google passerer bare 43 % av mobilnettsteder alle tre Core Web Vitals-tersklene (Chrome UX Report, 2025). Det betyr at flertallet av nettsteder har et konkret forbedringspotensial som direkte påvirker rangering, konvertering og brukertilfredshet. Denne guiden gir deg praktiske strategier for å optimalisere hvert enkelt vital.
Hva er Core Web Vitals: LCP, INP og CLS
Core Web Vitals er tre brukersentrerte ytelsesmåltall definert av Google. Largest Contentful Paint (LCP) måler hvor lang tid det tar før det største synlige innholdselementet i viewporten er ferdig rendret. Interaction to Next Paint (INP) måler responshastigheten — tiden fra en bruker klikker, tapper eller trykker til nettleseren visuelt responderer. Cumulative Layout Shift (CLS) måler visuell stabilitet — hvor mye innholdet uventet flytter på seg under lasting.
Tersklene er tydelige: LCP bør være under 2,5 sekunder, INP under 200 millisekunder, og CLS under 0,1. Alt over disse tersklene vurderes som dårlig. «Needs improvement» er mellomsjiktet: LCP mellom 2,5 og 4 sekunder, INP mellom 200 og 500 millisekunder, og CLS mellom 0,1 og 0,25.
INP erstattet First Input Delay (FID) som offisiell Core Web Vital i mars 2024. Endringen var betydelig: FID målte bare forsinkelsen av første interaksjon, mens INP måler alle interaksjoner gjennom hele sidebesøket og rapporterer den verste (tilnærmet). Dette betyr at sider som bestod FID-testen kan feile på INP, spesielt sider med tunge JavaScript-interaksjoner.
Hvorfor hastighet er viktig for SEO og brukeropplevelse
Google bekreftet i 2021 at Core Web Vitals er en del av Page Experience-rangeringssignalene, og har siden bekreftet at dette fortsatt gjelder (Google Search Central, 2025). Det er ikke det sterkeste rangeringssignalet — innholdsrelevans og lenker veier tyngre — men i konkurransesituasjoner der innholdet er likt, kan hastighet vippe utfallet.
Men den virkelige effekten er på brukeropplevelse og konvertering. En studie fra Portent viser at nettsteder som laster på 1 sekund har 3x høyere konverteringsrate enn nettsteder som laster på 5 sekunder (Portent, 2023). For mer om dette samspillet, se vår guide til konverteringsoptimalisering. Google rapporterer at 53 % av mobilbrukere forlater sider som tar mer enn 3 sekunder å laste (Google, 2018). Disse tallene gjør hastighetsoptimalisering til en direkte inntektsfaktor.
For SEO betyr dårlig hastighet også lavere crawl-effektivitet. Googlebot har et crawl-budsjett for hvert nettsted, og trege sider bruker mer av dette budsjettet. Resultatet er at færre sider crawles og indekseres, noe som er spesielt skadelig for store nettsteder med tusenvis av sider.
Slik måler du Core Web Vitals korrekt
Det finnes to typer ytelsesdata: feltdata (fra virkelige brukere) og laboratoriedata (fra simulerte tester). Google bruker feltdata fra Chrome UX Report (CrUX) for rangeringsformål. Laboratoriedata fra Lighthouse er nyttig for diagnostikk, men det er feltdataen som teller for SEO.
PageSpeed Insights (pagespeed.web.dev) er det beste utgangspunktet fordi det viser både feltdata og laboratoriedata for en spesifikk URL. Feltdataen vises øverst under «Discover what your real users are experiencing» — dette er CrUX-dataen Google bruker. Laboratoriedataen under gir diagnostikk og spesifikke anbefalinger.
Google Search Console gir en oversikt over Core Web Vitals for hele nettstedet, gruppert etter URL-mønstre. Chrome DevTools Performance-panelet gir detaljert diagnostikk for individuelle sideinnlastinger. For kontinuerlig overvåking er web-vitals JavaScript-biblioteket fra Google det beste alternativet for å samle feltdata direkte fra dine egne brukere.
- PageSpeed Insights: Feltdata + laboratoriedata for enkelt-URL-er
- Google Search Console: Oversikt over CWV for hele nettstedet
- Chrome DevTools: Detaljert diagnostikk for individuelle sideinnlastinger
- web-vitals JS-bibliotek: Samle egne feltdata fra reelle brukere
- Lighthouse CI: Automatisert laboratorietesting i CI/CD-pipeline
LCP-optimalisering: Raskere innholdslasting
LCP måler når det største synlige elementet er ferdig rendret — typisk et hero-bilde, en stor tekstblokk eller en video. De fire hovedårsakene til dårlig LCP er: treg server-responstid (TTFB), render-blokkerende ressurser, treg ressurslasting og treg client-side rendering.
Start med server-responstiden. Time to First Byte (TTFB) bør være under 800 ms. Bruk et CDN for statiske ressurser, aktiver server-side caching, og optimaliser database-spørringer. For Next.js-nettsteder gir statisk generering (SSG) og Incremental Static Regeneration (ISR) dramatisk bedre TTFB enn server-side rendering (SSR) på hver forespørsel. Vår JavaScript SEO-guide dekker disse renderingsmetodene i detalj.
For bilder — den vanligste LCP-kilden — er preload-attributtet avgjørende. Legg til <link rel="preload"> for hero-bildet i <head>, bruk moderne formater (WebP eller AVIF), og server responsivt med srcset og sizes. Unngå lazy loading på LCP-bildet — det skal lastes umiddelbart. Fjern render-blokkerende CSS og JavaScript ved å inline kritisk CSS og defer ikke-kritiske skript.
INP-optimalisering: Raskere interaksjonsrespons
INP er det nyeste vitalet og det vanskeligste å optimalisere, fordi det handler om JavaScript-ytelse gjennom hele sidebesøket. Dårlig INP skyldes nesten alltid at hovedtråden i nettleseren er blokkert av langvarige JavaScript-oppgaver når brukeren forsøker å interagere.
Den viktigste strategien er å bryte opp lange JavaScript-oppgaver (over 50 ms) i mindre biter. Bruk requestIdleCallback eller scheduler.yield() for å gi nettleseren rom til å respondere på brukerinteraksjoner mellom oppgavene. I React/Next.js betyr dette å unngå tunge beregninger i render-syklusen og heller bruke useTransition eller useDeferredValue for ikke-kritiske oppdateringer.
Reduser også mengden JavaScript som lastes og kjøres. Bruk kode-splitting for å bare laste det som trengs for den aktuelle siden. Implementer tree shaking for å fjerne ubrukt kode. Og vurder om tunge klientside-operasjoner kan flyttes til server-side eller Web Workers. Ifølge HTTP Archive er medianen for JavaScript per side 509 KB komprimert (HTTP Archive, 2024) — de raskeste nettstedene er godt under dette.
CLS-optimalisering: Stabil visuell opplevelse
CLS-problemer er ekstremt frustrerende for brukere — du er i ferd med å klikke på en lenke, og plutselig hopper innholdet fordi et bilde lastet inn eller en annonse dukket opp. De vanligste årsakene er bilder uten dimensjoner, dynamisk innlastet innhold, web-fonter som forårsaker FOUT/FOIT, og sent innlastede annonser.
Den enkleste og mest effektive fiksen er å alltid angi width og height (eller aspect-ratio) på alle bilder og videoer. Dette lar nettleseren reservere plass før ressursen laster. I Next.js håndteres dette automatisk av Image-komponenten. For annonser og dynamisk innhold, reserver plass med CSS (min-height) basert på de forventede dimensjonene.
Web-fonter er en skjult CLS-kilde. Når en font lastes inn etter at teksten allerede er rendret med fallback-fonten, oppstår et layoutskift. Bruk font-display: swap kombinert med en nøye matchet fallback-font for å minimere skiftet. Bedre ennå: bruk font-display: optional som ikke viser fonten i det hele tatt hvis den ikke er lastet i tide, noe som eliminerer CLS helt.
Bildeoptimalisering: WebP, AVIF, lazy loading og responsive bilder
Bilder utgjør typisk 50–70 % av en sides totale vekt. Moderne bildeformater som WebP og AVIF gir 25–50 % mindre filstørrelser enn JPEG med samme synlige kvalitet. WebP støttes av alle moderne nettlesere, mens AVIF gir ytterligere 20 % besparelse men har litt smalere støtte (95 % globalt per 2025).
Bruk <picture>-elementet med AVIF som førstevalg, WebP som fallback og JPEG som siste utvei. Implementer responsive bilder med srcset og sizes slik at mobilbrukere ikke laster desktop-versjoner. Et 2000px-bredt hero-bilde som serveres til en 375px mobil er bortkastet båndbredde og lastetid.
Lazy loading (loading="lazy") bør brukes på alle bilder som er under folden — altså bilder som ikke er synlige når siden først lastes. Men bruk aldri lazy loading på hero-bildet eller andre bilder som er synlige i den initielle viewporten. For disse bør du heller bruke fetchpriority="high" og preload for å sikre raskest mulig lasting.
Fontinnlastingsstrategi
Fonter blokkerer rendering hvis de ikke håndteres riktig. Nettleseren venter som standard i opptil 3 sekunder på fonten før den viser tekst med fallback — dette kalles Flash of Invisible Text (FOIT). Bruk font-display: swap for å vise tekst umiddelbart med fallback-font, og bytt til den riktige fonten når den er lastet.
Preload de viktigste fontfilene med <link rel="preload" as="font" type="font/woff2" crossorigin>. Begrens antall fontvarianter — hver variant (vekt, stil) er en separat fil. Bruk variable fonts der det er mulig, slik at én fil dekker flere vekter. For et typisk nettsted med to fontfamilier bør du ikke laste mer enn 4–5 fontfiler totalt.
En avansert strategi er å bruke CSS Font Loading API til å oppdage når fonten er klar, og deretter legge til en CSS-klasse som justerer linehøyde og tegnbredde for å matche den nye fonten. Dette minimerer CLS-bidraget fra fontbytte. For webdesign-prosjekter anbefaler vi å velge Google Fonts som er optimalisert for webleveranse.
Tredjepartsskript og ytelsesstyring
Tredjepartsskript — analyseverktøy, chatbotter, annonseplattformer, heatmap-verktøy, CRM-widgeter — er den vanligste årsaken til dårlig ytelse som utviklere ikke har direkte kontroll over. En studie fra HTTP Archive viser at mediansiden laster 21 tredjepartsforespørsler (HTTP Archive, 2024).
Audit alle tredjepartsskript jevnlig: Trenger du fortsatt det verktøyet? Kan det lazy-loades? Kan det erstattes med et lettere alternativ? Bruk Chrome DevTools Network-panelet til å identifisere de tyngste tredjepartsskriptene og vurder hvert enkelt kritisk. Google Tag Manager gjør det enkelt å legge til skript — kanskje for enkelt. Gamle tagger som ingen bruker akkumuleres og trekker ned ytelsen.
For skript du må beholde, bruk async eller defer-attributtet for å unngå render-blokkering. Vurder å laste chatbotter og andre ikke-kritiske skript først etter brukerinteraksjon (klikk, scroll). For analyseverktøy kan du bruke Partytown eller en Web Worker-tilnærming for å flytte kjøringen vekk fra hovedtråden.
Hastighetsovervåking og forebygging av regresjoner
Ytelsesoptimalisering er ikke et engangsprosjekt — det er en kontinuerlig prosess. Uten overvåking vil ytelsen gradvis forringes etter hvert som nytt innhold, nye funksjoner og nye tredjepartsskript legges til. Sett opp ytelsesbudsjetter som definerer maksimalt akseptable verdier for sidestørrelse, antall forespørsler og Core Web Vitals-måltall.
Integrer Lighthouse CI i byggepipelinen for å automatisk teste ytelse ved hver deploy. Sett opp varsler i Google Search Console når Core Web Vitals-data forverres. Bruk SpeedCurve eller Calibre for kontinuerlig syntetisk overvåking, og web-vitals-biblioteket for reell brukerdata (RUM). Definer terskler som utløser varsler før ytelsen blir kritisk.
Dokumenter alle ytelsesrelaterte beslutninger. Når noen legger til et nytt tredjepartsskript, bør det gjennom en ytelsesvurdering. Når bilder legges til i CMS, bør de automatisk komprimeres og serveres i moderne formater. Ytelse bør være en del av kulturen, ikke bare et teknisk tiltak. Trenger du hjelp med ytelsesoptimalisering, tilbyr LeapJet dette som en del av våre SEO-tjenester.
Kilder og videre lesning
Denne artikkelen bygger på følgende kilder og bransjerapporter:
- Google Search Central — Core Web Vitals and Page Experience (2025)
- Chrome UX Report — Web Vitals Technology Report (2025)
- Portent — Site Speed and Conversion Rate Study (2023)
- Google — Think with Google: Mobile Page Speed Statistics (2018)
- HTTP Archive — State of the Web: JavaScript and Third-Party Usage (2024)
- web.dev — Optimize Largest Contentful Paint, INP, and CLS (2025)
