Så läser du en Lighthouse-rapport utan att få panik

Första regeln: din poäng är inte din webbplats

Öppna en Lighthouse-rapport för första gången och du möts av en vägg av siffror, färgkodade rutor och varningar om saker du aldrig har hört talas om. Den naturliga reaktionen är panik. Poängen är röd. Sjutton granskningar har misslyckats. Visst måste webbplatsen vara trasig?

Förmodligen inte. Lighthouse är ett diagnostiskt verktyg, inte ett betyg. Poängen är ett syntetiskt benchmark som körs under labbförhållanden — ofta på en begränsad anslutning, som simulerar en mellanklassmobil från 2017. Den visar hur din webbplats presterar i just det scenariot, inte hur verkliga användare upplever den ute i verkligheten.

Det här spelar roll eftersom de flesta team fixerar sig vid poängen och missar sammanhanget. En poäng på 65 kan vara helt rimlig för en komplex webbapp med realtidsdata. En poäng på 95 kan fortfarande ge en dålig upplevelse om fel saker har optimerats. Poängen är en startpunkt för undersökning, inte ett framgångsmått.

Vad du ska läsa först: Core Web Vitals

Hoppa över den övergripande prestandapoängen. Rulla ned till avsnittet Metrics och titta på tre siffror: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) och Interaction to Next Paint (INP). Det här är Core Web Vitals, och de är de enda prestandamått som Google använder som rankingsignal.

• LCP mäter hur lång tid det tar för det största synliga elementet att renderas. Mål: under 2,5 sekunder. Om du ligger över 4 sekunder väntar användarna för länge på att se meningsfullt innehåll.
• CLS mäter visuell stabilitet — hur mycket sidan hoppar runt medan den laddas. Mål: under 0,1. Om du ligger över 0,25 klickar användare av misstag på fel sak eftersom knappar flyttar sig.
• INP mäter responsivitet — hur snabbt sidan reagerar på klick, tryck och tangentnedslag. Mål: under 200ms. Om du ligger över 500ms känns webbplatsen trög.

Dessa tre mått korrelerar med faktisk användarfrustration. Åtgärda dem innan du oroar dig för något annat.

Opportunities kontra Diagnostics: förstå skillnaden

Lighthouse delar upp sina fynd i två kategorier: Opportunities och Diagnostics. Opportunities rangordnas efter uppskattad tidsbesparing. Diagnostics är ytterligare sammanhang — saker som kan vara problem, eller kanske inte.

Börja med Opportunities. Om Lighthouse säger att "Eliminate render-blocking resources" kan spara 1,2 sekunder är det en konkret vinst. Om det säger att "Reduce unused JavaScript" kan spara 0,1 sekunder är det troligen inte värt en omarbetning.

Diagnostics är knepigare. "Avoid an excessive DOM size" låter illa, men om din CLS är bra och din INP är snabb kanske en stor DOM inte skadar någon. Diagnostics är ledtrådar, inte krav. Undersök dem som ligger i linje med dina faktiska mätvärden.

Granskningarna du oftast kan ignorera

Vissa Lighthouse-varningar är kvarlevor eller onödigt aggressiva. Här är de som orsakar mest onödig panik:

• "Does not use passive listeners to improve scrolling performance" — Det här är en mikrooptimering som sällan gör någon märkbar skillnad. Om du inte har belägg för hackig scrollning kan du hoppa över den.
• "Image elements do not have explicit width and height" — Det här spelar roll för CLS, men bara om bilder orsakar layoutförskjutningar. Om din CLS redan är bra ska du inte bygga om bara för granskningens skull.
• "Serve images in next-gen formats" — Ja, WebP och AVIF är mindre. Men om dina bilder redan är optimerade och din LCP är snabb är detta något trevligt att ha, inte en kris.
• "Avoid enormous network payloads" — Lighthouse flaggar allt över 1,6 MB. Men en sida på 2 MB som laddar snabbt är bättre än en sida på 500 KB som blockerar rendering. Fokusera på hur byten levereras, inte bara totalsumman.

Vad du gör när allt är rött

Om din Lighthouse-poäng är under 50 och de flesta granskningar misslyckas handlar det förmodligen om en av tre grundorsaker:

1. Ooptimerade typsnitt. Webbtypsnitt är fortfarande den enklaste prestandavinsten på de flesta webbplatser. Kontrollera om du laddar sex typsnittsvikter när du bara använder två, eller skickar WOFF-filer i stället för WOFF2.
2. Renderingsblockerande CSS och JavaScript. Om din First Contentful Paint (FCP) är över 3 sekunder blockerar något webbläsaren från att måla sidan. Leta efter stora CSS-filer eller synkrona skript i <head>.
3. För stora bilder. Om ditt LCP-element är en bild och den är 4 MB är det problemet. Komprimera den, lazy-loada bilder nedanför vikningen och använd responsiv bildsyntax.

Åtgärda en av dessa och kör Lighthouse igen. Ofta ser du ett hopp på 20–30 poäng. Ta sedan nästa.

Labbdata kontra fältdata: verklighetskontrollen

Lighthouse körs i ett labb. Det simulerar en långsam anslutning och en långsam enhet, men kan inte simulera verkligt användarbeteende — hur människor scrollar, vad de klickar på eller om de sitter på instabilt Wi‑Fi.

För en verklighetskontroll kan du jämföra dina Lighthouse-resultat med fältdata från Chrome User Experience Report (CrUX). CrUX visar hur riktiga Chrome-användare har upplevt din webbplats under de senaste 28 dagarna. Om Lighthouse säger att din LCP är 4 sekunder men CrUX visar 2 sekunder, lita på CrUX. Om båda är dåliga har du ett verkligt problem.

Du hittar CrUX-data i PageSpeed Insights (webbversionen av Lighthouse) eller i Google Search Console under "Core Web Vitals." Om det finns en skillnad, undersök varför. Kanske sitter dina verkliga användare på snabbare nätverk. Kanske testar Lighthouse en ooptimerad utvecklingsbuild.

När du ska köra Lighthouse igen

Lighthouse är brusigt. Kör det tre gånger i rad och du får tre olika poäng, även på samma sida. Det beror på att prestanda varierar — bakgrundsprocesser, nätverksjitter och webbläsarheuristik påverkar alla resultatet.

För att få en stabil baslinje, kör Lighthouse i inkognitoläge med alla tillägg inaktiverade, eller använd CLI med flaggan --preset=desktop för mer konsekventa resultat. Kör det tre gånger och ta medelvärdet av poängen. Om du ser stora svängningar (mer än 10 poäng) är något annat fel — kanske är servern långsam, eller så laddar sidan olika resurser varje gång.

Kör Lighthouse igen efter varje större förändring. Lanserat en ny typsnittsstrategi? Kontrollera LCP. Lazy-loadat bilder? Kontrollera CLS. Lagt till ett tredjepartsskript? Kontrollera INP. Prestanda är inte en engångsåtgärd; det är en budget du försvarar.

Verktygen som hjälper dig att agera på Lighthouse-fynd

Lighthouse berättar vad som är långsamt. Det berättar inte alltid hur du ska åtgärda det. För det behöver du ytterligare verktyg:

• WebPageTest ger dig en filmremsa över hur sidan laddas, bildruta för bildruta. Oumbärligt för att diagnostisera LCP- och CLS-problem.
• Chrome DevTools Performance panel visar exakt vilken JavaScript som blockerar huvudtråden. Använd den för att hitta källan till en dålig INP-poäng.
• Image compressor tools låter dig optimera bilder direkt i webbläsaren, vilket är snabbare och mer privat än att ladda upp till en tredjepartstjänst. Bildbehandling på klientsidan är en vinst för integriteten eftersom dina bilder aldrig lämnar din dator.

Lighthouse är startpunkten. De här verktygen hjälper dig att slutföra jobbet.

Viktiga slutsatser

• Din Lighthouse-poäng är ett labbbenchmark, inte ett mått på användarupplevelse i verkligheten. Jämför den med fältdata från CrUX innan du får panik.
• Fokusera först på Core Web Vitals (LCP, CLS, INP). Det här är måtten som korrelerar med användarfrustration och SEO-påverkan.
• Prioritera Opportunities efter uppskattad tidsbesparing. Ignorera Diagnostics som inte stämmer överens med dina faktiska prestandaproblem.
• Vissa granskningar — som passive listeners eller next-gen image formats — är mikrooptimeringar. Åtgärda de stora sakerna först.
• Kör Lighthouse tre gånger och ta medelvärdet av resultaten. Prestanda varierar, och en enda körning kan vara missvisande.

FAQ

Q: Varför ändras min Lighthouse-poäng varje gång jag kör det?
A: Lighthouse mäter prestanda under varierande förhållanden — nätverkshastighet, CPU-belastning och webbläsarheuristik påverkar alla resultatet. Kör det tre gånger i inkognitoläge och ta medelvärdet av poängen för en stabilare baslinje.

Q: Bör jag optimera för mobil eller desktop först?
A: Mobil. Lighthouse utgår från en mobilsimulering eftersom den mesta webbtrafiken är mobil, och mobila enheter är långsammare. Om din mobilpoäng är bra brukar din desktoppoäng också vara det.

Q: Min Lighthouse-poäng är 95, men min webbplats känns fortfarande långsam. Vad är fel?
A: Lighthouse mäter sidladdning, inte interaktivitet efter laddning. Kontrollera din INP-poäng och använd Chrome DevTools Performance panel för att profilera vad som händer när användare klickar eller scrollar. Du kan ha ett JavaScript-problem som Lighthouse inte fångar.

Q: Behöver jag en perfekt poäng på 100?
A: Nej. En poäng på 90+ är utmärkt. Att jaga 100 innebär ofta att optimera saker som inte spelar någon roll för användarna. Fokusera på verkliga mätvärden — LCP, CLS, INP — och ignorera poängen.

Q: Kan jag lita på Lighthouse om jag använder många tredjepartsskript?
A: Lighthouse kommer att flagga tredjepartsskript som ett problem, men det kan inte alltid skilja mellan nödvändiga och onödiga. Använd granskningarna "Avoid enormous network payloads" och "Reduce JavaScript execution time" för att identifiera de värsta syndarna, och avgör sedan om de är värda att behålla.

Källor

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