Speed vs. conversion.

Lighthouse-score er et gennemsnit af laboratoriemålinger på én maskine, i ét netværk, på én dag. Den siger noget om, hvor sund koden er, men den siger ikke, hvordan dine kunder oplever siden, og den siger slet ikke, hvad langsomhed koster. Det gør felttallene: TTFB, LCP og INP, målt på rigtige enheder, på rigtige netværk, i rigtige øjeblikke.

Forskellen er ikke akademisk. En side kan score 95 på en hurtig testmaskine og tage fire sekunder på en mobil i et 4G-netværk med tre faner åbne i baggrunden. Det er den mobil, der betaler din omsætning.

TTFB: serveren taler først

Time to First Byte er tiden fra kundens request til det første svar. Den indeholder DNS, TCP, TLS, serverens egen behandling og eventuel cache. En shop på dansk hosting kan have 120 ms her. Den samme shop på amerikansk shared hosting med uncached database-opslag kan have 900 ms, før browseren overhovedet er begyndt at bygge siden.

Kritisk sti: hvad browseren venter på, og hvad den ikke behøver

Hvert render-blokerende stylesheet og script udskød det øjeblik, kunden ser noget. Den kritiske sti skal indeholde det, der skal til for at vise skærmen, intet andet. Alt andet kan indlæses efter. I praksis ligger der ofte analytics, chat-widgets, A/B-tests og anmeldelses-apps og blokerer i den kritiske sti, hvor de aldrig burde være.

Hydrering: at gøre en færdig side dyr igen

Moderne frontend-teknikker sender først HTML, der ser færdig ud, og derefter JavaScript, der skal gøre den interaktiv. Det er “hydration”, og det er dyrere, end det lyder: mens scriptet kører, er knapperne ikke svarer, selv om de ser ud som om, de er. På en langsom telefon kan der gå sekunder, hvor kunden trykker, intet sker, og tilliden tager skade.

Main thread: dér, hvor interaktiviteten drukner

Browserens main thread er en enkelt kø. Et script, der bruger 300 ms, blokerer alt andet i de 300 ms, inklusive klik. Det er derfor, INP er den metric, kunderne faktisk mærker. Et klik, der ikke svarer inden for et par hundrede millisekunder, føles som en fejl, uanset hvad Lighthouse mente om siden.

Hver node i DOM'en har en pris: hukommelse, stilberegning, layout og paint. En simpel produktside bør kunne stå i et par tusind noder. Vi har set dem på over 12.000, bygget af avancerede menuer, mega-menuer, avancerede produktgallerier, pop-ups og tre forskellige anmeldelses-widgets, der hver især indsætter deres egen struktur.

Det mest opsigtsvækkende er, hvor lidt der bliver vist. En mega-menu med 900 noder kan vise 40 links og blive åbnet af under to procent af de besøgende. Resten af besøgende betaler prisen alligevel, fordi browseren skal forholde sig til det hele, hver gang layoutet beregnes.

Det dyreste JavaScript er ikke det, der fejler. Det er det, der kører, lykkes, og ikke gør noget for kunden. Event listeners, der spejder efter klik i elementer, der ikke findes på siden, polling-loops, der henter data hvert femte sekund, og re-renders, der genopbygger hele komponenttræer for at opdatere et tal.

Målingen ligger i browserens egen Performance API snarere end i en rapport udefra: long tasks over 50 ms, tid brugt i tredjeparts-kode, hvor mange gange layoutet beregnes under indlæsning. Vi finder sjældent én stor synder. Vi finder femten scripts, der hver koster 20-40 ms, og tilsammen gør siden ubrugelig i det første sekund, hvor kunden er mest motiveret.

Arbejdet starter med Real User Monitoring frem for laboratorietest: hvad møder kunderne faktisk, på hvilke enheder, med hvilke forbindelser? Derefter sættes budgetter, et loft for TTFB, LCP, INP og tredjeparts-JavaScript, og de håndhæves, som man håndhæver et budget. Enhver ny funktion skal betale sin egen vægt.

Teknisk betyder det edge-cache tæt på kunden, server-rendered HTML frem for klient-hydrering hvor det er muligt, scripts der indlæses efter behov i stedet for i den kritiske sti, og prefetch af næste side, så klikket føles øjeblikkeligt. Ingen af delene er et plugin. Alle delene er en arkitektur, og den arkitektur er den eneste, der kan svare på, hvad hastighed reelt koster og indbringer.