Sådan læser du en Lighthouse-rapport uden panik

Første regel: din score er ikke dit site

Åbn en Lighthouse-rapport for første gang, og du bliver mødt af en mur af tal, farvekodede bokse og advarsler om ting, du aldrig har hørt om. Den naturlige reaktion er panik. Scoren er rød. Sytten audits er fejlet. Sitet må da være i stykker?

Det er det sandsynligvis ikke. Lighthouse er et diagnostisk værktøj, ikke et karakterblad. Scoren er en syntetisk benchmark, der køres under laboratorieforhold — ofte på en droslet forbindelse, der simulerer en mellemklassetelefon fra 2017. Den fortæller dig, hvordan dit site klarer sig i netop det scenarie, ikke hvordan rigtige brugere oplever det i praksis.

Det er vigtigt, fordi de fleste teams stirrer sig blinde på scoren og overser konteksten. En score på 65 kan være helt acceptabel for en kompleks webapp med realtidsdata. En score på 95 kan stadig give en dårlig oplevelse, hvis de forkerte ting er optimeret. Scoren er et udgangspunkt for undersøgelse, ikke et succesmål.

Hvad du skal læse først: Core Web Vitals

Spring den samlede performance-score over. Rul ned til sektionen Metrics, og se på tre tal: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) og Interaction to Next Paint (INP). Det er Core Web Vitals, og det er de eneste performance-metrics, Google bruger som ranking-signal.

• LCP måler, hvor lang tid det tager, før det største synlige element renderes. Mål: under 2,5 sekunder. Hvis du ligger over 4 sekunder, venter brugerne for længe på at se meningsfuldt indhold.
• CLS måler visuel stabilitet — hvor meget siden hopper rundt, mens den indlæses. Mål: under 0,1. Hvis du ligger over 0,25, kommer brugere til at klikke på det forkerte, fordi knapper flytter sig.
• INP måler responsivitet — hvor hurtigt siden reagerer på klik, tryk og tastetryk. Mål: under 200 ms. Hvis du ligger over 500 ms, føles sitet trægt.

Disse tre metrics hænger sammen med reel brugerfrustration. Ret dem, før du bekymrer dig om noget andet.

Opportunities vs. Diagnostics: kend forskellen

Lighthouse deler sine fund op i to kategorier: Opportunities og Diagnostics. Opportunities rangeres efter estimeret tidsbesparelse. Diagnostics er ekstra kontekst — ting, der kan være problemer, eller måske ikke er det.

Start med Opportunities. Hvis Lighthouse siger, at "Eliminate render-blocking resources" kan spare 1,2 sekunder, er det en konkret gevinst. Hvis den siger, at "Reduce unused JavaScript" kan spare 0,1 sekunder, er det sandsynligvis ikke en refaktorering værd.

Diagnostics er mere vanskelige. "Avoid an excessive DOM size" lyder dårligt, men hvis din CLS er fin, og din INP er hurtig, skader en stor DOM måske ikke nogen. Diagnostics er ledetråde, ikke påbud. Undersøg dem, der passer med dine faktiske metrics.

De audits, du som regel kan ignorere

Nogle Lighthouse-advarsler er forældede eller alt for aggressive. Her er dem, der skaber mest unødvendig panik:

• "Does not use passive listeners to improve scrolling performance" — Dette er en mikrooptimering, der sjældent flytter noget mærkbart. Medmindre du har evidens for hakkende scrolling, så spring den over.
• "Image elements do not have explicit width and height" — Det betyder noget for CLS, men kun hvis billeder forårsager layout shifts. Hvis din CLS allerede er god, så lad være med at refaktorere kun for auditens skyld.
• "Serve images in next-gen formats" — Ja, WebP og AVIF er mindre. Men hvis dine billeder allerede er optimeret, og din LCP er hurtig, er det rart at have — ikke en krise.
• "Avoid enormous network payloads" — Lighthouse markerer alt over 1,6 MB. Men en side på 2 MB, der indlæses hurtigt, er bedre end en side på 500 KB, der blokerer rendering. Fokusér på hvordan bytes leveres, ikke kun den samlede mængde.

Hvad du gør, når alt er rødt

Hvis din Lighthouse-score er under 50, og de fleste audits fejler, har du sandsynligvis at gøre med en af tre grundårsager:

1. Uoptimerede fonte. Web fonts er stadig den nemmeste performance-gevinst på de fleste sites. Tjek, om du indlæser seks fontvægte, når du kun bruger to, eller sender WOFF-filer i stedet for WOFF2.
2. Renderingsblokerende CSS og JavaScript. Hvis din First Contentful Paint (FCP) er over 3 sekunder, blokerer noget browseren fra at male siden. Kig efter store CSS-filer eller synkrone scripts i <head>.
3. For store billeder. Hvis dit LCP-element er et billede, og det er 4 MB, er det dit problem. Komprimér det, lazy-load billeder under folden, og brug responsiv billedsyntaks.

Ret én af disse ting, og kør Lighthouse igen. Du vil ofte se et hop på 20-30 point. Tag derefter fat på den næste.

Labdata vs. feltdata: realitetstjekket

Lighthouse kører i et laboratorie. Det simulerer en langsom forbindelse og en langsom enhed, men det kan ikke simulere reel brugeradfærd — hvordan folk scroller, hvad de klikker på, eller om de er på ustabilt Wi-Fi.

Som realitetstjek bør du sammenligne dine Lighthouse-resultater med feltdata fra Chrome User Experience Report (CrUX). CrUX viser, hvordan rigtige Chrome-brugere har oplevet dit site over de seneste 28 dage. Hvis Lighthouse siger, at din LCP er 4 sekunder, men CrUX viser 2 sekunder, så stol på CrUX. Hvis de begge er dårlige, har du et reelt problem.

Du kan finde CrUX-data i PageSpeed Insights (webversionen af Lighthouse) eller i Google Search Console under "Core Web Vitals." Hvis der er uoverensstemmelse, så undersøg hvorfor. Måske er dine rigtige brugere på hurtigere netværk. Måske tester Lighthouse et uoptimeret dev-build.

Hvornår du skal køre Lighthouse igen

Lighthouse er støjende. Kør det tre gange i træk, og du får tre forskellige scorer, selv på den samme side. Det skyldes, at performance varierer — baggrundsprocesser, netværksjitter og browserheuristikker påvirker alle resultatet.

For at få en stabil baseline skal du køre Lighthouse i inkognitotilstand med alle extensions deaktiveret eller bruge CLI med flaget --preset=desktop for mere konsistente resultater. Kør det tre gange, og tag gennemsnittet af scorerne. Hvis du ser voldsomme udsving (mere end 10 point), er der noget andet galt — måske er serveren langsom, eller siden indlæser forskellige ressourcer hver gang.

Kør Lighthouse igen efter hver væsentlig ændring. Udruller du en ny fontstrategi? Tjek LCP. Lazy-loader du billeder? Tjek CLS. Tilføjer du et tredjepartsscript? Tjek INP. Performance er ikke en engangsrettelse; det er et budget, du forsvarer.

Værktøjerne, der hjælper dig med at handle på Lighthouse-fund

Lighthouse fortæller dig, hvad der er langsomt. Det fortæller dig ikke altid, hvordan du retter det. Til det har du brug for flere værktøjer:

• WebPageTest giver dig en filmstrip-visning af, hvordan siden indlæses, frame for frame. Uundværlig til at diagnosticere LCP- og CLS-problemer.
• Chrome DevTools Performance panel viser dig præcis, hvilken JavaScript der blokerer main thread. Brug det til at finde årsagen til en dårlig INP-score.
• Billedkomprimeringsværktøjer lader dig optimere billeder direkte i browseren, hvilket er hurtigere og mere privat end at uploade til en tredjepartstjeneste. Client-side image processing er en gevinst for privatliv, fordi dine billeder aldrig forlader din maskine.

Lighthouse er udgangspunktet. Disse værktøjer hjælper dig med at gøre arbejdet færdigt.

Vigtigste pointer

• Din Lighthouse-score er en laboratoriebenchmark, ikke et mål for brugeroplevelsen i den virkelige verden. Sammenlign den med feltdata fra CrUX, før du går i panik.
• Fokusér først på Core Web Vitals (LCP, CLS, INP). Det er de metrics, der hænger sammen med brugerfrustration og SEO-effekt.
• Prioritér Opportunities efter estimeret tidsbesparelse. Ignorér Diagnostics, der ikke stemmer overens med dine faktiske performance-problemer.
• Nogle audits — som passive listeners eller next-gen billedformater — er mikrooptimeringer. Ret de store ting først.
• Kør Lighthouse tre gange, og tag gennemsnittet af resultaterne. Performance varierer, og en enkelt kørsel kan være misvisende.

FAQ

Q: Hvorfor ændrer min Lighthouse-score sig, hver gang jeg kører den?
A: Lighthouse måler performance under variable forhold — netværkshastighed, CPU-belastning og browserheuristikker påvirker alle resultatet. Kør det tre gange i inkognitotilstand, og tag gennemsnittet af scorerne for en mere stabil baseline.

Q: Skal jeg optimere til mobil eller desktop først?
A: Mobil. Lighthouse bruger som standard en mobilsimulering, fordi det meste webtrafik er mobil, og mobile enheder er langsommere. Hvis din mobilscore er god, vil din desktopscore som regel også være fin.

Q: Min Lighthouse-score er 95, men mit site føles stadig langsomt. Hvad er galt?
A: Lighthouse måler sideindlæsning, ikke interaktivitet efter indlæsning. Tjek din INP-score, og brug Chrome DevTools Performance panel til at profilere, hvad der sker, når brugere klikker eller scroller. Du kan have et JavaScript-problem, som Lighthouse ikke fanger.

Q: Har jeg brug for en perfekt score på 100?
A: Nej. En score på 90+ er fremragende. At jagte 100 betyder ofte, at man optimerer ting, der ikke betyder noget for brugerne. Fokusér på rigtige metrics — LCP, CLS, INP — og ignorér scoren.

Q: Kan jeg stole på Lighthouse, hvis jeg bruger mange tredjepartsscripts?
A: Lighthouse vil markere tredjepartsscripts som et problem, men det kan ikke altid skelne mellem nødvendige og unødvendige scripts. Brug audits som "Avoid enormous network payloads" og "Reduce JavaScript execution time" til at identificere de værste syndere, og beslut derefter, om de er værd at beholde.

Kilder

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