Lighthouse

Chromes egen måling af hastighed, markup og god praksis

Hvad det er

Lighthouse, ofte kaldt Google Lighthouse, er et open source-program fra Chrome-teamet, der indlæser én webside under kontrollerede forhold, registrerer, hvad browseren gjorde, og giver resultatet en score fra 0 til 100 i fire kategorier: ydelse, tilgængelighed, god skik og SEO. Det virker på enhver side, det kan nå, offentlig eller bag et login, og hvert tjek i rapporten linker til et kort dokument om, hvorfor tjekket findes, og hvordan man består det.

Samme motor kører fire steder:

  • i Chrome DevTools, fra Lighthouse-panelet;
  • på kommandolinjen, som lighthouse <url> efter en global installation med npm;
  • som Node-modul i et script, man selv skriver;
  • bag PageSpeed Insights, en tjeneste fra Google, der kører det på Googles maskiner.

Ydelsesscoren kommer kun fra målinger foretaget under indlæsningen: First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time og Cumulative Layout Shift. Hver måling placeres på en kurve tegnet ud fra rigtige websites i HTTP Archive, og kategoriens score er et vægtet gennemsnit af de fem. I Lighthouse 10 vejer Total Blocking Time 30 %, Largest Contentful Paint og Cumulative Layout Shift 25 % hver og de to andre 10 % hver. Vægtene har ændret sig mellem versioner, fordi teamet løbende undersøger, hvad der betyder mest for, hvor hurtig en side føles.

Kurven har to faste punkter. En måleværdi ved 25. percentil i arkivet giver 50, og en ved 8. percentil giver 90. Lavere er bedre for alle fem målinger, så en side, der scorer 50 på en af dem, ligger allerede foran tre fjerdedele af de målte sites; 50 er ikke gennemsnit. Øverst flader kurven ud: at gå fra 99 til 100 kræver omtrent lige så meget forbedring som at gå fra 90 til 94.

De tre andre kategorier scores i stedet ud fra audits. I tilgængelighed består eller dumper hver audit uden point for at bestå delvist, hver vægtes efter regelmotoren axes vurdering af, hvor hårdt en fejl rammer brugerne, og de tjek, der kræver et menneske, holdes uden for scoren og listes til manuel gennemgang.

Hvorfor det betyder noget

Den beslutning, Lighthouse tjener, er, om en ændring gjorde en side langsommere, sværere at bruge eller sværere at finde, og om det skal stoppe udgivelsen. Svaret kommer i en form, en maskine kan handle på: et tal, de samme audits hver gang og en rapport, et script kan læse. Det gør det billigt nok at køre ved hver ændring i stedet for én gang før en lancering.

Tallet er en laboratoriemåling: én enhedsprofil, ét simuleret netværk, én indlæsning. PageSpeed Insights viser forskellen ved at stille to slags data side om side. Laboratorieafsnittet er en Lighthouse-kørsel. Feltafsnittet kommer fra Chrome UX Report: hvad rigtige Chrome-brugere oplevede de seneste 28 dage, opgjort ved 75. percentil, så tallet beskriver de fleste besøgende og ikke de heldigste. En side med for få besøg af sine egne vises med tal for hele dens origin. Dokumentationen siger, at man skal regne med, at de to afsnit viser forskellige tal.

Den opdeling afgør, hvad hver af dem kan bruges til. Feltdata siger, om brugerne har et problem, men de kommer uger efter en ændring og siger intet om en gren, der ikke er udgivet. Laboratoriedata kan samles før udgivelsen og så tit, man vil, og det gør dem til et værn, men de beskriver ét simuleret besøg.

Den anden grænse er støj. Scoringsvejledningen foreslår at læse ydelse som en fordeling af scorer frem for ét tal og nævner årsager uden for selve siden: A/B-test og skiftende annoncer, ændringer i internettets routing, en hurtig stationær computer over for en langsom bærbar, browserudvidelser og antivirusprogrammer. En tærskel, der tjekkes mod én kørsel, fejler tilfældigt. Projektets vejledning om variation sætter tal på løsningen: medianen af fem kørsler er dobbelt så stabil som én kørsel.

Lighthouse CI gør det til en regel. Det kører Lighthouse flere gange pr. adresse, tre som standard, samler kørslerne og tjekker resultatet mod påstande, assertions, for en hel kategori eller én audit. En påstand på warn melder kun; en på error får buildet til at fejle. Tærsklen er en mindste score, en højeste værdi for en måling eller et højeste antal fund:

{
    "ci": {
        "collect": { "numberOfRuns": 5 },
        "assert": {
            "assertions": {
                "categories:accessibility": ["error", { "minScore": 1 }],
                "largest-contentful-paint": [
                    "error",
                    { "maxNumericValue": 2500, "aggregationMethod": "median" }
                ]
            }
        }
    }
}

Sådan ser det ud i praksis

Sitets kolofon nævner Lighthouse blandt de værktøjer, sitet kører mod sig selv på den maskine, det skrives på, og giver det én opgave: det holder performancebudgetterne. Et budget er en grænse, der er aftalt på forhånd, så en side, der bliver langsommere, dumper et tjek i stedet for at starte en diskussion om, hvorvidt et par hundrede millisekunder betyder noget.

Et senere afsnit på samme side linker til PageSpeed Insights blandt de tjek, læseren selv kan køre, og siger, at det kører Lighthouse fra Googles maskiner og ikke sitets egne, med data fra rigtige brugere, hvor der har været nok af dem. Siden holder de to adskilt med vilje. Det første afsnit er sitet, der retter sine egne opgaver; det andet giver de samme spørgsmål til værktøjer, der ikke er sitets egne og ikke tager dets ord for noget.

Den vane, der gør et budget værd at holde, viser sig også i arbejde her, som intet har med en score at gøre. Beretningen om, hvordan stylesheet-bundtet blev skåret fra 87 KB til 31 indleder sin fremgangsmåde med »Måling først.« To tredjedele af det største stylesheet viste sig at være én base64-kodet font; den tredje fontvægt kom først på listen over forudindlæsninger, da feltdata viste, at den lukkede den længste kritiske kæde; og et moderne billedformat til bomærket blev målt og fravalgt, fordi filen blev større. Hver beslutning dér har en måling knyttet til sig, også den, der gik den anden vej. Lighthouses forslag fortjener samme behandling: hvert af dem er en hypotese, indtil en måling viser, at det hjalp.

Hvor det går galt

De fleste fejl med Lighthouse kommer af at læse tallet som mere, end det er.

Én kørsel bliver læst som sandheden. Én rapport viser 94, den næste 87, og nogen jagter en regression, der aldrig skete. Sammenlign medianer af flere kørsler, og vælg sammenlægningen i Lighthouse CI med vilje: en påstand uden indstillinger tager den værdi på tværs af alle kørsler, der har størst chance for at bestå, så en regression slipper igennem, så længe én kørsel undgår den.

Kørsler bliver samlet side om side. Når ti adresser auditeres på én gang på én maskine, konkurrerer de om processor, hukommelse og netværk, og vejledningen om variation siger ligeud, at man ikke skal gøre det. Kør dem efter hinanden eller på flere maskiner; for Lighthouse er flere små maskiner bedre end én stor.

Laboratoriescoren bliver læst som det, de besøgende får. 98 på en udviklers bærbare siger, at siden kan være hurtig; kun feltdata siger, om den var det. Læs feltafsnittet i PageSpeed Insights, og regn med, at en side med få besøg viser tal for hele dens origin.

Forslagene bliver behandlet som scoren. Opportunities og Diagnostics tæller ikke med i ydelsesscoren; de flytter den kun gennem de målinger, de forbedrer. Vælg det forslag, der bør flytte en måling, som betyder noget for netop denne side, lav ændringen, og mål igen.

En perfekt score bliver målet. Scoringsvejledningen kalder 100 yderst svært at nå og siger, at det ikke forventes. Når en side først er i det grønne bånd, koster de sidste point mere, end de giver.

Fuld tilgængelighedsscore bliver læst som en tilgængelig side. 100 dér betyder, at de automatiske audits bestod. De manuelle tjek står ved siden af scoren og tælles aldrig med, så en side kan score 100 og stadig være umulig at bruge med et tastatur.

Læs mere

Ordliste