Google Lighthouse: Hvordan forbedre ytelse, tilgjengelighet og SEO

Google Ads bruker Quality Score for å avgjøre annonseplassering og kostnad per klikk. Quality Score består av tre faktorer: forventet klikkfrekvens, annonserelevans og landingssideopplevelse. Undersøkelser viser at landingssideopplevelse står for rundt 39 % av den samlede beregningen.

Landingssideopplevelsen vurderes ut fra flere kriterier: hvor relevant og nyttig innholdet er, hvor enkelt nettstedet er å navigere, sideinnlastingshastighet og mobilvennlighet. Google definerer treg lastetid som «regionalt gjennomsnitt pluss tre sekunder». På mobil scorer Google landingssidens hastighet på en skala fra 1 til 10.

I praksis betyr dette at Quality Score har uforholdsmessig stor innvirkning på hva du faktisk betaler for annonsering. Den faktiske CPC-en beregnes slik: (Ad Rank til annonsøren under deg ÷ din Quality Score) + 0,10 kr. Jo høyere Quality Score, desto lavere blir kostnaden per klikk.

Bransjetall viser tydelig hvordan ulike nivåer av Quality Score påvirker CPC sammenlignet med en grunnlinje på 5:

Dokumenterte eksempler viser 20–25 % reduksjon i kostnad per klikk etter forbedringer i landingssidens ytelse. Ett treningssenter forbedret sin Quality Score fra 6 til 9 og så CPC falle fra 35 kr til 24,50 kr – en reduksjon på 30 %. Et Amerikansk energiselskap forbedret sin Quality Score fra 6,5 til 8,9 noe som ga estimerte besparelser på rundt 1.5 millioner dollar, bare i CPC-kostnader.

For bedrifter som bruker titusenvis av kroner på annonser hver måned, betyr dette enten betydelige kostnadsbesparelser – eller langt større rekkevidde for samme budsjett.

Google analyserer hvordan brukere samhandler med nettstedet ditt etter at de klikker på et søkeresultat. Høy bounce rate og kort tid på siden signaliserer at brukerne enten ikke fant det de forventet – eller at opplevelsen var frustrerende.

Lastetid er en av de viktigste faktorene her. Når innholdet ikke vises raskt nok, forlater mange siden før de i det hele tatt har rukket å engasjere seg. Dette er godt dokumentert gjennom flere uavhengige analyser av faktisk brukeradferd:

• Google viser at når lastetiden øker fra 1 til 3 sekunder, øker sannsynligheten for at brukeren forlater siden med rundt 32 %. Ved 5 sekunder øker sannsynligheten med opptil 90 %, og ved 10 sekunder med over 120 %.
• BBC fant at for hvert ekstra sekund en side bruker på å laste, forlater omtrent 10 % av brukerne nettstedet.
• Akamai, som spesialiserer seg på innholdslevering og ytelsesanalyse, viser at en forsinkelse på 2 sekunder kan øke bounce rate med opptil 103 %.
• Pingdom rapporterer at nettsteder som laster på rundt 1 sekund har cirka 7 % bounce rate, mens sider som bruker 5 sekunder ligger nær 38 %.
• Desenio oppnådde 37 % lavere bounce rate, 48 % lengre økter og 34 % bedre konvertering etter å ha optimalisert Core Web Vitals i 2024.
• Rakuten 24 rapporterte 53 % økning i omsetning per besøkende etter tilsvarende ytelsesforbedringer.

Når sider laster raskt og stabilt, skjer det motsatte av frafall: brukerne blir lenger, ser flere sider og interagerer mer med innholdet. Disse engasjementsignalene – bounce rate, tid på side og sider per økt – brukes av Google som indirekte kvalitetsindikatorer.

Over tid gir dette bedre forutsetninger for stabile, organiske rangeringer. Ytelse avgjør ikke bare hvor høyt du rangerer, men hvor lenge du klarer å bli der.

Sidehastighet har direkte innvirkning på hvor mange besøkende som faktisk blir kunder. Selv små forbedringer i lastetid kan gi målbare utslag på både konverteringsrate og omsetning.

Store analyser av reelle brukerøkter viser et konsistent mønster:

• Google og Deloitte fant i studien Milliseconds Make Millions, basert på 30 millioner brukerøkter, at en forbedring på 0,1 sekund (100 ms) i lastetid ga:

  • 8,4 % økning i konverteringer og 9,2 % økning i gjennomsnittlig ordreverdi i detaljhandel
  • 10,1 % økning i konverteringer innen reise
  • 8,6 % flere sidevisninger per økt for luksusvarer

• Portent analyserte 27 000 landingssider og fant at konverteringsraten faller med rundt 4,4 % for hvert ekstra sekund med lastetid mellom 0 og 5 sekunder.

  • E-handelssider som laster på 1 sekund har rundt 3 % konverteringsrate
  • Ved 5 sekunders lastetid, faller den til rundt 1 %
  • B2B-sider som laster på 1 sekund konverterer 3 ganger høyere enn sider som bruker 5 sekunder, og 5 ganger høyere enn sider som laster på 10 sekunder
    x

• Google/SOASTA viser at 53 % av mobilbrukere forlater en side som bruker mer enn 3 sekunder på å laste.

Effekten er enda sterkere på mobil, der de fleste brukere i 2026 befinner seg. Mobile enheter har langt svakere prosessorer enn laptop eller stasjonær PC, og JavaScript tar betydelig lenger tid å kjøre. Lighthouse simulerer dette med 4× CPU-throttling i sine mobiltall.

Analyser viser også at rimelige Android-telefoner kan være over 4 ganger tregere enn moderne toppmodeller, og ytelsesgapet øker hvert år.

Et nettsted som føles umiddelbart responsivt bygger tillit. Et tregt nettsted mister besøkende før de i det hele tatt rekker å vurdere tilbudet.

I praksis er det svært få norske nettsteder som faktisk optimaliserer for ytelse og brukeropplevelse. Vi har selv jobbet med kunder som bruker tusenvis av konsulenttimer på UX, uten å ta høyde for at ytelse også er en helt sentral del av brukeropplevelsen.

Når de fleste norske nettsteder ligger rundt 60–70 i Lighthouse, og de beste når 90, gir det å komme helt til 100 et tydelig forsprang. Sidene laster raskere, rangerer bedre i søk, det koster mindre å annonsere – og konverterer flere besøkende.

Når det er sagt, er det ikke alltid nødvendig å oppnå full score i alle kategorier. Poenget er ikke å jage 100 for enhver pris, men å sikre at du konsekvent ligger foran konkurrentene. I praksis betyr det at du alltid vil være på minst 90 på ytelse, og 100 på tilgjengelighet, beste praksis og SEO.

Mange stopper når resultatene ser «gode nok» ut. Da er prosjektet levert, og man går videre. Men det er nettopp her at mange går glipp av det viktige konkurransefortrinnet.

De siste 10 prosentene skiller nettsteder som fungerer stabilt i virkeligheten, fra nettsteder som først og fremst ser bra ut i rapporter og presentasjoner. Over tid er det disse marginene som avgjør hvem som vinner trafikken – og kundene.

Ytelsesresultatet måler hvor raskt siden laster og hvor fort den blir brukbar for brukeren. I Lighthouse 10+ beregnes dette basert på fem metrikker, som vektes ulikt:

Largest Contentful Paint (LCP) måler hvor lang tid det tar før det største synlige innholdselementet er lastet og vises.
Bra: ≤ 2,5 sekunder.
Dårlig: > 4 sekunder.

Interaction to Next Paint (INP) erstattet First Input Delay som Core Web Vital i mars 2024. INP måler hvor raskt nettstedet responderer på brukerinteraksjoner.
Bra: ≤ 200 ms.
Dårlig: > 500 ms.

I laboratorietester bruker Lighthouse Total Blocking Time (TBT) som en erstatning, siden INP krever faktiske brukerinteraksjoner for å kunne måles presist.

Cumulative Layout Shift (CLS) måler visuell stabilitet – altså hvor mye innhold flytter seg uventet under lasting.
Bra: ≤ 0,1.
Dårlig: > 0,25.

First Contentful Paint (FCP) måler hvor raskt det første synlige innholdet vises på skjermen.
Bra: ≤ 1,8 sekunder.
Dårlig: > 3 sekunder.

En score på 90 betyr at nettstedet ditt er blant de øverste prosentene globalt. En score på 100 plasserer deg helt i toppsjiktet når det gjelder faktisk nettytelse.

Tilgjengelighet måler om nettstedet kan brukes av alle, inkludert personer som benytter skjermlesere, tastaturnavigasjon eller har nedsatt syn eller motorikk.

Lighthouse bruker axe-core for automatisert tilgjengelighetstesting. Slike tester fanger imidlertid bare rundt 30–40 % av mulige WCAG-problemer. En score på 100 betyr derfor ikke at nettstedet er fullt tilgjengelig – men at det består de automatiserte kontrollene.

Manuell testing med skjermlesere og tastaturnavigasjon er fortsatt nødvendig for å avdekke resten.

Lighthouse sjekker blant annet:

• Alt-tekst på bilder
• Fargekontrast
• Skjemaetiketter
• ARIA-attributter
• Overskriftshierarki
• Synlige fokusindikatorer
• Størrelse på klikk- og trykkflater

Beste praksis dekker generell teknisk kvalitet og sikkerhet, og fanger opp problemer som kan gi konsekvenser over tid. Dette inkluderer blant annet bruk av HTTPS, fravær av konsollfeil, riktige bildeforhold og gyldige source maps.

SEO-delen verifiserer at søkemotorer faktisk kan crawle, indeksere og forstå innholdet på nettstedet ditt. Lighthouse kontrollerer blant annet metabeskrivelser, robots.txt, korrekt viewport-oppsett, lesbare skriftstørrelser og beskrivende lenketekst.

En Lighthouse-score på 100 innen SEO betyr ikke at du automatisk vil rangere høyt i søk. Den bekrefter at det tekniske grunnlaget er på plass, slik at søkemotorene kan gjøre jobben sin uten hindringer.

Bilder er ofte den tyngste ressursen på en nettside. På mange nettsteder står bilder for flere overførte bytes enn noen annen ressurs. Uten optimalisering fører dette raskt til treg lasting og dårlig LCP.

Løsningen er å tilby flere bildestørrelser og la nettleseren velge den som passer best for skjermen som brukes. Samtidig må nettleseren vite hvor mye plass bildet skal oppta før det lastes, for å unngå layout shifts.

Last kun JavaScript når det faktisk trengs. Funksjonalitet som ikke er synlig eller relevant ved første sidevisning bør lastes senere. Dette er viktig fordi JavaScript har dobbel kostnad: det må både lastes ned og kjøres.

På mobile enheter er det kjøringen av JavaScript som ofte er flaskehalsen. En rimelig Android-telefon kan bruke fire til seks ganger lengre tid på å parse og kjøre samme JavaScript som en moderne toppmodell. Data fra HTTP Archive viser at mobilsider ved 75-persentilen har nesten tre sekunder med blokkeringstid, og ved 90-persentilen nærmere seks sekunder.

Kodesplitting reduserer denne belastningen ved å dele JavaScript i mindre biter som lastes ved behov, i stedet for alt på én gang.

Med server-side rendering (SSR) sendes den første HTML-en ferdig rendret fra serveren. Brukeren får innhold på skjermen umiddelbart, i stedet for å møte en tom side mens JavaScript lastes og kjøres. Dette gir direkte forbedringer i både First Contentful Paint og Largest Contentful Paint.

Ulempen er økt kompleksitet. Serveren må rendre siden før den sendes til klienten, og nettleseren må deretter «hydrere» HTML-en med JavaScript for å gjøre siden interaktiv. Når samspillet mellom server og klient fungerer som det skal, kombineres rask visning med full funksjonalitet.

Dersom implementeringen er mangelfull, kan SSR derimot skape nye problemer – innhold som hopper, eller sider som ser ferdige ut, men ikke responderer. Det forutsetter at server og klient faktisk er enige om hva som skal vises.

CSS som trengs for innholdet øverst på siden kan legges direkte inn i HTML-en. Da slipper nettleseren å vente på eksterne stilark før den kan vise den første visningen, og render-blokkerende forespørsler fjernes fra den kritiske banen.

Dette forutsetter at du identifiserer hvilke CSS-regler som faktisk er nødvendige for første visning, og kun inkluderer disse. Resten av CSS-en lastes asynkront etterpå.

Verktøy som Critical og Critters kan automatisere denne prosessen, men prinsippet er enkelt: brukeren skal ikke måtte vente på CSS som ikke er nødvendig for det som vises først.

Egendefinerte skrifttyper kan føre til både usynlig tekst og uønskede layout-endringer dersom de ikke håndteres riktig. Dette påvirker både brukeropplevelsen og Lighthouse-scoren.

God håndtering av skriftinnlasting innebærer blant annet:

1. Forhåndslast kritiske skrifttyper – gi nettleseren tidlig beskjed om hvilke skrifter som er viktige
2. Bruk font-display: swap – vis tekst med en reserveskrifttype (fallback-font) umiddelbart, og bytt til riktig skrifttype når den er ferdig lastet
3. Bruk WOFF2-format – gir bedre komprimering og bred støtte i moderne nettlesere
4. Begrens tegnsettet – inkluder kun tegnene som faktisk brukes på nettstedet

Når dette gjøres riktig, unngår du både usynlig tekst og merkbare layout-hopp når skrifttyper lastes inn.

Nettleseren kan starte å laste ressurser på forhånd dersom du forteller den hvilke ressurser som snart vil bli brukt. Dette gjøres ved å etablere tilkoblinger og starte nedlasting tidlig, før ressursene ellers ville blitt oppdaget.

preconnect brukes for å opprette tidlige forbindelser til eksterne domener du er avhengig av, som CDN-er, skriftleverandører eller API-er. Dette fjerner tidkrevende steg som DNS-oppslag, TCP-håndtrykk og TLS-forhandling fra den kritiske banen.

preload brukes når du vet at en bestemt ressurs vil bli nødvendig tidlig, men normalt oppdages sent av nettleseren – for eksempel skrifttyper eller kritisk CSS som lastes indirekte. Brukt riktig kan dette gi merkbare forbedringer i både First Contentful Paint og Largest Contentful Paint.

Disse teknikkene bør brukes målrettet og med måte. For mange forhåndslastede ressurser kan gi motsatt effekt og konkurrere med det som faktisk er viktigst for første visning.

Lighthouse tester rundt 30–40 % av suksesskriteriene i WCAG gjennom automatiserte kontroller. Å bestå disse testene er nødvendig for å oppnå full score, men det er ikke tilstrekkelig for å sikre full tilgjengelighet.

Automatiserte tester kan avdekke mange tekniske feil, men de fanger ikke opp alt. Manuell testing med skjermleser og tastatur-navigasjon er fortsatt nødvendig for å sikre at nettstedet faktisk fungerer godt for alle brukere.

WCAG AA stiller konkrete krav til kontrast mellom tekst og bakgrunn for å sikre god lesbarhet:

• Vanlig tekst (mindre enn 18 pt, eller 14 pt fet): minimum 4,5:1
• Stor tekst (18 pt / 24 px eller større, eller 14 pt / 18,5 px fet): minimum 3:1
• UI-komponenter og grafiske elementer: minimum 3:1

Dette er absolutte terskelverdier. Et kontrastforhold på 4,49:1 oppfyller ikke kravet på 4,5:1 – det finnes ingen avrunding eller slingringsmonn.

Kravene er satt for å kompensere for redusert kontrastsyn, tilsvarende rundt 20/40-syn, som er vanlig hos eldre brukere. God kontrast gjør samtidig tekst lettere å lese for alle – spesielt på eldre eller rimeligere telefoner og nettbrett, og når øynene er slitne mot slutten av dagen.

Alle interaktive elementer må ha en tydelig og synlig fokusindikator. Når brukeren navigerer med tastatur, skal det alltid være klart hvilket element som har fokus.

Tab-rekkefølgen bør følge en logisk leserekkefølge. Dette er spesielt viktig for brukere som navigerer uten mus.

WCAG 2.2 stiller i tillegg tydeligere krav:

• Fokuserte elementer kan ikke være helt skjult av annet innhold (2.4.11 Focus Not Obscured)
• Interaktive elementer må ha en minimumsstørrelse på 24 × 24 CSS-piksler (2.5.8 Target Size Minimum)

God fokushåndtering gjør det mulig å bruke nettstedet effektivt uten mus, og sikrer at brukeren alltid vet hvor i grensesnittet de befinner seg.

For brukere som benytter skjermleser, er struktur avgjørende. Skjermlesere tolker ikke visuell layout, men navigerer ut fra dokumentets semantikk og struktur.

Riktig overskriftshierarki ved bruk av <h1> til <h6> gir innholdet en logisk oppbygning. Dette gjør det mulig å hoppe raskt mellom seksjoner, på samme måte som seende brukere skanner en side visuelt.

Landemerkeregioner, også kalt semantiske hovedområder, brukes for å definere sidens struktur. Elementer som <header>, <nav>, <main> og <footer> gjør det mulig for skjermleserbrukere å hoppe direkte til ønskede deler av siden, uten å måtte gå gjennom alt innhold sekvensielt.

Beskrivende lenketekst er også viktig. Lenker som «Les hele rapporten» eller «Gå til kontaktskjema» gir mening i seg selv, i motsetning til generiske lenker som «klikk her».

God skjermleserstøtte handler ikke om spesialtilpasninger, men om å bruke HTML slik den er ment å brukes.

Noen brukere opplever ubehag eller kvalme ved animasjoner og bevegelige overganger. Dette gjelder særlig personer med vestibulære lidelser, men kan også påvirke andre i mindre grad.

Nettlesere gir brukere mulighet til å signalisere dette gjennom innstillingen prefers-reduced-motion. Når denne er aktiv, bør animasjoner enten reduseres kraftig eller slås helt av.

Selv for brukere som ikke har aktivert denne innstillingen, bør animasjoner være tilbakeholdne og funksjonelle. Bevegelse skal støtte innholdet – ikke være en distraksjon.

Overskriftshierarki
Bruk én <h1> som hovedoverskrift, med en logisk struktur av <h2> og <h3> videre nedover. Google har bekreftet at flere <h1>-tagger ikke nødvendigvis skader rangering, men et tydelig hierarki gjør innholdet enklere å forstå – både for brukere og søkemotorer.

Metadata
Hver side bør ha en unik sidetittel og metabeskrivelse. Titler bør som regel holdes innen 50–60 tegn for å unngå avkorting i søkeresultater. Metabeskrivelser er ikke en direkte rangeringsfaktor, men påvirker klikkfrekvensen. Hvis beskrivelsen ikke samsvarer godt med søket, omskriver Google den ofte automatisk.

Kanoniske URL-er
Alle indekserbare sider bør ha en selvrefererende canonical. Bruk absolutte URL-er. Vanlige feil er å peke canonical til en 404-side, ha flere canonical-tagger på samme side, eller ha innhold som ikke samsvarer mellom kanonisk og faktisk side.

Mobil-først-indeksering
Google crawler nå nettsteder utelukkende med Googlebot Smartphone. Innhold som ikke er tilgjengelig på mobil, blir ikke indeksert. Mobil- og desktopversjon må derfor ha samme innhold, metadata, strukturert data og overskrifter.

Strukturert data
Bruk strukturert data i JSON-LD-format for å hjelpe søkemotorer med å forstå innholdet. Vanlige typer er Article, Product, Event, Organisation og Local Business. Merk at FAQ-strukturert data nå i hovedsak kun vises for autoritative offentlige og helserelaterte nettsteder.

Robots.txt og sitemap
Sitemapet bør kun inneholde kanoniske URL-er som faktisk skal indekseres. Husk at robots.txt blokkerer crawling, ikke indeksering. Hvis du vil forhindre at en side vises i søkeresultater, må noindex brukes.

Alle ressurser levert over HTTPS
Blandet innhold gir både sikkerhetsadvarsler og svekker tilliten til nettstedet.

Ingen konsollfeil eller utdaterte API-er
Avhengighet til foreldede nettleser-API-er kan føre til at funksjonalitet slutter å virke over tid.

Bilder med riktige størrelsesforhold
Bilder som strekkes eller klemmes feiler Lighthouse sine kontroller og gir dårligere visuell kvalitet.

Gyldige source maps
Source maps gjør det mulig å feilsøke produksjonsfeil uten å eksponere uminifisert kode for sluttbrukere.

Et nettsted med et ryddig teknisk fundament tåler endringer bedre over tid. Nettleseroppdateringer bryter ikke funksjonalitet, sikkerhetsskannere flagger færre problemer, og teknisk gjeld bygger seg opp saktere.

Rocket Loader
Rocket Loader utsetter JavaScript ved å omskrive HTML-en som sendes til nettleseren. For applikasjoner som bruker server-side rendering skaper dette ofte problemer med hydrering, synlige layout-hopp og i enkelte tilfeller ødelagt funksjonalitet. React- og Next.js-applikasjoner er særlig utsatt. Bruker du SSR, bør Rocket Loader som hovedregel være deaktivert.

Automatisk minifisering i CDN
Minifisering bør skje i byggeprosessen, ikke i CDN-et. Når CSS og JavaScript allerede er optimalisert ved bygging, gir ytterligere minifisering ingen gevinst og kan i noen tilfeller skape problemer med source maps og integritetssjekker. CDN-et bør levere det som allerede er bygget – ikke endre det.

Brotli-komprimering
Brotli gir merkbart mindre filer enn gzip for tekstbaserte ressurser som HTML, CSS og JavaScript. For sluttbrukeren betyr dette raskere nedlasting uten negative bieffekter, og bør være aktivert der det er tilgjengelig.

HTTP/3
HTTP/3 gir raskere oppkobling, spesielt på mobilnettverk. Protokollen håndterer pakketap bedre enn tidligere versjoner og reduserer ventetid ved ustabile forbindelser. For nettsteder med mye mobiltrafikk gir dette ofte målbare forbedringer i innlastingstid.

Early Hints (HTTP 103)
Early Hints gjør det mulig å varsle nettleseren om kritiske ressurser før serveren er ferdig med å generere svaret. Mens backend rendrer innhold, kan nettleseren allerede starte nedlasting av CSS, skrifttyper og andre nødvendige filer. Riktig brukt gir dette tydelige forbedringer i Largest Contentful Paint.

Aggressiv caching av statiske ressurser
Statiske filer med versjonerte filnavn kan caches svært aggressivt. Når filnavnet endres, brytes cachen automatisk. Dynamisk innhold bør derimot håndteres separat og ikke caches på samme måte.

Den beste CDN-konfigurasjonen er i praksis usynlig. Den gjør nettstedet raskere uten å omskrive, optimalisere eller «forbedre» kode som allerede er bygget riktig.