CLS og INP er Core Web Vitals, der måler andre sider af brugeroplevelsen end hastighed.
CLS måler visuel stabilitet. Et layoutskift sker, når indhold flytter sig efter indlæsningen. Brugeren læser en artikel. En annonce indlæses. Artiklen rykker nedad. Brugeren mister overblikket. CLS sætter tal på det irriterende.
INP måler respons. Brugeren klikker på en knap. Systemet svarer. Hvor lang tid tager svaret? INP sætter tal på forsinkelsen.
Cumulative Layout Shift (CLS) i detaljer
Hvad forårsager CLS
Annoncer indlæses og fylder. Indlejret indhold indlæses og fylder. Billeder indlæses uden en angivet højde. Skrifttyper skifter, og teksten flyder om. Indhold sættes ind med JavaScript.
Et ægte eksempel
Sidens layout er stabilt. Brugeren begynder at læse. En annonce indlæses. Annoncen er 300 pixel høj. Indholdet under annoncen rykker 300 pixel nedad. Brugeren mister overblikket. Det er irriterende.
Måling
CLS måles som den andel af synsfeltet, der flytter sig. Hvis synsfeltet er 1.000 pixel højt, og indholdet flytter sig 300 pixel, er CLS 0,3. Målet er under 0,1 (et skift på ti procent er acceptabelt, et skift på tredive procent er ikke).
Sådan optimerer du CLS
Strategi ét: reserver plads
Reserver plads til annoncer, indlejret indhold og billeder. Fortæl layoutet: Annoncen fylder 300 pixel. Reserver pladsen. Annoncen indlæses i den reserverede plads. Intet skift.
Strategi to: sæt ind nederst
Undgå at sætte indhold ind midt på siden. Sæt det ind nederst (indholdet under er allerede rullet ud af synsfeltet). Eller sæt det ind i en fast header (brugeren forventer, at headeren ændrer sig).
Strategi tre: undgå skift af skrifttype
Undgå at skifte skrifttype midt i indlæsningen. Et skift af skrifttype får teksten til at flyde om. Al tekst med den skrifttype flytter sig. Brug `font-display: optional` eller `font-display: swap` for at begrænse skiftet.
Strategi fire: angiv billedets højde
Brug en fast højde til billeder. Billedet indlæses. Højden er angivet. Billedet fylder den reserverede plads. Intet skift.
Et ægte eksempel: CLS-optimering af en produktside i en webshop
CLS i udgangspunktet: 0,25 (dårlig).
Analyse
Produktbillederne indlæses uden en angivet højde. Billederne får indholdet til at skifte. Det giver 0,10 CLS. En annonce under produktet indlæses, efter siden er klar. Annoncen fylder. Indholdet skifter. Det giver 0,12 CLS. Brugeranmeldelser hentes fra et API. De sættes ind på siden. Indholdet skifter. Det giver 0,3 CLS.
Optimering
Angiv billedets højde i HTML. Billederne fylder den reserverede plads. Bidrag til CLS: nul. Reserver plads til annoncen. Annoncen indlæses i den reserverede plads. Bidrag til CLS: nul. Brug lazy loading til brugeranmeldelserne længere nede. Sæt dem ikke ind øverst. Bidrag til CLS: nul (skiftet sker uden for synsfeltet).
Ny CLS: 0,05 (god).
Interaction to Next Paint (INP) i detaljer
Hvad INP måler
INP måler respons. Brugeren klikker på en knap. Systemet behandler klikket. Opdaterer tilstanden. Viser ændringen. Tegner den på skærmen. INP er tiden fra klik til den første synlige opdatering.
Et ægte eksempel
Brugeren klikker på knappen Læg i kurv. Systemet tjekker lageret. Opdaterer kurvtælleren. Viser det nye tal på skærmen. Er INP 100 millisekunder, ser brugeren kurvtælleren opdatere med det samme. Er INP ét sekund, opdateres kurvtælleren ét sekund senere. Det føles trægt.
Måling
INP måles i millisekunder. Et mål under 200 millisekunder er godt.
Sådan optimerer du INP
Strategi ét: sænk kørselstiden for JavaScript
Lang JavaScript blokerer visningen. Del lange opgaver op i mindre opgaver. Brug async, defer eller Web Workers til tunge beregninger.
Strategi to: optimer hændelseshåndtering
Hændelseshåndtering skal gøre så lidt arbejde som muligt. Flyt det tunge arbejde i baggrunden.
Strategi tre: optimer CSS
Tung CSS kan forsinke visningen. Brug CSS containment til at fortælle browseren: Dette element er selvstændigt, så genberegn ikke typografien for hele siden, når elementet ændrer sig.
Strategi fire: brug en hurtigere måde at vise på
CSS-opdateringer er hurtigere end opdateringer af DOM med JavaScript. Brug CSS transforms i stedet for at flytte med left/top. Brug CSS opacity i stedet for at skifte synlighed.
Et ægte eksempel: respons i en formular
INP i udgangspunktet: 400 millisekunder (dårlig).
Analyse
Formularen har JavaScript til validering. Brugeren skriver i et felt. Valideringen kører. Valideringen er synkron. Den blokerer opdateringen af feltet. Feltet opdateres ikke, før valideringen er færdig. Det føles trægt.
Optimering
Flyt valideringen i baggrunden (Web Worker eller setTimeout). Feltet opdateres med det samme. Valideringen sker i baggrunden. Brug CSS containment på formularen. Fortæl browseren: Formularen er selvstændig, så genberegn ikke typografien for hele siden. Brug CSS transform til animation i stedet for at flytte med JavaScript.
Ny INP: 150 millisekunder (god).
CLS og INP sammen
CLS får siden til at føles ustabil. INP får siden til at føles træg. Sammen påvirker de, hvordan brugeren opfatter kvaliteten.
En side med god LCP, men dårlig CLS (hurtig, men hoppende) er frustrerende. Brugeren giver langsomheden skylden, selv om det er et problem med stabilitet.
En side med god LCP og CLS, men dårlig INP (hurtig og stabil, men træg at bruge), føles ødelagt. Knapperne svarer ikke på klik.
Alle tre Core Web Vitals har betydning for en god brugeroplevelse.
Ofte stillede spørgsmål
Hvordan finder vi problemer med CLS?
Brug Chrome DevTools. Højreklik på siden. Vælg Inspicer. Åbn fanen Performance. Optag sideindlæsningen. DevTools viser layoutskift under indlæsningen. Tjek også PageSpeed Insights. Lighthouse peger på problemer med CLS. Tjek også rapporten om Core Web Vitals i Search Console. Den viser sider med dårlig CLS. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Skal vi reservere plads til alle annoncer eller kun til de kritiske?
Reserver plads til annoncer øverst på siden (annoncer, der indlæses med det samme). Reserver ikke plads til annoncer længere nede (annoncer, der indlæses, når man scroller). Annoncer længere nede kan flytte indhold længere nede, men brugeren ser ikke skiftet.
Hvordan optimerer vi INP i komplekse programmer med meget JavaScript?
Flyt tunge beregninger over i Web Workers. En Web Worker kører på en separat tråd. Den blokerer ikke hovedtråden. Hovedtråden bliver ved med at svare på brugerens input. Brug også React Suspense eller lignende rammeværk, der udsætter tunge beregninger, til interaktionen er håndteret.
Er CLS vigtigere på mobil end på computer?
Ja, mere vigtig på mobil. Mobilskærmen er mindre. Layoutskift er mere synlige. En mobilbruger lægger oftere mærke til skiftet og bliver frustreret. Prioriter CLS-optimering på mobil.
Kan god CLS og INP veje op for dårlig LCP?
Nej. Tager siden fem sekunder at indlæse, er brugeren allerede frustreret, før CLS og INP får betydning. Brugeren forlader siden, før vedkommende har brugt den. Hurtig indlæsning (god LCP) er en forudsætning for en god oplevelse. God CLS og INP forbedrer oplevelsen af en hurtig side, ikke af en langsom side.
Hvordan måler og følger vi forbedringer af CLS og INP?
Udgangspunkt: Mål, før du optimerer. Gennemfør optimeringen. Ny måling: Mål bagefter. Brug Web Vitals-biblioteket (et JavaScript-bibliotek, der måler Core Web Vitals) til at følge med hos rigtige brugere. Sæt alarmer op: Hvis CLS eller INP bliver dårligere, giver en alarm teamet besked.