Google PageSpeed og Core Web Vitals: slik gjør du nettsiden raskere

Google PageSpeed Insights er Googles gratis verktøy for å måle hvor rask en nettside er. Det viser både en simulert ytelsesscore fra 0 til 100 og ekte brukerdata for Core Web Vitals: LCP under 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1. Det er brukerdataene Google bruker i rangeringen, ikke scoren.

Hva måler Google PageSpeed egentlig?

Google PageSpeed Insights måler to forskjellige ting: en *laboratorietest* som kjøres med Lighthouse, og *felt­data* fra ekte Chrome-brukere. Ifølge Googles egen dokumentasjon for PageSpeed Insights gjelder feltdataene de siste 28 dagene. Laboratorietesten er én enkelt simulert lasting av siden.

Mange blander de to sammen. Det store tallet i en sirkel (for eksempel 47 i oransje) er Lighthouse-scoren. Den gir et øyeblikksbilde fra én test på en simulert mellomklassemobil med begrenset nettforbindelse. Øverst i rapporten står derimot feltet «Vurdering av Core Web Vitals» med «Bestått» eller «Ikke bestått». Det er resultatet fra ekte besøkende, og det er det som betyr noe for synligheten din. Lighthouse er bra til å finne feil. Feltdataene viser om kundene faktisk merker dem.

Vil du ha bedre oversikt over hele nettstedet, ikke bare én adresse, kan du bruke Core Web Vitals-rapporten i Search Console. Search Console-hjelpen forklarer at rapporten sorterer sidene etter status (dårlig, trenger forbedring, god) og grupperer like sider. En treg produktmal i en nettbutikk dukker dermed opp som én gruppe, ikke som 400 enkeltfeil. Vil du også sjekke sikkerhet, lenker og innhold, finner du flere verktøy i guiden om å sjekke nettsider.

Hva er Core Web Vitals, og hvilke grenser gjelder?

Core Web Vitals er tre målinger som Google bruker for å vurdere brukeropplevelsen: lasting (LCP), respons når noen klikker eller trykker (INP) og visuell stabilitet (CLS). Google Search Central setter grensene for god opplevelse til LCP innen 2,5 sekunder, INP under 200 millisekunder og CLS under 0,1.

Grenser for Core Web Vitals (gjelder fortsatt i 2026)

• Måling | Hva den måler | God | Trenger forbedring | Dårlig | Vanligste årsak hos SMB
• LCP (Largest Contentful Paint) | Når det største elementet, ofte toppbildet, er synlig | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s | For store toppbilder, treg server, lazy loading på toppbildet
• INP (Interaction to Next Paint) | Hvor fort siden reagerer på klikk, trykk og tastetrykk | ≤ 200 ms | 200–500 ms | > 500 ms | Tunge sidebyggere, chat-moduler, sporingsskript
• CLS (Cumulative Layout Shift) | Hvor mye innholdet hopper mens siden lastes | ≤ 0,1 | 0,1–0,25 | > 0,25 | Bilder uten bredde og høyde, samtykkebanner, nettfonter

To detaljer er viktige. For det første er INP relativt nytt. Det erstattet First Input Delay (FID) 12. mars 2024, så guider som fortsatt snakker om FID er utdaterte. For det andre måles alt ved den 75. persentilen. web.dev anbefaler å måle på den 75. persentilen av sidelastinger, og mobil og desktop vurderes hver for seg. Det betyr at tre av fire besøk må være innenfor grensen. Hvis halvparten av kundene dine bruker eldre Android-telefoner på 4G, er det dem du må bygge for, ikke for MacBooken på kontoret.

Påvirker PageSpeed-scoren hvor høyt du rangerer i Google?

Core Web Vitals påvirker rangeringen, men Lighthouse-scoren gjør det ikke direkte. Om sideopplevelse skriver Google at Core Web Vitals brukes av rangeringssystemene, men understreker samtidig at det ikke finnes noe enkeltstående signal for sideopplevelse. Relevant innhold veier fortsatt tyngre.

I praksis fungerer gode Core Web Vitals som en avgjørende faktor når to sider ellers står likt, og ikke som en snarvei til toppen. En side som scorer 70 i Lighthouse, men består Core Web Vitals for ekte brukere, har ingenting å hente på å presse scoren opp til 100. Vi mener derfor at «scoren er rød» aldri er god nok begrunnelse for å bestille en ny nettside. Det avgjørende er om vurderingen øverst i rapporten står som ikke bestått, og på hvilke maler.

Hva med AI-oversikter og AI-svar i søk?

Google har ikke dokumentert egne krav til hastighet for AI-oversikter (AI Overviews). Svarene hentes fra det samme indekserte innholdet som vanlige søkeresultater, og sider som er trege eller ustabile for brukerne, blir behandlet av de samme rangeringssystemene. For å bli sitert av AI-svar betyr tydelig struktur og strukturerte data mer enn de siste millisekundene. Hvis du vil jobbe med begge deler, gir guiden med søkemotoroptimalisering-tips en god oversikt.

Slik leser du PageSpeed-rapporten riktig

Begynn med feltdataene på mobil, og bruk Lighthouse til å finne årsakene. Med denne rekkefølgen slipper du å bruke tid på feil du ikke har.

• 1. Lim inn den fullstendige adressen på pagespeed.web.dev og velg fanen Mobil. Det er der de fleste SMB-er stryker.
• 2. Sjekk om vurderingen øverst gjelder «Denne nettadressen» eller «Opprinnelse» (hele domenet). Har siden lite trafikk, viser Google tall for hele nettstedet, og da er det ikke sikkert at problemet ligger på akkurat denne siden.
• 3. Noter hvilken av LCP, INP og CLS som er rød eller oransje. Det er denne målingen du skal jobbe med, ikke selve scoren.
• 4. Bla ned til Lighthouse-delen og filtrer forslagene på samme måling (knappene «Vis forslag som gjelder LCP / CLS / TBT»).
• 5. Klikk på diagnosen «Element for største innholdsrike opptegning» (Largest Contentful Paint element). Der ser du nøyaktig hvilket bilde eller hvilken tekstblokk som er LCP. Ofte er det samtykkebanneret, ikke toppbildet.
• 6. Kjør testen tre ganger og bruk resultatet i midten. Lighthouse-scoren varierer fra gang til gang med serverbelastning og nettverk.
• 7. Gjenta testen for én side av hver mal (forside, tjenesteside, artikkel, produktside), ikke bare for forsiden.
• 8. Når feilen er rettet, åpner du Core Web Vitals-rapporten i Search Console og klikker «Valider løsningen». Deretter følger Google med på de berørte adressene over en periode på 28 dager.

Hvilke tiltak gir størst effekt?

Mest effekt får du ved å rydde i JavaScript, rette opp toppbildet og reservere plass til elementer som lastes sent. Det henger sammen med hvordan scoren beregnes. Ifølge Chromes dokumentasjon av ytelsesscoren i Lighthouse veier Total Blocking Time 30 prosent, Largest Contentful Paint og Cumulative Layout Shift 25 prosent hver, og First Contentful Paint og Speed Index 10 prosent hver.

TBT har altså størst vekt, og den fungerer som en erstatning for INP i laboratoriet. INP kan nemlig ikke måles i en simulert test, fordi ingen faktisk klikker på noe. Når TBT går ned, blir både scoren og den reelle INP-verdien vanligvis bedre.

LCP: få hovedinnholdet raskere på skjermen

• Fjern `loading="lazy"` fra toppbildet. WordPress og mange temaer legger på lazy loading automatisk, og da venter nettleseren med å hente bildet som brukeren skal se først. Gi heller toppbildet `fetchpriority="high"`.
• Lever toppbildet i WebP eller AVIF, og ikke større enn skjermen trenger. Et bilde på 2500 piksler for en mobilskjerm på 400 piksler er bortkastet.
• Sjekk responstiden fra serveren (TTFB). Er den treg før noe som helst er tegnet opp på skjermen, kan ikke frontend-optimalisering redde siden. Da er det webhotellet eller mangel på mellomlagring på serveren som er problemet.
• Unngå skyveframvisninger (karuseller) øverst på siden. De gjør LCP tregere og blir sjelden klikket på.

INP og TBT: frigjør hovedtråden

• Gå gjennom tagger i Google Tag Manager, Meta-pikselen, chat-moduler og heatmap-verktøy. Fjern alt som ingen har sett på det siste kvartalet.
• Først når besøkende har samtykket skal markedsføringsskript lastes. Den nye ekomloven, som trådte i kraft 1. januar 2025, krever samtykke på GDPR-nivå før informasjonskapsler som ikke er nødvendige kan settes. Riktig oppsett av samtykket gjør derfor siden både lovlig og raskere. Husk å oppdatere personvernerklæringen når du endrer verktøy.
• Tunge sidebyggere og «alt-i-ett»-temaer laster ofte mye JavaScript på hver side. Les mer om valg av WordPress tema før du legger på flere optimaliseringstillegg.

CLS: hindre at innholdet hopper

• Sett bredde og høyde på alle bilder, videoer og iframes, slik at nettleseren holder av plass til dem.
• La samtykkebanneret ligge oppå innholdet (fast nederst eller som et vindu), ikke dytte innholdet nedover når det dukker opp.
• Last inn nettfonter med `font-display: swap` og bruk en reservefont med omtrent samme mål, slik at teksten ikke flytter seg når fonten byttes.

Etter Lighthouse-optimalisering (bildekomprimering, caching, opprydding i skript) forbedres ytelsesscore hos Box sine kunder typisk fra under 55 til over 80.

Det passer med det vi ser oftest i tekniske gjennomganger. De tre vanligste funnene hos Box er manglende eller feil canonical-tagger, bilder som ikke er optimalisert og treg lastetid på mobil, og alle tre løses normalt på under en arbeidsdag. Bruker du WordPress, ser du hvordan hastighet henger sammen med resten av den tekniske SEO-en i guiden om søkemotoroptimalisering i WordPress.

Hva koster det å gjøre nettsiden raskere?

For en vanlig bedriftsside handler det oftest om timer, ikke om et nytt prosjekt. Prisen avhenger mest av om problemet ligger i innholdet (bilder, skript), i oppsettet (mellomlagring, server) eller i selve temaet. Det siste er dyrest.

Hvor ligger problemet, og hva innebærer det?

• Problem | Typisk tiltak | Omfang | Hvem kan gjøre det
• Store bilder | Komprimere, konvertere til WebP, sette mål | Lite, ofte under en dag | Redaktør med riktig tillegg eller rutine
• For mange skript | Rydde i taggene, laste dem etter samtykke | Lite til middels | Markedsansvarlig sammen med utvikler
• Ingen mellomlagring / treg server | Sidebuffer, CDN, bytte av hosting | Middels | Utvikler eller vertsleverandør
• Tungt tema eller tung sidebygger | Bytte tema eller bygge malene på nytt | Stort | Utvikler, ofte som del av redesign

Den rekkefølgen sparer penger. Ta bilder og skript først, før du bytter webhotell, og bytt webhotell før du vurderer en redesign av nettsiden. erfaringen viser bedrifter som fikk anbefalt nytt nettsted, når problemet egentlig var tre ukomprimerte toppbilder og et chat-skript. Om du budsjetterer for en ny side uansett, viser guiden om hva en nettside koster hvilke prisnivåer som er vanlige. Krav til hastighet bør stå i kravspesifikasjonen fra starten.

Typiske feil som gir deg dårligere resultater

• Teste bare på desktop. Desktop-scoren er nesten alltid høyere og gir en falsk trygghet. Google vurderer mobil og desktop hver for seg.
• Installere tre optimaliseringstillegg samtidig. Tillegg for mellomlagring, minifisering og lazy loading kan overlappe og ødelegge hverandre, og noen ganger hele layouten. Bruk ett, og test etter hver endring.
• Forvente resultater dagen etter. Feltdataene dekker de siste 28 dagene, så forbedringer vises gradvis over omtrent fire uker.
• Tro at Lighthouse sjekker universell utforming. Tilgjengelighetsscoren i Lighthouse fanger bare opp en del av det som kan testes automatisk. Den dokumenterer ikke at du oppfyller WCAG-kravene som Uu-tilsynet fører tilsyn med. Se guiden om universell utforming av nettsider.
• Glemme vedlikeholdet. Nye tillegg, nye sporingskoder og bilder som lastes opp i full størrelse gjør gode resultater dårligere igjen i løpet av noen måneder. Hastighet bør inn i rutinen for drift av nettsiden.

Når det ikke er riktig å jakte på bedre PageSpeed-score

Hvis siden allerede består Core Web Vitals, eller du har så lite trafikk at Google ikke har feltdata, er det sjelden lønnsomt å bruke penger på å øke Lighthouse-scoren. Da gir pengene mer igjen andre steder.

• Du består allerede vurderingen. Å gå fra 75 til 95 i Lighthouse gir ingen dokumentert rangeringsgevinst når feltdataene er grønne.
• Problemet er innhold, ikke hastighet. Rangerer ikke sidene dine fordi de ikke svarer på det kundene søker etter, hjelper ingen millisekunder. Vi ville prioritert bedre tjenestesider og en tydelig landingsside først.
• Du skal uansett bytte plattform innen et halvt år. Da er det bedre å stille hastighetskrav til den nye løsningen enn å lappe på den gamle.
• Det krever at du fjerner funksjoner som gir salg. Et chat-verktøy som gir henvendelser, er verdt noen ekstra millisekunder med INP. Prøv heller å laste det etter første interaksjon før du fjerner det.

Vårt råd er enkelt: Bruk PageSpeed Insights til å finne konkrete feil, og Search Console til å avgjøre om de betyr noe. Vurder deretter om tiltakene gir flere henvendelser, ikke bare et grønnere tall. Er siden bygget uten tanke på mobil fra starten, er responsive nettsider ofte et bedre sted å begynne enn optimalisering av enkeltfiler.

Vil du ha en gjennomgang av hvilke maler som stryker og hva det koster å rette dem, kan vi hjelpe gjennom nettsidetjenestene våre.