Hvorfor en rask nettside betyr mer enn bare en høy Lighthouse-score

Lighthouse-scoren er blitt et slags karakterkort for nettsider. Det er forståelig: tallet er enkelt å måle, sammenligne og vise frem. Likevel er en høy score ikke målet i seg selv. Det som betyr noe, er at nettsiden oppleves rask og stabil for dem som faktisk bruker den, og at ytelsesarbeidet ikke ødelegger noe underveis.

Hva brukeren faktisk merker

For en besøkende handler ytelse om tre ting:

• Hvor raskt det viktigste innholdet vises. Ser jeg det jeg kom for, eller en tom side?
• Om siden står stille. Hopper teksten når bilder, annonser eller bannere lastes inn?
• Hvor raskt siden svarer. Skjer det noe når jeg trykker på en knapp eller åpner menyen?

Det er nettopp dette Googles Core Web Vitals prøver å måle.

De tre målene, forklart enkelt

LCP (Largest Contentful Paint)

Hvor lang tid det tar før det største synlige elementet, ofte et hovedbilde eller en stor overskrift, er ferdig lastet. Google regner 2,5 sekunder eller mindre som bra.

CLS (Cumulative Layout Shift)

Hvor mye innholdet flytter på seg mens siden laster. Et typisk eksempel er at du skal trykke på en lenke, og så dukker det opp et bilde over som skyver alt nedover. En verdi på 0,1 eller lavere regnes som bra.

INP (Interaction to Next Paint)

Hvor raskt siden reagerer når du klikker, trykker eller skriver. INP erstattet det eldre målet FID i 2024. Under 200 millisekunder regnes som bra.

I Lighthouse ser du også TBT (Total Blocking Time). Det er et laboratoriemål for hvor lenge nettleseren er opptatt med JavaScript, og gir en indikasjon på hvordan siden vil oppføre seg ved interaksjon.

Laboratoriedata og ekte brukere

Lighthouse simulerer én besøkende, på én type enhet, med én type nettverk. Det er nyttig for å finne problemer og sammenligne endringer, men det er ikke det samme som virkeligheten.

Feltdata, som du finner i Search Console og Chrome-brukerrapporten, viser hvordan ekte brukere faktisk opplever siden, på sine egne telefoner og nettverk. De to kan vise forskjellige ting. En side kan score middels i Lighthouse og likevel oppleves rask for de fleste, eller score høyt i en test og være treg for brukere med eldre telefoner.

For mindre nettsteder finnes det ofte ikke nok feltdata. Da er laboratoriemålinger det beste man har, men resultatet bør leses som en pekepinn.

Hvor tiden faktisk går

Serverrespons

Før nettleseren kan gjøre noe, må serveren svare. Treg hosting, tunge databasespørringer eller mange utvidelser som kjører på hver forespørsel gir forsinkelse helt i starten, og den forsinkelsen påvirker alt som kommer etter.

Caching

Caching betyr at ferdige sider eller data lagres, slik at de ikke må bygges på nytt for hver besøkende. Det er ofte den enkeltendringen som gir mest. Men caching må settes opp med omtanke: innloggede brukere, handlekurv, kasse og skjemaer trenger ofte ferskt innhold.

Bilder

Bilder er ofte den største delen av en side. Riktig størrelse, moderne formater som WebP og responsive varianter for ulike skjermer gjør mye. Bilder under første skjermbilde kan lastes når de trengs. Hovedbildet øverst skal derimot ikke utsettes, fordi det ofte er det LCP måler. Faste bredde- og høydeattributter forhindrer at siden hopper når bildene kommer.

Fonter

Hver fontvariant er en egen fil. Mange vekter og stiler gir mange filer. Fonter som lastes fra eksterne tjenester, krever i tillegg en ekstra tilkobling. Å hoste fontene på eget domene og bruke færre varianter er enkle grep.

JavaScript

JavaScript er den vanligste årsaken til at en side føles treg å bruke. Typiske syndere er biblioteker som lastes på alle sider selv om de bare trengs på én, animasjoner som krever mye kode, og byggeverktøy som legger til mer enn nødvendig.

Tredjepartsskript

Analyse, chat, kart, sosiale medier, annonser og samtykkebannere kommer ofte fra andre tjenester. Hver av dem har en kostnad, og du har begrenset kontroll over hvor raske de er. Spør for hvert skript: trengs dette, og trengs det på alle sider?

Hvorfor aggressiv optimalisering kan skade

Det finnes verktøy som lover høy score med ett klikk: utsett all JavaScript, slå sammen alle filer, lat-last alle bilder, cache alt. Resultatet kan bli en fin score og en nettside som ikke fungerer. Vanlige bivirkninger er:

• skjemaer og bookingløsninger som slutter å fungere fordi skript lastes for sent
• samtykkebannere som ikke vises eller ikke respekteres
• hovedbildet lastes for sent fordi det ble lat-lastet
• innloggede brukere eller handlekurver som får mellomlagret innhold

Ytelse er et middel, ikke et mål. En litt lavere score på en side som fungerer, er bedre enn en perfekt score på en side der besøkende ikke får sendt inn skjemaet.

Fra eget arbeid

Da jeg bygget om mitt eget nettsted, kom mesteparten av ytelsesforbedringen fra å fjerne ting, ikke fra triks: skript som ikke trengtes, eksterne kall som kunne gjøres lokalt, og fonter som ble flyttet til eget domene. Cachingen ble satt opp konservativt, slik at skjemaer, booking og samtykke fortsatt fungerer som de skal. Den erfaringen gjelder de fleste nettsider: færre avhengigheter gir både bedre ytelse og mindre vedlikehold.

En enkel sjekkliste

• Mål både i Lighthouse og i Search Console, og se på mobil først.
• Finn det største elementet øverst og sørg for at det lastes tidlig.
• Gi alle bilder riktig størrelse, moderne format og faste dimensjoner.
• Fjern skript og utvidelser som ikke trengs.
• Host fonter lokalt og bruk færre varianter.
• Sett opp caching med tanke på hva som må være dynamisk.
• Test skjemaer, kasse, booking og samtykke etter hver endring.

Oppsummering

En rask nettside handler om hva brukerne opplever: innhold som vises raskt, en side som står stille, og knapper som reagerer. Lighthouse er et nyttig verktøy for å finne problemer, men ikke en fasit. Den beste ytelsen kommer som regel fra en enkel og ryddig løsning, sjelden fra aggressive innstillinger.

Opplever du at nettsiden er treg? Ytelse er en del av både webdesign og webutvikling, og god ytelse er også en del av teknisk SEO. Skal den holdes stabil over tid, er det noe en driftsavtale kan ta vare på.