Ydeevne og Core Web Vitals — en hurtig webløsning
LCP, INP og CLS — Googles mål for, hvordan en side reelt opleves
Ydeevne er ikke en finpudsning, man tilføjer til sidst — det er en del af, om en webløsning reelt fungerer for brugeren. Bekendtgørelsen for webudvikleruddannelsen kræver da også, at eleven kan optimere en webbaseret løsning i forhold til teknisk performance. Google har samlet de vigtigste mål for oplevet ydeevne i tre metrikker, kaldet Core Web Vitals, som både bruges til at vurdere brugeroplevelsen og indgår som et signal i søgemaskinens rangering.
§De tre mål — og grænserne for 'godt'
Hvert mål har en grænse for 'godt', en grænse for 'dårligt', og et mellemrum kaldet 'kan forbedres'. Google vurderer en side ud fra den 75. percentil af rigtige besøg — det vil sige, at mindst tre ud af fire besøg skal ramme den gode grænse, før siden som helhed regnes for god på det mål.
| Mål | Hvad det måler | Godt | Dårligt |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Hvor hurtigt det største, synlige indhold er vist | 2,5 sekunder eller derunder | Over 4 sekunder |
| INP (Interaction to Next Paint) | Hvor hurtigt siden reagerer visuelt på en brugerhandling | 200 millisekunder eller derunder | Over 500 millisekunder |
| CLS (Cumulative Layout Shift) | Hvor meget synligt indhold flytter sig uventet under indlæsning | 0,1 eller derunder | Over 0,25 |
§LCP — det vigtigste indhold skal vises hurtigt
LCP måler, hvornår det største og mest fremtrædende element i det synlige område er færdigindlæst — ofte et hero-billede eller en overskrift. De hyppigste årsager til en dårlig LCP er tunge, uoptimerede billeder, en langsom server, og ressourcer der blokerer siden i at rendere, mens de hentes. Optimér billeder i størrelse og format, lad kritiske ressourcer hentes tidligt, og undgå at det vigtigste indhold skal vente på ting, brugeren slet ikke kigger på endnu.
§INP — reaktionen på et klik
INP afløste i 2024 det tidligere mål FID og ser bredere på responsivitet: det måler hele forløbet fra en brugerhandling, til siden visuelt har reageret, hen over hele besøget, ikke kun første interaktion. Tunge JavaScript-opgaver, der blokerer hovedtråden, er den typiske synder — en knap, der ikke reagerer med det samme, fordi browseren er optaget af noget andet. Løsningen er at dele store opgaver op i mindre bidder og undgå unødvendigt tungt arbejde, netop når brugeren interagerer.
§CLS — når indhold hopper under øjnene på brugeren
CLS opstår, når synligt indhold flytter sig, uden at brugeren har gjort noget — det klassiske eksempel er et billede uden angivne mål, der først reserverer sin plads, når det er færdigindlæst, og skubber teksten under sig ned. Et andet eksempel er indhold, der pludselig indsættes øverst på siden, mens man er ved at læse eller klikke. Reservér plads til billeder og indlejret indhold på forhånd, og undgå at indsætte nyt indhold over det, brugeren allerede kigger på.
- 01Optimér og skalér billeder til den størrelse, de reelt vises i
- 02Lad ikke-kritisk JavaScript og styling hentes uden at blokere det vigtigste indhold
- 03Del tungt JavaScript-arbejde op i mindre stykker
- 04Angiv altid bredde og højde på billeder og indlejret indhold
- 05Cache det, der ikke ændrer sig ofte
“Brugeren dømmer ikke din kode — de dømmer, hvor hurtigt siden føles klar til at bruges.”
— Almindelig læreregel i webydeevne