Core Web Vitals forklart: LCP, INP og CLS på enkelt norsk

Core Web Vitals er ikke en personlighetstest for nettstedet ditt

Core Web Vitals blir ofte behandlet som et mystisk poengkort. En side får et rødt tall, noen legger ut et skjermbilde i Slack, og teamet begynner å krangle om JavaScript-rammeverk.

Det er ikke spesielt nyttig.

En bedre måte å tenke på Core Web Vitals på er enklere: De er tre målinger av om en side føles brukbar for en ekte person på en ekte enhet. De fanger ikke opp alle aspekter ved ytelse, tilgjengelighet eller kvalitet. Men de fanger tre vanlige kilder til frustrasjon:

• Hovedinnholdet bruker for lang tid på å vises.
• Siden reagerer tregt når brukeren prøver å gjøre noe.
• Oppsettet hopper rundt mens brukeren leser eller trykker.

Dette er de tre Core Web Vitals: LCP, INP og CLS.

Google bruker dem som en del av sine signaler for sideopplevelse, men SEO-perspektivet er ikke den beste grunnen til å bry seg. Den bedre grunnen er at trege, hoppende og lite responsive sider sløser med brukernes tid. De konverterer også ofte dårligere, gir dårligere støtteopplevelser og eldes dårlig.

De tre målingene i én setning hver

Før vi går inn i detaljene, her er versjonen på enkelt norsk:

• LCP, eller Largest Contentful Paint, måler hvor lang tid det tar før det viktigste synlige innholdet er lastet inn.
• INP, eller Interaction to Next Paint, måler hvor raskt siden reagerer på brukerinteraksjoner gjennom besøket.
• CLS, eller Cumulative Layout Shift, måler hvor mye siden uventet flytter på seg.

De vanlige terskelverdiene er:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s or faster | 2.5s–4.0s | Over 4.0s | | INP | 200ms or faster | 200ms–500ms | Over 500ms | | CLS | 0.1 or lower | 0.1–0.25 | Over 0.25 |

Disse tallene vurderes vanligvis ved 75. persentil av reelle brukerbesøk. Det er viktig. Du prøver ikke å lage én perfekt laboratoriekjøring. Du prøver å gjøre opplevelsen god for de fleste brukere, også personer på tregere telefoner og mer uforutsigbare nettverk.

Hvis du stirrer på en automatisert rapport og er usikker på hvor du skal begynne, hjelper det å skille diagnose fra panikk. Vi har en egen guide om hvordan du leser en Lighthouse-rapport uten å få panikk, som dekker den arbeidsflyten mer detaljert.

LCP: når føles siden lastet inn?

Largest Contentful Paint måler rendringstiden for det største synlige innholdselementet i viewporten. I praksis er det ofte:

• et hero-bilde,
• en stor overskrift,
• et fremhevet artikkelbilde,
• et produktbilde,
• en stor tekstblokk.

LCP spør ikke når hvert skript, sporingspiksel og bilde under første skjermbilde er ferdig lastet. Den spør: når ble det viktigste brukeren kom for å se, synlig?

Det gjør LCP til en mer menneskelig måling enn gammeldags «page load time». En side kan teknisk sett bli ferdig lastet sent, men likevel føles rask hvis hovedinnholdet vises tidlig. Det motsatte er også sant: En side kan utløse load-hendelsen mens hero-området fortsatt er tomt, uskarpt eller blokkert av en rendringsforsinkelse.

Vanlige årsaker til dårlig LCP

De fleste dårlige LCP-problemer kommer fra noen forutsigbare steder:

1. Treg serverrespons

Hvis HTML-dokumentet kommer sent, starter alt annet sent.

1. Rendringsblokkerende CSS eller JavaScript

Nettleseren har innholdet, men kan ikke tegne det ennå.

1. Uoptimaliserte hero-bilder

Det største elementet er for stort, i feil format, ikke prioritert, eller lastes inn lazy ved en feil.

1. Webfonter som forsinker tekstrendring

En stor overskrift kan være LCP-elementet, og fontinnlasting kan forsinke eller visuelt endre den.

1. Forsinkelser fra client-side rendering

Hvis siden trenger en stor JavaScript-bundle før den kan vise meningsfullt innhold, lider LCP.

Slik forbedrer du LCP

Begynn med det faktiske LCP-elementet. Ikke optimaliser tilfeldige ressurser før du vet hva nettleseren måler.

Praktiske tiltak inkluderer:

• Lever HTML raskt: bruk cache der det passer, reduser backend-arbeid, unngå trege omdirigeringer.
• Optimaliser LCP-bildet: bruk riktige dimensjoner, komprimering og format.
• Ikke lazy-load hero-bildet øverst på siden.
• Bruk fetchpriority="high" med omhu for hovedbildet når det faktisk er prioriteten.
• Inline kritisk CSS bare når det gir en meningsfull reduksjon i rendringsforsinkelse.
• Reduser JavaScript som trengs før den første meningsfulle rendringen.
• Bruk font-display: swap eller en annen bevisst fontstrategi.

Bilder og fonter er hyppige syndere. For bilder handler avveiningen ikke bare om «liten fil er bra». Formatvalg, kodingsinnsats og nettleserstøtte spiller også inn, og derfor har vi et praktisk beslutningstre for når AVIF slår WebP og når det ikke gjør det. For sider med mye typografi er webfonter fortsatt en av de enkleste ytelsesgevinstene, fordi mange nettsteder sender flere fontfiler enn de bruker.

INP: reagerer siden når den berøres?

Interaction to Next Paint måler responsivitet. Mer presist ser den på forsinkelsen mellom en brukerinteraksjon og den neste visuelle oppdateringen etter at nettleseren har behandlet interaksjonen.

Interaksjoner inkluderer ting som:

• å klikke på en knapp,
• å trykke på en meny,
• å velge en avkrysningsboks,
• å skrive i et skjemafelt,
• å åpne en accordion.

INP erstattet First Input Delay som en Core Web Vital i 2024. Det var en god endring. First Input Delay så bare på den første interaksjonen. INP er bredere: Den vurderer interaksjoner gjennom hele sidebesøket og rapporterer en interaksjon med høy forsinkelse som sidens responsivitetsscore.

På enkelt norsk: INP fanger sider som ser lastet ut, men føles fastlåst.

Du har sannsynligvis brukt en slik side. Den virker klar. Du trykker på menyen. Ingenting skjer på et halvt sekund. Du trykker igjen. Så skjer to ting samtidig. Det er et INP-problem.

Vanlige årsaker til dårlig INP

INP er som regel et main-thread-problem. Nettleseren vil respondere, men JavaScript, rendringsarbeid eller oppsettberegning står i veien.

Typiske årsaker inkluderer:

• store JavaScript-bundler,
• dyre event handlers,
• hydrering i klientrendrerte apper,
• tredjepartsskript som konkurrerer om main thread,
• langvarige oppgaver etter sideinnlasting,
• komplekse DOM-oppdateringer utløst av små interaksjoner,
• layout thrashing, der kode gjentatte ganger leser og skriver layout-verdier.

Markedsføringstagger, analyse, chat-widgets og samtykkebannere kan alle bidra. Dette betyr ikke «fjern alt». Det betyr at hvert skript på siden har en kostnad, og interaksjonsforsinkelse er ofte der den kostnaden blir synlig.

Slik forbedrer du INP

Å forbedre INP handler mindre om én magisk attributt og mer om å redusere konkurranse om main thread.

Nyttige tilnærminger inkluderer:

• Del lange JavaScript-oppgaver opp i mindre biter.
• Utsett ikke-essensielt arbeid til etter at siden er brukbar.
• Fjern ubrukt JavaScript i stedet for bare å minifisere det.
• Hold event handlers små og forutsigbare.
• Unngå å rendere store deler av grensesnittet på nytt for små tilstandsendringer.
• Bruk CSS for enkle visuelle tilstander der det er mulig.
• Revider tredjepartsskript og last dem bare der de trengs.

Se også på interaksjonsdesign. En knapp som gir umiddelbar visuell tilbakemelding, kan føles mer responsiv, selv om oppfølgingsarbeidet tar lengre tid. Det er ikke en erstatning for ytelse, men det er en del av godt grensesnittarbeid. Sjekklisten vår for tilgjengelige webknapper overlapper med dette: tydelige tilstander, riktig semantikk og forutsigbar oppførsel hjelper både brukere og nettlesere.

CLS: blir siden der brukeren forventer?

Cumulative Layout Shift måler uventet bevegelse av synlige elementer. Hvis en bruker begynner å lese et avsnitt og en annonse, et bilde eller et banner lastes inn over det og skyver teksten ned, bidrar det til CLS.

CLS måles ikke i sekunder. Det er en score basert på hvor mye innhold som flyttet seg, og hvor langt det flyttet seg. Lavere er bedre.

Nøkkelordet er uventet. Layout-endringer som skyldes en brukerhandling, telles vanligvis ikke på samme måte. Hvis noen trykker på «vis mer» og innholdet utvides, er det forventet. Hvis et nyhetsbrevbanner dukker opp øverst etter tre sekunder og skyver alt ned, er det ikke det.

Vanlige årsaker til dårlig CLS

CLS-feil er ofte hverdagslige:

• bilder uten width- og height-attributter,
• annonser eller embeds uten reservert plass,
• cookie-bannere satt inn over innhold,
• webfonter som byttes inn med andre metrikkverdier,
• kampanjefelt som lastes sent,
• dynamisk injisert innhold nær toppen av siden.

Løsningen er vanligvis å reservere plass før innholdet kommer. Nettleseren bør kjenne formen på siden så tidlig som mulig.

Slik forbedrer du CLS

Begynn med de synlige forskyvningene. Se et opptak eller bruk nettleserverktøy for å identifisere hvilke elementer som flytter seg.

Bruk deretter de kjedelige løsningene:

• Legg til eksplisitte width- og height-attributter på bilder.
• Bruk CSS aspect-ratio for responsive mediebeholdere.
• Reserver fast eller minimumsplass for annonser, embeds og iframes.
• Unngå å injisere bannere over eksisterende innhold etter innlasting.
• Velg font-fallbacks med metrikk som ligner sluttfonten.
• Unngå animasjoner som endrer layout-egenskaper som top, left, width eller height; foretrekk transforms.

CLS er en av få ytelsesmålinger der disiplin slår smarthet. Hvis siden har stabile bokser, får den som regel god score.

Feltdata og labdata er begge nyttige, men de svarer på ulike spørsmål

En vanlig kilde til forvirring er at ulike verktøy viser ulike tall. Det er normalt.

Feltdata kommer fra ekte brukere. De gjenspeiler faktiske enheter, nettverk, steder og nettleserforhold. Googles Chrome User Experience Report er et eksempel på feltdata.

Labdata kommer fra et kontrollert testmiljø. Lighthouse er det velkjente eksempelet. Det er repeterbart og nyttig for feilsøking, men det er ikke det samme som brukernes faktiske opplevelse.

Bruk feltdata til å avgjøre om brukere har et reelt problem. Bruk labdata til å gjenskape og feilsøke det problemet.

Husk også at Core Web Vitals vanligvis vurderes per URL eller URL-gruppe, ikke som én abstrakt egenskap ved merkevaren din. Forsiden, blogginnlegget, prissiden og checkout kan ha svært ulike flaskehalser.

En fornuftig arbeidsrekkefølge

Hvis alle tre målingene er dårlige, er fristelsen å starte overalt. Motstå den.

En praktisk rekkefølge er:

1. Fiks åpenbar CLS først

Manglende bildedimensjoner og ustabile bannere er ofte raske gevinster.

1. Forbedre LCP for viktige maler

Fokuser på sider som betyr noe: produktsider, landingssider, artikler, registreringsflyter.

1. Undersøk INP med reelle interaksjoner

Klikk på tingene brukerne faktisk klikker på. Menyer, filtre, skjemaer og checkout-kontroller avslører ofte mer enn den innledende innlastingssporingen.

1. Revider tredjepartsskript

Behold dem som forsvarer kostnaden sin. Fjern eller utsett dem som ikke gjør det.

1. Sett et ytelsesbudsjett

Uten et budsjett forvitrer ytelsesforbedringer. Nye skript, bilder og designkomponenter vil stille og rolig gjøre arbeidet ugjort.

Det viktige poenget: Ikke optimaliser for et merke. Optimaliser for brukerreisen. En marginal scoreforbedring på en side med lav trafikk kan bety mindre enn en litt uperfekt, men mye raskere checkout-interaksjon.

<!-- tool-cta:start -->

💡 Prøv dette: Siden LCP vanligvis er et bildeproblem, krymp hero-elementet ditt med Image Compressor som en første, enkel gevinst.

<!-- tool-cta:end -->

Hva Core Web Vitals ikke forteller deg

Core Web Vitals er nyttige, men ufullstendige.

De forteller deg ikke om innholdet ditt er godt. De forteller deg ikke om navigasjonen din gir mening. De garanterer ikke tilgjengelighet. De måler ikke personvern, sikkerhet, tillit, lesbarhet eller om siden svarer på brukerens spørsmål.

De erstatter heller ikke skjønn. En side kan bestå Core Web Vitals og fortsatt være ubehagelig. En kompleks applikasjon kan bomme på en terskel og likevel være ansvarlig utviklet innenfor sine rammer.

Behandle LCP, INP og CLS som røykvarslere. Når de går av, undersøk. Når de er stille, fortsett å vedlikeholde bygningen.