Core Web Vitals for dem der skal sælge

Core Web Vitals bliver som regel forklaret til udviklere. Det her er forklaringen til dig der skal sælge noget, og som bare vil vide hvad de tre tal koster dig.

De hedder LCP, INP og CLS, og de svarer på tre spørgsmål en kunde stiller uden at tænke over det: Kom der noget? Virker det? Bliver det stående?

LCP: kom der noget?

LCP måler hvornår det største element på skærmen er tegnet færdigt — typisk dit hero-billede eller din overskrift. Grænsen for godt er 2,5 sekunder.

Hvad kunden oplever: en hvid skærm. Ikke en langsom side — en tom side. Kunden ved ikke om der kommer noget, om linket var forkert, eller om nettet er dårligt. Og han er allerede på vej tilbage til Google, hvor din konkurrent står lige under dig.

Hvad det koster: det er her de fleste besøgende går tabt, og de går tabt før de har set hvad du sælger. De så aldrig dit produkt, din pris eller dit navn. Der er ingen anden post i hele hastighedsoptimering hvor tabet er så rent.

Hvad der driver den: serverens svartid (TTFB) og størrelsen på hero-billedet. To ting, og begge kan rettes uden at røre designet. Se Billeder er stadig den største synder.

INP: virker det?

INP måler hvor lang tid der går fra kunden klikker, til skærmen viser resultatet. Grænsen for godt er 200 millisekunder. Det måles gennem hele besøget, ikke kun i starten.

Hvad kunden oplever: han trykker “Læg i kurv”. Der sker ingenting. Han trykker igen. Nu ligger der to.

Eller: han vælger en størrelse i en variationsvælger, og der går et halvt sekund før prisen opdaterer. Han når at tvivle på om valget blev registreret.

Hvad det koster: det her rammer sent i købsprocessen, hvor kunden allerede har besluttet sig. Det er den dyreste slags frafald, fordi du har betalt for at få ham hele vejen dertil. Ejendomsportalen Fotocasa fik en fremgang på 27 procent i henvendelser efter blandt andet at have arbejdet med INP, og rejsesitet Redbus målte 7 procent mere salg efter at have skåret svartiden ned på deres søgefelt.

Hvad der driver den: JavaScript. Plugins der lytter med på hvert klik, og tredjeparter der kører på samme tråd som din kurv. Det rammer webshops hårdere end almindelige firmasider, fordi webshops har flere ting man klikker på. Se hastighedsoptimering af WooCommerce.

CLS: bliver det stående?

CLS måler hvor meget indholdet flytter sig efter at det er tegnet. Det er ikke en tid, men et forholdstal, og grænsen for godt er 0,1.

Hvad kunden oplever: han sigter efter “Køb”, et cookiebanner popper op, og han rammer “Afmeld nyhedsbrev”. Eller han er ved at læse din pris, et billede lander over den, og teksten hopper tre linjer ned.

Hvad det koster: irritation frem for ventetid — og fejlklik. På mobil er det værst, fordi fingeren er upræcis og skærmen er lille. Det er også det eneste af de tre der får kunden til at føle sig dum, og det er ikke en følelse man køber noget i.

Hvad der driver den: billeder uden width og height, cookiebannere og reklamer uden reserveret plads, og skrifttyper der byttes undervejs. Alle tre kan rettes på en formiddag, og CLS 0 er et realistisk mål.

Hvordan de tre hænger sammen med pengene

Tag en kunde gennem et køb, og se hvor hvert tal rammer:

Trin	Tal	Hvad der går galt
Klikker på dit resultat i Google	LCP	Tom skærm. Han går tilbage
Læser produktsiden	CLS	Indholdet hopper. Han mister tråden
Vælger variant, lægger i kurv	INP	Intet svar. Han klikker igen
Går til kassen	TTFB	Kassen kan ikke caches. Nu er serveren alene

Bemærk det sidste. Kurv, kasse og Min konto må aldrig caches, så de sider har ikke en cache at falde tilbage på. Det er præcis dér kunden er tættest på at betale — og præcis dér din server står alene. Se TTFB: når problemet er serveren.

Rangordn efter penge, ikke efter score

Det er den vigtigste beslutning, og det er dér de fleste går galt i byen.

Er LCP rød, så start der. Uanset hvad de to andre siger. Du taber besøgende før de har set noget, og alt andet arbejde er spildt på folk der aldrig kom ind.

Er CLS rød og de andre grønne, så tag den næst. Den er billigst at rette af de tre, og gevinsten kommer med det samme.

INP tager du til sidst — men kun fordi den er dyrest at arbejde med, ikke fordi den betyder mindst. På en webshop er den ofte den der koster mest per besøgende.

Om målingen: to forskellige tal

Der er en detalje der forvirrer alle, og den er værd at have med.

Google måler Core Web Vitals på feltdata: rigtige besøg fra rigtige mennesker, samlet over 28 dage, gjort op på 75. percentil — altså det tal tre ud af fire oplever bedre end. Det er dét der tæller.

Et testværktøj laver en laboratoriemåling: ét besøg, én simuleret forbindelse, fra ét sted. Det er nyttigt til fejlsøgning, men det er ikke det samme tal. Og INP kan slet ikke måles der — der er ingen til at klikke.

Så når din test siger 95, og Search Console siger at siden ikke består: begge dele kan være rigtige. Se Hvad en hastighedstest IKKE fortæller.

Ofte stillede spørgsmål

Hvor meget betyder Core Web Vitals for min placering på Google?

Mindre end relevans og indhold. De indgår i Googles vurdering af sidefunktionalitet og er med til at bryde ligheden mellem to sider der ellers svarer lige godt. Den stærkere grund til at tage dem alvorligt er, at en langsom side mister kunder uanset hvad Google mener.

Hvor ser jeg mine egne tal?

I Google Search Console under rapporten for Core Web Vitals, hvis du har besøgende nok til at der er data. Ellers i PageSpeed Insights — kig i feltdelen øverst, ikke på scoren.

Skal alle tre være grønne?

Ja, for at siden tæller som bestået. Google vurderer en URL som god når alle tre ligger i det gode felt på 75. percentil. Én rød måling er nok til at falde igennem.

Hvad kan jeg forvente at hastighed gør for min omsætning?

Der findes ingen omregningsfaktor, og den der lover dig en, gætter. De offentliggjorte cases ligger typisk i intervallet et par procent til et par tiere procent — men det afhænger af hvor langsom du var, hvad du sælger, og hvem der køber det. Mål dine egne tal før og efter, det er den eneste ærlige måde.