Slik leser du en Lighthouse-rapport uten å få panikk

Første regel: poengsummen er ikke nettstedet ditt

Åpner du en Lighthouse-rapport for første gang, møtes du av en vegg av tall, fargekodede bokser og advarsler om ting du aldri har hørt om. Den naturlige reaksjonen er panikk. Poengsummen er rød. Sytten revisjoner har feilet. Nettstedet må vel være ødelagt?

Det er det sannsynligvis ikke. Lighthouse er et diagnostikkverktøy, ikke et karakterkort. Poengsummen er en syntetisk benchmark kjørt under laboratorieforhold – ofte på en strupet tilkobling som simulerer en mellomklassemobil fra 2017. Den forteller deg hvordan nettstedet ditt fungerer i akkurat dette scenarioet, ikke hvordan ekte brukere opplever det i praksis.

Dette er viktig fordi de fleste team henger seg opp i poengsummen og mister konteksten. En poengsum på 65 kan være helt grei for en kompleks webapp med sanntidsdata. En poengsum på 95 kan fortsatt gi en dårlig opplevelse hvis feil ting er optimalisert. Poengsummen er et utgangspunkt for undersøkelse, ikke et suksessmål.

Hva du bør lese først: Core Web Vitals

Hopp over den samlede ytelsespoengsummen. Rull ned til delen Metrics og se på tre tall: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) og Interaction to Next Paint (INP). Dette er Core Web Vitals, og de er de eneste ytelsesmålingene Google bruker som rangeringssignal.

• LCP måler hvor lang tid det tar før det største synlige elementet gjengis. Mål: under 2,5 sekunder. Hvis du ligger over 4 sekunder, venter brukerne for lenge på å se meningsfullt innhold.
• CLS måler visuell stabilitet – hvor mye siden hopper rundt mens den lastes. Mål: under 0,1. Hvis du ligger over 0,25, klikker brukerne utilsiktet på feil ting fordi knapper flytter seg.
• INP måler responsivitet – hvor raskt siden reagerer på klikk, trykk og tastetrykk. Mål: under 200 ms. Hvis du ligger over 500 ms, føles nettstedet tregt.

Disse tre målingene korrelerer med faktisk brukerfrustrasjon. Rett disse før du bekymrer deg for noe annet.

Muligheter kontra diagnostikk: kjenn forskjellen

Lighthouse deler funnene sine i to kategorier: Opportunities og Diagnostics. Opportunities rangeres etter estimert tidsbesparelse. Diagnostics er tilleggskontekst – ting som kan være problemer, eller kanskje ikke.

Start med Opportunities. Hvis Lighthouse sier at "Eliminate render-blocking resources" kan spare 1,2 sekunder, er det en konkret gevinst. Hvis den sier at "Reduce unused JavaScript" kan spare 0,1 sekunder, er det sannsynligvis ikke verdt refaktoreringen.

Diagnostics er vanskeligere. "Avoid an excessive DOM size" høres ille ut, men hvis CLS-en din er fin og INP-en er rask, er det ikke sikkert en stor DOM skader noen. Diagnostics er spor, ikke påbud. Undersøk dem som samsvarer med de faktiske målingene dine.

Revisjonene du vanligvis kan ignorere

Noen Lighthouse-advarsler er foreldede eller overdrevent aggressive. Her er de som skaper mest unødvendig panikk:

• "Does not use passive listeners to improve scrolling performance" — Dette er en mikrooptimalisering som sjelden gir merkbar effekt. Med mindre du har bevis på hakkete rulling, kan du hoppe over den.
• "Image elements do not have explicit width and height" — Dette er relevant for CLS, men bare hvis bilder forårsaker layoutskift. Hvis CLS-en din allerede er god, bør du ikke refaktorere bare for revisjonens skyld.
• "Serve images in next-gen formats" — Ja, WebP og AVIF er mindre. Men hvis bildene dine allerede er optimalisert og LCP-en er rask, er dette kjekt å ha, ikke en krise.
• "Avoid enormous network payloads" — Lighthouse flagger alt over 1,6 MB. Men en side på 2 MB som lastes raskt, er bedre enn en side på 500 KB som blokkerer gjengivelse. Fokuser på hvordan bytene leveres, ikke bare totalen.

Hva du gjør når alt er rødt

Hvis Lighthouse-poengsummen din er under 50 og de fleste revisjoner feiler, har du sannsynligvis å gjøre med en av tre rotårsaker:

1. Uoptimaliserte skrifter. Webfonter er fortsatt den enkleste ytelsesgevinsten på de fleste nettsteder. Sjekk om du laster seks skriftvekter når du bare bruker to, eller sender WOFF-filer i stedet for WOFF2.
2. Gjengivelsesblokkerende CSS og JavaScript. Hvis First Contentful Paint (FCP) er over 3 sekunder, er det noe som hindrer nettleseren i å male siden. Se etter store CSS-filer eller synkrone skript i <head>.
3. For store bilder. Hvis LCP-elementet ditt er et bilde og det er 4 MB, er det problemet ditt. Komprimer det, lazy-load bilder under folden, og bruk responsiv bildesyntaks.

Rett én av disse og kjør Lighthouse på nytt. Du vil ofte se et hopp på 20–30 poeng. Deretter tar du neste.

Labdata kontra feltdata: realitetssjekken

Lighthouse kjører i et laboratorium. Det simulerer en treg tilkobling og en treg enhet, men det kan ikke simulere ekte brukeratferd – hvordan folk ruller, hva de klikker på, eller om de er på ustabil Wi-Fi.

Som en realitetssjekk kan du sammenligne Lighthouse-resultatene dine med feltdata fra Chrome User Experience Report (CrUX). CrUX viser hvordan ekte Chrome-brukere har opplevd nettstedet ditt de siste 28 dagene. Hvis Lighthouse sier at LCP-en din er 4 sekunder, men CrUX viser 2 sekunder, stol på CrUX. Hvis begge er dårlige, har du et reelt problem.

Du finner CrUX-data i PageSpeed Insights (nettversjonen av Lighthouse) eller i Google Search Console under "Core Web Vitals." Hvis det er et avvik, undersøk hvorfor. Kanskje de ekte brukerne dine er på raskere nettverk. Kanskje Lighthouse tester et uoptimalisert utviklingsbygg.

Når du bør kjøre Lighthouse på nytt

Lighthouse har støy. Kjør det tre ganger på rad, og du får tre forskjellige poengsummer, selv på samme side. Dette skyldes at ytelse varierer – bakgrunnsprosesser, nettverksjitter og nettleserheuristikk påvirker alle resultatet.

For å få et stabilt utgangspunkt bør du kjøre Lighthouse i inkognitomodus med alle utvidelser deaktivert, eller bruke CLI med flagget --preset=desktop for mer konsistente resultater. Kjør det tre ganger og ta gjennomsnittet av poengsummene. Hvis du ser store svingninger (mer enn 10 poeng), er noe annet galt – kanskje serveren er treg, eller siden laster ulike ressurser hver gang.

Kjør Lighthouse på nytt etter hver vesentlige endring. Har du rullet ut en ny skriftstrategi? Sjekk LCP. Lazy-loadet bilder? Sjekk CLS. Lagt til et tredjepartsskript? Sjekk INP. Ytelse er ikke en engangsrettelse; det er et budsjett du forsvarer.

Verktøyene som hjelper deg å handle på Lighthouse-funn

Lighthouse forteller deg hva som er tregt. Det forteller deg ikke alltid hvordan du fikser det. Til det trenger du flere verktøy:

• WebPageTest gir deg en filmstripevisning av hvordan siden lastes, bilde for bilde. Uunnværlig for å diagnostisere LCP- og CLS-problemer.
• Chrome DevTools Performance panel viser deg nøyaktig hvilken JavaScript som blokkerer hovedtråden. Bruk det til å finne kilden til en dårlig INP-poengsum.
• Bildekomprimeringsverktøy lar deg optimalisere bilder direkte i nettleseren, noe som er raskere og mer privat enn å laste dem opp til en tredjepartstjeneste. Bildebehandling på klientsiden er en personverngevinst fordi bildene dine aldri forlater maskinen din.

Lighthouse er utgangspunktet. Disse verktøyene hjelper deg å fullføre jobben.

Viktigste punkter

• Lighthouse-poengsummen din er en laboratorie-benchmark, ikke et mål på brukeropplevelse i den virkelige verden. Sammenlign den med feltdata fra CrUX før du får panikk.
• Fokuser først på Core Web Vitals (LCP, CLS, INP). Dette er målingene som korrelerer med brukerfrustrasjon og SEO-effekt.
• Prioriter Opportunities etter estimert tidsbesparelse. Ignorer Diagnostics som ikke samsvarer med de faktiske ytelsesproblemene dine.
• Noen revisjoner – som passive lyttere eller neste generasjons bildeformater – er mikrooptimaliseringer. Rett de store tingene først.
• Kjør Lighthouse tre ganger og ta gjennomsnittet av resultatene. Ytelse varierer, og én enkelt kjøring kan være misvisende.

FAQ

Q: Hvorfor endrer Lighthouse-poengsummen min seg hver gang jeg kjører den?
A: Lighthouse måler ytelse under variable forhold – nettverkshastighet, CPU-belastning og nettleserheuristikk påvirker alle resultatet. Kjør det tre ganger i inkognitomodus og ta gjennomsnittet av poengsummene for et mer stabilt utgangspunkt.

Q: Bør jeg optimalisere for mobil eller desktop først?
A: Mobil. Lighthouse bruker som standard en mobilsimulering fordi mesteparten av nettrafikken er mobil, og mobile enheter er tregere. Hvis mobilpoengsummen din er god, vil desktop-poengsummen vanligvis også være fin.

Q: Lighthouse-poengsummen min er 95, men nettstedet føles fortsatt tregt. Hva er galt?
A: Lighthouse måler sidelasting, ikke interaktivitet etter lasting. Sjekk INP-poengsummen din og bruk Chrome DevTools Performance panel til å profilere hva som skjer når brukere klikker eller ruller. Du kan ha et JavaScript-problem som Lighthouse ikke fanger opp.

Q: Trenger jeg en perfekt poengsum på 100?
A: Nei. En poengsum på 90+ er utmerket. Å jage 100 betyr ofte å optimalisere ting som ikke betyr noe for brukerne. Fokuser på reelle målinger – LCP, CLS, INP – og ignorer poengsummen.

Q: Kan jeg stole på Lighthouse hvis jeg bruker mange tredjepartsskript?
A: Lighthouse vil flagge tredjepartsskript som et problem, men det kan ikke alltid skille mellom nødvendige og unødvendige. Bruk revisjonene "Avoid enormous network payloads" og "Reduce JavaScript execution time" til å identifisere de verste synderne, og avgjør deretter om de er verdt å beholde.

Kilder

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org