# Lighthouse ## Hva det er Lighthouse, ofte kalt Google Lighthouse, er et program med åpen kildekode fra Chrome-teamet som laster én enkelt nettside under kontrollerte forhold, registrerer hva nettleseren gjorde, og gir resultatet en poengsum av 100 i fire kategorier: ytelse, tilgjengelighet, beste praksis og SEO. Det virker på enhver side det kan nå, offentlig eller bak en innlogging, og hver sjekk i rapporten lenker til et kort dokument som forklarer hvorfor sjekken finnes, og hvordan du består den. Den samme motoren kjører fire steder: - i Chrome DevTools, fra Lighthouse-panelet; - på kommandolinjen, som `lighthouse ` etter en global installasjon med npm; - som en Node-modul, inne i et skript du skriver selv; - bak PageSpeed Insights, en tjeneste fra Google som kjører det på Googles egne maskiner. Poengsummen for ytelse kommer bare fra metrikker som måles under innlastingen: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time og Cumulative Layout Shift. Hver metrikk plasseres på en kurve tegnet ut fra ekte nettsteder i HTTP Archive, og poengsummen for kategorien er et vektet gjennomsnitt av de fem. I Lighthouse 10 er vektene 30 % for Total Blocking Time, 25 % hver for Largest Contentful Paint og Cumulative Layout Shift og 10 % hver for de to andre. Vektene har endret seg mellom versjonene, fordi teamet fortsetter å undersøke hva som påvirker mest hvor rask en side føles. Kurven har to faste punkter. En verdi som ligger på arkivets 25. persentil, gir 50 poeng, og en som ligger på 8. persentil, gir 90. Lavere er bedre for hver eneste av disse metrikkene, så en side som får 50 på én av dem, ligger allerede foran tre fjerdedeler av de målte nettstedene; 50 er ikke gjennomsnittet. Nær toppen flater kurven ut: å gå fra 99 til 100 krever omtrent like mye forbedring som å gå fra 90 til 94. De tre andre kategoriene får poengene sine fra revisjoner i stedet. I kategorien for tilgjengelighet, den delen av universell utforming en maskin kan sjekke, består eller feiler hver revisjon uten uttelling for halvveis bestått. Hver av dem vektes etter hvor hardt regelmotoren axe vurderer at en feil rammer brukerne, og sjekkene som krever et menneske, holdes utenfor poengsummen og listes opp for manuell gjennomgang. ## Hvorfor det er viktig Avgjørelsen Lighthouse hjelper med, er om en endring gjorde en side tregere, vanskeligere å bruke eller vanskeligere å finne, og om det bør stoppe den fra å bli utgitt. Svaret kommer i en form en maskin kan handle på: et tall, de samme revisjonene hver gang og en rapport et skript kan lese. Det gjør Lighthouse billig nok til å kjøres ved hver endring i stedet for én gang før en lansering. Tallet er en laboratoriemåling: én enhetsprofil, ett simulert nettverk, én innlasting. PageSpeed Insights viser forskjellen ved å sette to slags data ved siden av hverandre. Laboratoriedelen er en kjøring av Lighthouse. Feltdelen kommer fra Chrome UX Report: hva ekte Chrome-brukere opplevde de siste 28 dagene, oppgitt ved 75. persentil, slik at tallet beskriver de fleste besøkende og ikke de heldigste. En side med for få egne besøk vises med tall for hele opprinnelsen sin, det engelske origin. Dokumentasjonen sier at du skal regne med at de to delene viser forskjellige tall. Den delingen avgjør hva hver av dem er til. Feltdata sier om brukerne har et problem, men de kommer uker etter en endring og sier ingenting om en gren som ikke er utgitt. Laboratoriedata kan samles inn før utgivelsen og så ofte det trengs, og det gjør dem til en vakt, men de beskriver ett simulert besøk. Den andre begrensningen er støy. Veiledningen for poengberegning foreslår å lese ytelse som en fordeling av poengsummer og ikke som ett tall, og lister opp årsaker som ligger utenfor siden: A/B-tester og annonser som roterer, endringer i rutingen på internett, en rask stasjonær maskin mot en treg bærbar, nettlesertillegg og antivirusprogramvare. En terskel som sjekkes mot én kjøring, vil feile tilfeldig. Prosjektets veiledning om variasjon setter et tall på botemiddelet: medianen av fem kjøringer er dobbelt så stabil som én enkelt kjøring. Lighthouse CI gjør dette til en regel. Det kjører Lighthouse flere ganger per adresse, tre som standard, slår sammen kjøringene og sjekker resultatet mot påstander, assertions, for en hel kategori eller én enkelt revisjon. En påstand på `warn` melder bare fra; en på `error` får byggingen til å feile og blir dermed en kvalitetsport. Terskelen er en minste poengsum, en høyeste verdi for en metrikk eller et høyeste antall elementer som bryter regelen: ```json { "ci": { "collect": { "numberOfRuns": 5 }, "assert": { "assertions": { "categories:accessibility": ["error", { "minScore": 1 }], "largest-contentful-paint": [ "error", { "maxNumericValue": 2500, "aggregationMethod": "median" } ] } } } } ``` ## Slik ser det ut i praksis Nettstedets [kolofon](/nb/credits/) lister Lighthouse blant verktøyene nettstedet kjører mot seg selv, på maskinen det skrives på, og gir det én jobb: det holder ytelsesbudsjettene. Et budsjett er en grense som er avtalt på forhånd, slik at en side som blir tregere, feiler en sjekk i stedet for å starte en diskusjon om hvorvidt noen hundre millisekunder betyr noe. Et senere avsnitt på den samme siden lenker til PageSpeed Insights blant sjekkene leserne kan kjøre selv, og sier at det kjører Lighthouse fra Googles maskiner i stedet for nettstedets egne, med data fra virkelig bruk der nok folk har vært innom. Siden holder de to adskilt med vilje. Det første avsnittet er nettstedet som retter sine egne prøver; det andre gir de samme spørsmålene til verktøy som ikke er nettstedets egne, og som ikke tar nettstedet på ordet for noe. Vanen som gjør et budsjett verdt å holde, viser seg også i arbeid her som ikke har noe med en poengsum å gjøre. Beretningen om hvordan [stilarkpakken ble kuttet fra 87 KB til 31](/nb/portfolio/cut-the-stylesheet-bundle-from-87kb-to-31kb-139/) åpner metoden sin med «Måling først». To tredjedeler av det største stilarket viste seg å være én base64-kodet font; en tredje fontvekt ble forhåndslastet først da feltdata viste at den lukket den lengste kritiske kjeden; og et moderne bildeformat for merkevaresymbolet ble målt og avvist, fordi filen ble større. Hver beslutning der har en måling knyttet til seg, også den som gikk den andre veien. Forslagene fra Lighthouse fortjener den samme behandlingen: hvert av dem er en hypotese til en måling viser at det hjalp. ## Hvor det går galt De fleste feil med Lighthouse kommer av at tallet leses som mer enn det er. **Én kjøring leses som sannheten.** Én rapport viser 94, den neste 87, og noen jakter på en regresjon som aldri skjedde. Sammenlign medianer av flere kjøringer, og velg sammenslåingen i Lighthouse CI med vilje: en påstand skrevet uten innstillinger bruker den verdien som har størst sjanse for å bestå på tvers av alle kjøringene, så en regresjon slipper gjennom så lenge én kjøring unngår den. **Kjøringene samles inn side om side.** Å revidere ti adresser samtidig på én maskin får dem til å konkurrere om prosessor, minne og nettverk, og veiledningen om variasjon sier rett ut at det ikke skal gjøres. Kjør dem etter tur, eller fordelt på flere maskiner; for Lighthouse slår mange små maskiner én stor. **Laboratorietallet leses som det besøkende får.** En 98 på en utviklers bærbare sier at siden kan være rask; bare feltdata sier om den var det. Les feltdelen i PageSpeed Insights, og regn med at en side med få besøk viser tallene for opprinnelsen sin. **Forslagene behandles som poengsummen.** Opportunities og Diagnostics, mulighetene og diagnosene i rapporten, teller ikke med i poengsummen for ytelse; de flytter den bare gjennom metrikkene de forbedrer. Velg det forslaget som bør flytte en metrikk som betyr noe for akkurat denne siden, gjør endringen, og mål på nytt. **En perfekt poengsum blir målet.** Veiledningen for poengberegning kaller 100 svært krevende og sier at det ikke er forventet. Når en side først er i det grønne feltet, koster de siste poengene mer enn de gir tilbake. **Full poengsum for tilgjengelighet leses som en universelt utformet side.** 100 der betyr at de automatiserte revisjonene besto. De manuelle sjekkene står ved siden av poengsummen og telles aldri med, så en side kan få 100 og likevel være umulig å bruke med tastatur. ## Les mer - [Introduction to Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) — måtene å kjøre det på, kategoriene det rapporterer, og hvor dokumentasjonen for hver revisjon ligger. - [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) — vektene for metrikkene per versjon, kurvene bak poengsummen og fargefeltene. - [Lighthouse accessibility score](https://developer.chrome.com/docs/lighthouse/accessibility/scoring) — hvordan revisjonene vektes, og hvorfor manuelle sjekker holdes utenfor poengsummen. - [Score Variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) — kildene til støy, hva som demper hver av dem, og argumentet for å kjøre flere ganger. - [About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) — laboratoriedata mot feltdata, 75. persentil og vurderingen av Core Web Vitals. - [Lighthouse CI configuration](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md) — innsamling av flere kjøringer, skriving av påstander og valg av hvordan kjøringene slås sammen.