Nettsiden kan virke rask på kontoret og likevel være tung å bruke på en mobil. Kanskje hovedbildet dukker opp sent. Kanskje menyen ikke reagerer med en gang, eller en knapp flytter seg akkurat når kunden skal trykke.
Jeg ville startet med disse konkrete problemene. Målet er at kunden får lest innholdet og gjort det hun kom for. Rådene under bygger på dokumentasjon fra Google og web.dev, kontrollert 26. september 2026.
Start med det kunden skal gjøre
Åpne nettsiden på mobilen og prøv den vanligste oppgaven. Finn en tjeneste, les om den og ta kontakt. Prøv gjerne med mobilnett i tillegg til det trådløse nettet på kontoret.
Noter hvor du må vente, om teksten er lett å lese, og om skjemaet faktisk lar seg bruke. Test også en underside. Det hjelper lite at forsiden er rask dersom siden kunden lander på fra Google, har et tungt galleri eller en bestilling som låser seg.
Dette er min praktiske gjennomgang, ikke en erstatning for målinger. Den gjør det lettere å forstå hvilke funn i en teknisk rapport som betyr noe for kundene.
Skill mellom en test og faktiske besøk
PageSpeed Insights viser en simulert test og, når det finnes nok data, målinger fra faktiske besøkende. Testen er nyttig når du skal finne feil. Besøksdataene beskriver opplevelser fra de siste 28 dagene.
En liten eller ny nettside kan mangle besøksdata. Verktøyet kan også vise tall for hele nettstedet når den konkrete siden har for få målinger. Se derfor hva tallene gjelder før du sammenligner. Google forklarer forskjellen mellom datatypene.
Ta gjerne vare på rapporten før du endrer noe. Da kan du sammenligne samme side og samme type test etterpå. En enkelt poengsum bør ikke alene avgjøre om hele nettsiden må bygges på nytt.
Tre målinger som sier noe nyttig
Google samler tre sentrale målinger under navnet Core Web Vitals:
- LCP: Hvor lang tid det tar før det største synlige bildet eller tekstfeltet vises. Grensen for en god verdi er 2,5 sekunder.
- INP: Hvor raskt siden reagerer visuelt når noen for eksempel trykker på en knapp. Grensen for en god verdi er 200 millisekunder.
- CLS: Hvor mye innholdet flytter seg uventet mens siden brukes. Grensen for en god verdi er 0,1.
Grensene vurderes ved den 75. persentilen. Det betyr at minst 75 prosent av de målte besøkene skal være innenfor grensen for den aktuelle målingen. web.dev forklarer målingene og grensene.
Mitt råd er å bruke dem til å stille konkrete spørsmål: Kommer innholdet sent? Reagerer knappen tregt? Hopper siden? Det gir en mer forståelig bestilling til utvikleren enn «få alt grønt».
Se på bilder og det som lastes først
Hvis hovedbildet kommer sent, ville jeg undersøkt både filstørrelsen og når nettleseren begynner å hente bildet. En mindre fil hjelper ikke nok hvis bildet først blir oppdaget etter at mye annen kode er kjørt.
Bildet øverst på siden bør normalt kunne hentes tidlig. Bilder langt nede kan ofte vente til leseren nærmer seg dem. Sett også av plass til bildene, slik at teksten rundt slipper å flytte seg når de vises. Se veiledningene om raskere visning av hovedinnhold og å unngå innhold som flytter seg.
Be om at bildene tilpasses størrelsen de faktisk vises i. Jeg ville samtidig beholdt nok kvalitet til at kunden kan vurdere produktet eller arbeidet på bildet.
Kontroller eksterne funksjoner
Kart, video, chat og bestilling kan være nyttige, men kan også legge til kode som konkurrerer om nettleserens kapasitet. web.dev beskriver hvordan kode fra andre tjenester kan påvirke lasting og respons.
Jeg ville gått gjennom hvilke funksjoner kundene bruker, og testet effekten av å laste resten senere. Et kart kan for eksempel vises når kunden ber om det. Bestillingen må fortsatt være enkel å finne og bruke. Gjør slike endringer i en testversjon før du fjerner noe fra nettsiden kundene bruker.
Slik ville jeg prioritert arbeidet
- Rett feil som hindrer lesing, kontakt eller bestilling.
- Undersøk det som forsinker det viktigste innholdet.
- Rett innhold som flytter seg og knapper som reagerer sent.
- Test de samme oppgavene på nytt, både manuelt og med måleverktøy.
- Følg med på besøksdata når det finnes tilstrekkelig grunnlag.
Be om en forklaring av hva som ble endret og hvilke målinger som viser forbedringen. Hvis løsningen heller bør erstattes, bør du også sammenligne det med kostnaden ved en ny nettside.