Core Web Vitals er ikke bare en teknisk score, som udviklere går op i. For en webshop er det tæt på bundlinjen: Kan kunden se det vigtigste indhold hurtigt, reagerer siden straks på klik, og står layoutet stille nok til, at man trykker det rigtige sted?
Når en webshop halter på LCP, INP eller CLS, mærkes det med det samme. Produktsiden føles tung. Filtre reagerer sent. Knapper flytter sig. Og så stiger frafaldet. Google bruger de her målinger som pejlemærker for god brugeroplevelse, men det vigtigste er ikke Google. Det vigtigste er, at kunder køber mere på sider, der føles hurtige og stabile.
Hvorfor Core Web Vitals betyder noget for webshops
Core Web Vitals består af tre målinger: LCP, INP og CLS. Samlet fortæller de, om en side loader hurtigt, reagerer hurtigt og holder sig visuelt stabil. Det er især relevant i e-handel, fordi købsflowet består af mange små beslutninger og handlinger. Hver forsinkelse koster opmærksomhed. Nogle gange også salg.
Det smarte ved Core Web Vitals er, at de bygger på den oplevelse, rigtige brugere har. Det er ikke kun en syntetisk test i et værktøj. Det er data fra faktiske besøg på rigtige enheder og netværk. Derfor ser man også ofte, at en webshop kan virke “fin” på en hurtig kontorcomputer, men stadig have dårlige tal i felten.
Her er de niveauer, der normalt regnes som gode:
| Metric | Godt niveau | Hvad det betyder i praksis | Typisk problem på webshops |
|---|---|---|---|
| LCP | ≤ 2,5 sek. | Det vigtigste indhold vises hurtigt | Tunge hero-billeder, langsom server, blokkerende kode |
| INP | ≤ 200 ms | Siden reagerer hurtigt på klik og tastetryk | Tunge filtre, cart drawer, tredjepartsscripts |
| CLS | ≤ 0,1 | Layoutet står stabilt | Billeder uden størrelse, bannere, widgets, fontskift |
For mange webshops er gevinsten ret enkel: færre afbrydelser, bedre brugerflow og højere sandsynlighed for køb. Når sider møder Googles anbefalede niveauer, peger data på lavere frafald. Samtidig viser e-commerce-tal igen og igen, at kunder sjældent er tålmodige, hvis indlæsningen trækker ud over få sekunder.
LCP i webshops: få det største element hurtigt frem
LCP står for Largest Contentful Paint. Det er tidspunktet, hvor det største synlige element i skærmen er blevet vist. På en webshop er det ofte et hero-billede, et stort produktfoto eller en markant tekstblok i toppen.
Hvis LCP er langsom, føles siden langsom, også selv om noget andet er begyndt at loade. Brugeren ser ikke det, der faktisk betyder noget endnu. Det er et klassisk problem på forsider, kategorisider og produktsider med store billeder, sliders eller tunge temaer.
Det er også her, mange webshops skyder sig selv i foden. Hero-billedet bliver lazy-loadet. Billedet ligger som baggrund i CSS eller bliver indsat sent via JavaScript. Serveren svarer for langsomt. Eller CSS og JavaScript blokerer, før browseren når frem til det vigtigste indhold.
De fixes, der oftest giver mest LCP-effekt, er ret jordnære:
- Optimer hovedbilledet: brug WebP eller AVIF, korrekt størrelse og komprimering
- Fjern lazy loading på LCP-elementet: det vigtigste billede skal hentes med det samme
- Hæv prioriteten på kritiske ressourcer: brug preload eller
fetchpriority="high"på hero-billedet - Reducer serverens svartid: caching, CDN og bedre hosting gør en mærkbar forskel
Mange starter med at fintrimme småting i CSS eller rydde lidt op i filer. Det kan hjælpe, men hvis LCP-elementet stadig er et alt for tungt billede, eller hvis TTFB er høj, kommer man sjældent langt. Derfor bør LCP-arbejde næsten altid starte med netop det element, der faktisk bliver målt.
Et praktisk råd: Kig først på mobil. Det er ofte her, problemerne er størst, og det er også her, mange webshops mister flest brugere, hvis toppen af siden er for tung.
INP i webshops: gør klik, filtre og kurv hurtige
INP står for Interaction to Next Paint. Den måler, hvor hurtigt siden reagerer, når brugeren gør noget. Ikke kun det første klik, men den samlede interaktivitet på siden.
Det gør INP meget relevant for webshops. Filtrering, variantvalg, “læg i kurv”, åbning af cart drawer, lukning af popups og checkout-trin er alle handlinger, hvor forsinkelse føles skarpere end ved almindelig indlæsning. Brugeren forventer respons med det samme.
Når INP er dårlig, handler det ofte om for meget JavaScript på hovedtråden. Browseren er travlt optaget og kan ikke male næste skærmopdatering hurtigt nok. Det er årsagen til, at knapper føles sløve, eller at brugeren klikker to gange, fordi der ikke sker noget.
De mest almindelige syndere er tit de samme fra webshop til webshop:
- Tunge filtermoduler
- Cart drawers med mange scripts
- Chatwidgets
- Tracking- og marketingtags
- Produktvarianter med kompleks logik
- Temaer med mange animationer
Her er de fixes, der typisk virker bedst: del lange JavaScript-opgaver op, fjern eller udskyd unødvendige tredjepartsscripts, reducer DOM-størrelsen, og gør interaktioner enklere. Hvis et filtermodul kører store beregninger på hvert klik, skal det laves om. Hvis en popup, et review-widget og en chatløsning alle konkurrerer om browserens opmærksomhed, skal noget væk eller senere i køen.
INP er også den metric, hvor det kan være svært at gætte sig frem. En side kan se pæn og hurtig ud, men stadig have elendig respons, når kunder bruger den aktivt. Derfor er måling i rigtige brugssituationer vigtig her.
CLS i webshops: stop layoutskift på produkt- og kategorisider
CLS står for Cumulative Layout Shift. Den måler, hvor meget elementer flytter sig uventet, mens siden loader eller bliver opdateret.
På en webshop er det ekstra irriterende. Brugeren er på vej til at trykke “Læg i kurv”, men knappen rykker sig, fordi et banner, et billede eller et badge lige kommer ind. Eller teksten hopper, når fonten skifter. Den slags skaber usikkerhed. Og det føles sjusket.
CLS kommer sjældent fra én stor fejl. Det er oftere mange små ting, der tilsammen skaber uro: billeder uden bredde og højde, dynamiske kampagneblokke, trust badges, review-widgets, cookie-barer og lagerbeskeder, der bliver skubbet ind over eksisterende indhold.
De fixes, der næsten altid er værd at tage først, er disse:
- Angiv dimensioner på billeder og video: browseren skal kende pladsen, før indholdet loader
- Reserver plads til dynamiske elementer: bannere, widgets og embeds må ikke starte fra nul højde
- Placér nye elementer fornuftigt: undgå at indsætte indhold over det, brugeren allerede ser
Hvis en webshop har mange visuelle komponenter, kan CLS være det letteste sted at hente en hurtig gevinst. Det kræver ofte mindre udviklingstid end større JavaScript-ombygninger, og effekten kan mærkes med det samme.
En stabil side virker mere troværdig.
Prioritering af Core Web Vitals fixes med størst effekt
Det største problem i mange teams er ikke mangel på ideer. Det er forkert rækkefølge. Der bliver brugt tid på småjusteringer, mens de store syndere står urørt.
Hvis målet er at få mest effekt pr. time, bør man prioritere efter tre ting: hvor meget trafik siden har, hvor tæt siden er på køb, og hvor tydelig fejlen er i data. Produktsider, kategorisider og checkout-lignende flows kommer næsten altid før blogindhold og informationssider.
Høj effekt først: hvad der ofte betaler sig hurtigst
| Fix | Primær metric | Effekt | Typisk indsats |
|---|---|---|---|
| Komprimer og udskift tunge billeder | LCP | Høj | Lav til mellem |
| Fjern lazy loading på hero- og produkttop-billeder | LCP | Høj | Lav |
| Caching og CDN | LCP | Høj | Mellem |
| Ryd op i tredjepartsscripts | INP | Høj | Mellem |
| Split lange JavaScript-opgaver | INP | Høj | Mellem til høj |
Angiv width/height eller aspect-ratio |
CLS | Høj | Lav |
| Reserver plads til bannere og widgets | CLS | Høj | Lav til mellem |
| Minificering alene | LCP/INP | Lav til mellem | Lav |
Det er værd at bemærke, at nogle populære “performance fixes” får mere opmærksomhed, end de fortjener. Minificering og små kodeoprydninger er sjældent det, der redder en webshop alene. De er fine, men ofte sekundære i forhold til billeder, serverrespons, JavaScript-belastning og layoutstabilitet.
En enkel prioriteringsmodel for webshoppen
Hvis du vil arbejde struktureret, så brug denne rækkefølge:
- Find de sidetyper med mest trafik og mest omsætning.
- Tjek hvilken metric der er værst for netop de sider.
- Løs den største tekniske årsag først, ikke den letteste kosmetiske opgave.
- Mål igen i feltdata, før næste sprint planlægges.
Det lyder banalt, men det er ofte nok til at undgå mange fejlprioriteringer.
Måling af Core Web Vitals i webshoppen
Man kan ikke forbedre det, man ikke måler ordentligt. Og på Core Web Vitals er det vigtigt at kende forskel på lab-data og feltdata.
Feltdata vs. lab-data for Core Web Vitals
Feltdata kommer fra rigtige brugere. Det er blandt andet det, du ser i Google Search Console og i Chrome UX Report. De data viser, hvordan webshoppen faktisk performer på rigtige enheder, rigtige forbindelser og rigtige besøg.
Lab-data kommer fra værktøjer som Lighthouse og PageSpeed Insights. De er gode til fejlsøgning, fordi de peger på konkrete problemer, men de er stadig en simulation. Lab-data er altså gode til at finde årsager. Feltdata er bedre til at vurdere den reelle forretningseffekt.
Begge dele skal bruges. Hvis du kun kigger på Lighthouse, kan du ende med at optimere noget, som kunderne knap mærker. Hvis du kun kigger på feltdata, kan du se problemet uden at kende årsagen.
Værktøjer til Core Web Vitals på webshops
Google Search Console er som regel første stop. Her kan du se, hvilke URL-grupper der har problemer med LCP, INP og CLS på mobil og desktop. PageSpeed Insights er godt til hurtig analyse af en konkret side. WebPageTest er stærkt, når du vil ned i detaljer med vandfald, prioritering af ressourcer og belastende scripts.
Hvis webshoppen har lidt volumen, giver det god mening at supplere med RUM, altså Real User Monitoring. Så kan man koble performance-data sammen med omsætning, enheder, trafikkilder og sidetyper. Det gør prioritering langt skarpere.
Det vigtigste er ikke at måle mere. Det vigtigste er at måle det rigtige og reagere på det.
Typiske fejl, der holder webshops tilbage
Der er nogle mønstre, som går igen. Mange af dem er skabt af gode intentioner: flere features, mere tracking, flere widgets, større billeder, mere dynamisk indhold. Problemet er, at summen bliver tung.
En klassisk fejl er at tro, at et nyt tema eller en ny app automatisk er “optimeret”. Det er sjældent hele sandheden. En anden er at acceptere, at marketingscripts bare må koste det, de koster. Det behøver de ikke. Mange tags kan udskydes, styres bedre eller fjernes helt uden at skade marketingindsatsen.
En tredje fejl er at arbejde bredt i stedet for dybt. Det giver ofte mere at forbedre 20 vigtige produktsider og 5 kritiske kategoriskabeloner end at lave små tweaks på 2.000 URL’er med lav betydning.
Hvis webshoppen kæmper med Core Web Vitals, er første arbejdsliste ofte meget enkel: få topbilleder under kontrol, ryd op i JavaScript, og sørg for at layoutet ikke hopper. Det er sjældent alt, der skal til. Men det er tit der, den mærkbare effekt starter.