Core Web Vitals for webshops: det, der faktisk flytter noget

Der måles tre ting. Hvor hurtigt det største element på skærmen vises (LCP), hvor stabilt layoutet ligger, mens siden bygges op (CLS), og hvor hurtigt siden reagerer, når man trykker på noget (INP).

Grænserne skal nås for 75 procent af besøgene. Ikke i gennemsnit. Den forskel er værd at holde fast i, fordi et gennemsnit skjuler de langsomme besøg, og det er netop dem, der koster kurve.

Kunderne måler i øvrigt kun én ting: føles det hurtigt? De tre tal er den bedste erstatning, vi har for det spørgsmål. De er ikke målet i sig selv.

Det første, vi kigger på, er ikke en test, vi selv kører. Det er tallene fra rigtige besøg.

En laboratorietest kører på én maskine, på én forbindelse, én gang. Jeres kunder sidder på mobil, på skiftende net, uden noget i cachen og med ti faner åbne. De to billeder ligner sjældent hinanden.

Derfor starter vi i felt-data og deler dem op:

• Mobil og desktop hver for sig
• Forside, kategoriside, produktside og kurv hver for sig
• Første besøg og gentagne besøg hver for sig

Skabelonen er næsten altid den vigtigste opdeling. En webshop har fire eller fem sidetyper, og de fejler af hver sin grund. Ét samlet tal for domænet fortæller kun, at noget er galt, ikke hvor.

Vi tester på en mellemklasse-telefon, ikke på den nyeste. Det er ikke pedanteri. Det er den eneste måde at se, hvad flertallet af jeres kunder oplever.

En moderne bærbar skjuler næsten alle problemer. Den har kræfter nok til at køre tunge scripts, mens siden bygges op, og den sidder på et stabilt net. En telefon på et par år gør ikke noget af delene. Derfor er det også på mobil, at tallene typisk falder igennem, selv når desktop ser pænt ud.

To ting i praksis. Test med bremset processor og bremset netværk, så billedet svarer til virkeligheden. Og kig altid på mobiltallene først, når I skal beslutte, hvad der bliver lavet.

Det ændrer som regel prioriteringen. Scripts vejer tungere på mobil, billeder lidt mindre, end folk tror.

Den største synder er næsten altid billeder. For tunge filer, forkert format, manglende dimensioner, og det motiv, der bærer siden, hentes som om det var ligegyldigt.

Rækkefølgen, der plejer at virke:

• Moderne format og fornuftig komprimering på alt
• Rigtig bredde og højde angivet på hvert billede
• Hovedbilledet hentet med høj prioritet og uden lazy loading
• Alt under første skærmbillede skubbet bagest i køen

Derefter tredjepartsscripts. Chat, tracking, anmeldelsesvisninger, testværktøjer, popups og de apps, ingen husker at have installeret. Vi laver en liste over dem alle og stiller det samme spørgsmål til hver: hvad koster den i tid, og hvem ville savne den?

Det er ubehageligt arbejde, fordi svaret ofte sætter marketing op mod hastighed. Til gengæld er der ingen andre steder, hvor der er mere at hente.

Næste lag er alt det, der får siden til at hoppe under læsningen.

Fonte, der hentes sent, giver en ombrydning midt i en sætning. Cookiebannere og kampagnebjælker, der skubber indholdet nedad. Anbefalingsmoduler, der får tildelt plads, efter de er kommet ind, i stedet for før. Hver af dem koster på CLS, og tilsammen føles siden ustabil, selv når den er hurtig.

Vi gør tre ting. Reserverer plads til alt, der lander senere. Henter de fonte, der bruges over folden, tidligt. Vælger en reserveskrift, der fylder nogenlunde det samme, så skiftet ikke rykker teksten.

CSS følger samme princip: det, der skal bruges til første skærmbillede, skal med det samme, resten kan vente. Det kan gøres uden at bygge om, og effekten kan ses i tallene dagen efter.

LCP handler om det første indtryk. INP handler om resten af besøget, og den bliver overset af flest.

Mønstret er genkendeligt. Siden loader pænt, men filtrene på kategorisiden er træge, læg i kurv føles forsinket, og variantvælgeren halter et halvt sekund efter fingeren. Årsagen er som regel, at en opgave holder browseren optaget, netop når kunden trykker.

Vi går efter tre ting:

• Hændelser, der sætter for meget arbejde i gang på én gang, typisk filtre og søgefelt
• Tredjepartsscripts, der lytter med på klik over hele siden
• Meget store sider med mange produkter og dyb opbygning

Det er mere programmering end konfiguration, og det er sjældent en indstilling, man kan slå fra. Til gengæld ligger INP tættest på, hvordan det faktisk føles at handle.

Er alt ovenstående gjort, og sitet stadig langsomt, ligger problemet dybere.

Så kigger vi på servertid: hvor længe går der, før det første byte forlader serveren? En langsom server lægger et gulv, som ingen billedoptimering kommer under. Derefter caching, hvor meget der renderes på serveren, og hvad temaet slæber rundt på af moduler fra de sidste mange år.

Det er også her, samtalen om platform begynder. Ikke som en anbefaling, men som et regnestykke: hvad koster det at blive, og hvad koster det at flytte, inklusive alt det, der skal bygges om bagefter.

Vores erfaring er, at platformen sjældent er den egentlige årsag. Et tema med for mange lag og et setup, ingen har ryddet op i, forklarer langt flere af tilfældene.

Hastighed er ikke et projekt med en slutdato. Den forsvinder igen, typisk et par uger efter en kampagne.

Hos de kunder, hvor tallene bliver liggende, er det de samme vaner, der gør forskellen:

• Et fast kig på felt-data hver måned, på de fire vigtigste sidetyper
• En regel om, at nye apps og scripts måles før og efter installation
• Et loft over antallet af tredjepartsværktøjer, så noget ryger ud, når noget nyt skal ind
• En budgetpost til at rydde op, ikke kun til at bygge nyt

Den hurtige side er som regel den, hvor nogen har sagt nej et par gange.

Og en advarsel til sidst. Jagt ikke hundrede point i et testværktøj. Målet er, at kunden kan finde, vælge og betale uden at vente. Tallene viser bare, om det passer.