# Lighthouse ## Vad det är Lighthouse, ofta kallat Google Lighthouse, är ett program med öppen källkod från Chrome-teamet som laddar en enda webbsida under styrda förhållanden, registrerar vad webbläsaren gjorde och sätter betyg på resultatet på en skala till 100 i fyra kategorier: prestanda, tillgänglighet, bästa praxis och SEO. Det fungerar på varje sida som det kan nå, offentlig eller bakom en inloggning, och varje kontroll i rapporten länkar till ett kort dokument som förklarar varför kontrollen finns och hur sidan klarar den. Samma motor körs på fyra ställen: - i Chrome DevTools, från panelen Lighthouse; - på kommandoraden, som `lighthouse ` efter en global installation med npm; - som en Node-modul, inuti ett eget skript; - bakom PageSpeed Insights, en tjänst från Google som kör det på Googles maskiner. Prestandapoängen bygger enbart på mätvärden som registreras under laddningen: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time och Cumulative Layout Shift. Varje mätvärde placeras på en kurva som har ritats utifrån verkliga webbplatser i HTTP Archive, och kategorins poäng är ett viktat medelvärde av de fem. I Lighthouse 10 är vikterna 30 % för Total Blocking Time, 25 % vardera för Largest Contentful Paint och Cumulative Layout Shift och 10 % vardera för de två andra. Vikterna har ändrats mellan versionerna, eftersom teamet fortsätter att undersöka vad som mest påverkar hur snabb en sida känns. Kurvan har två fasta punkter. Ett mätvärde vid 25:e percentilen i arkivet får 50 poäng, och ett vid 8:e percentilen får 90. Lägre är bättre för vart och ett av de här mätvärdena, så en sida som får 50 på ett av dem ligger redan före tre fjärdedelar av de webbplatser som har mätts; 50 är inte medel. Nära toppen planar kurvan ut: att gå från 99 till 100 kräver ungefär lika stor förbättring som att gå från 90 till 94. De tre andra kategorierna får i stället sina poäng från granskningar. Inom tillgänglighet blir varje granskning godkänd eller underkänd, utan delpoäng för ett halvt godkännande, varje granskning viktas efter regelmotorn axes bedömning av hur hårt ett fel drabbar användarna, och de kontroller som kräver en människa hålls utanför poängen och listas för manuell granskning. ## Varför det spelar roll Beslutet som Lighthouse tjänar är om en ändring gjorde en sida långsammare, svårare att använda eller svårare att hitta, och om det i så fall ska stoppa leveransen. Svaret kommer i en form som en maskin kan agera på: ett tal, samma granskningar varje gång och en rapport som ett skript kan tolka. Det gör verktyget billigt nog att köra vid varje ändring och inte bara en gång före en lansering. Talet är en laboratoriemätning: en enhetsprofil, ett simulerat nätverk, en laddning. PageSpeed Insights visar skillnaden genom att ställa två sorters data bredvid varandra. Avsnittet med labbdata är en körning av Lighthouse. Avsnittet med fältdata kommer från Chrome UX Report: vad verkliga Chrome-användare upplevde under de senaste 28 dagarna, angivet vid 75:e percentilen så att siffran beskriver de flesta besökare och inte de som hade mest tur. En sida med för få egna besök visas med siffror för hela sitt ursprung. Dokumentationen säger att de två avsnitten kan väntas skilja sig åt. Den uppdelningen avgör vad var och en är till för. Fältdata säger om användarna har ett problem, men de kommer veckor efter en ändring och säger ingenting om en gren som ännu inte har levererats. Labbdata kan samlas in före lanseringen och så ofta som det behövs, vilket gör dem till ett skydd, men de beskriver ett enda simulerat besök. Den andra begränsningen är brus. Poängguiden föreslår att prestanda läses som en fördelning av poäng och inte som ett enda tal, och räknar upp orsaker utanför sidan: A/B-tester och roterande annonser, ändringar i routningen på internet, en snabb stationär dator jämfört med en långsam bärbar, webbläsartillägg och antivirusprogram. En tröskel som kontrolleras mot en enda körning fallerar slumpmässigt. Projektets guide om variation sätter en siffra på botemedlet: medianen av fem körningar är dubbelt så stabil som en enda körning. Lighthouse CI gör det till en regel. Verktyget kör Lighthouse flera gånger per adress, tre gånger som standard, kombinerar körningarna och prövar resultatet mot påståenden (assertions) för en hel kategori eller en enskild granskning. Ett påstående på nivån `warn` rapporterar bara; ett på `error` får bygget att fallera. Tröskeln är ett minsta poängtal, ett högsta värde för ett mätvärde eller ett högsta antal element som bryter mot granskningen: ```json { "ci": { "collect": { "numberOfRuns": 5 }, "assert": { "assertions": { "categories:accessibility": ["error", { "minScore": 1 }], "largest-contentful-paint": [ "error", { "maxNumericValue": 2500, "aggregationMethod": "median" } ] } } } } ``` ## Så ser det ut i praktiken Webbplatsens [kolofon](/sv/credits/) räknar upp Lighthouse bland de verktyg som webbplatsen kör mot sig själv, på den maskin som den skrivs på, och ger det ett enda jobb: att hålla prestandabudgetarna. En budget är en gräns som har bestämts i förväg, så att en sida som blir långsammare fallerar i en kontroll i stället för att starta en diskussion om huruvida några hundra millisekunder spelar någon roll. Ett senare avsnitt på samma sida länkar till PageSpeed Insights bland de kontroller som läsaren kan köra själv, och säger att tjänsten kör Lighthouse från Googles maskiner i stället för webbplatsens, med verkliga data där tillräckligt många har besökt sidan. Sidan håller isär de två med avsikt. Det första avsnittet är webbplatsen som rättar sina egna prov; det andra lämnar samma frågor till verktyg som inte är webbplatsens egna och som inte tar något på dess ord. Vanan som gör en budget värd att hålla syns också i arbete här som inte har med något poängtal att göra. Redogörelsen för hur [stilmallspaketet krympte från 87 KB till 31](/sv/portfolio/cut-the-stylesheet-bundle-from-87kb-to-31kb-139/) inleder sin metod med ”Först mätning.” Två tredjedelar av den största stilmallen visade sig vara ett enda base64-kodat typsnitt; en tredje typsnittsvikt förladdades först när fältdata visade att den avslutade den längsta kritiska kedjan; och ett modernt bildformat för varumärkessymbolen mättes och valdes bort, eftersom det blev större. Varje beslut där har en mätning kopplad till sig, även det som gick åt andra hållet. Förslagen från Lighthouse behöver samma behandling: vart och ett är en hypotes tills en mätning visar att det hjälpte. ## Var det går fel De flesta misstag med Lighthouse kommer av att talet läses som mer än det är. **En enda körning tas för sanningen.** En rapport visar 94, nästa 87, och någon jagar en försämring som aldrig har inträffat. Jämför medianer av flera körningar, och välj medvetet hur Lighthouse CI kombinerar dem: ett påstående som skrivs utan alternativ tar det värde som har störst chans att godkännas bland alla körningar, så en försämring slinker igenom så länge en enda körning undgår den. **Körningarna samlas in parallellt.** Att granska tio adresser på en gång på samma maskin får dem att konkurrera om processor, minne och nätverk, och guiden om variation säger rakt ut att det inte ska göras. Kör dem i tur och ordning, eller på flera maskiner; för Lighthouse är fler små maskiner bättre än en stor. **Labbpoängen läses som det besökarna får.** En 98 på en utvecklares bärbara dator säger att sidan kan vara snabb; bara fältdata säger om den var det. Läs avsnittet med fältdata i PageSpeed Insights, och räkna med att en sida med få besök visar siffrorna för sitt ursprung. **Förslagen behandlas som poängen.** Opportunities och Diagnostics räknas inte in i prestandapoängen; de flyttar den bara genom de mätvärden som de förbättrar. Välj det förslag som borde flytta ett mätvärde som betyder något för just den här sidan, gör ändringen och mät igen. **Full pott blir målet.** Poängguiden kallar 100 extremt svårt och säger att det inte förväntas. När en sida väl ligger i det gröna bandet kostar de sista poängen mer än de ger tillbaka. **Full poäng i tillgänglighet tas för en tillgänglig sida.** En 100 där betyder att de automatiska granskningarna godkändes. De manuella kontrollerna listas bredvid poängen och räknas aldrig, så en sida kan få 100 och ändå vara omöjlig att använda med tangentbord. ## Läs mer - [Introduction to Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) — sätten att köra verktyget, kategorierna som det rapporterar och var dokumentationen för varje granskning finns. - [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) — mätvärdenas vikter per version, poängkurvorna och färgbanden. - [Lighthouse accessibility score](https://developer.chrome.com/docs/lighthouse/accessibility/scoring) — hur granskningarna viktas och varför manuella kontroller hålls utanför poängen. - [Score Variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) — källorna till brus, vad som minskar var och en av dem och skälen till att köra flera gånger. - [About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) — labbdata jämfört med fältdata, 75:e percentilen och bedömningen enligt Core Web Vitals. - [Lighthouse CI configuration](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md) — att samla in flera körningar, skriva påståenden och välja hur körningarna kombineras.