Core Web Vitals i 2026: LCP, INP og CLS uden jargon
Tre akronymer bestemmer en bid af, hvordan Google rangerer dig, og hvordan dit websted føles at bruge. Her er, hvad LCP, INP og CLS virkelig måler - og for hver, den ændring, der bevæger nummeret mest.
Core Web Vitals er tre tal Google måler på reelle besøg: hvor hurtigt det vigtigste indhold vises (LCP, godt er 2,5 s), hvor hurtigt siden reagerer på et tryk (INP, godt er 200ms), og hvor meget layoutet hopper under indlæsning (CLS, godt er 0,1). Du er klassificeret på 75. percentil, så tre ud af fire besøg skal være gode - ikke kun din på en hurtig bærbar computer.
Google har mange ranking signaler, og de fleste af dem kan du ikke måle. Core Web Vitals er den sjældne undtagelse: tre konkrete tal, indsamlet fra rigtige Chrome-brugere, som du kan se og forbedre. De er værd at forstå, fordi de sidder i skæringspunktet mellem to ting, du bekymrer dig om - søgning placeringer, og besøgende ikke bliver irriteret.
De er også, mere end nogen anden præstationsmåling, en ting, folk bruger måneder på at optimere i den forkerte rækkefølge. Så dette stykke er organiseret omkring, hvad der rent faktisk bevæger hvert tal, groft rangeret.
Hvad tæller som godt i 2026
| Metrisk | Foranstaltninger | Godt. | Behov for arbejde | Fattig |
|---|---|---|---|---|
| LCP | Når det største element er færdigt | 2.5s | 2,54s | > 4s |
| INP | Lag fra en interaktion til den næste visuelle opdatering | 200ms | 200 500ms | > 500ms |
| CLS | Hvor meget synligt indhold skifter uventet | ≤ 0.1 | 0.1–0.25 | > 0.25 |
To ting om det bord tur folk op. Tærsklerne måles ved 75. percentil af virkelige besøg over et rullende 28-dages vindue - så en fjerdedel af dine besøgende kan have en dårlig tid, og du stadig passerer, men du kan ikke passere ved at teste på din egen maskine. Og en webadresse får kun sine egne data, når den har nok trafik; mindre sider arver en vurdering fra en gruppe af lignende webadresser på din oprindelse, hvorfor fastsættelse af en langsom skabelon kan flytte sider, du aldrig rørte.
LCP: At få den store ting på skærmen
LCP er næsten altid dit heltebillede, din overskriftsblok eller hovedbanneret. Det er det metriske, de fleste websteder fejler, og det er også det mest fikserbare, fordi årsagerne er kedelige og mekaniske.
Hvad bevæger sig mest
I grove rækkefølge af, hvor meget forskel de gør på et typisk websted:
- Brug LCP-billedet korrekt. Højre format (AVIF eller WebP), højre dimensioner for displaystørrelsen, fra en kantserver nær den besøgende. Denne enkelt ændring flytter flere websteder fra rød til grøn end alt andet kombineret.
- Få browseren til at opdage det tidligt. Et billede, der refereres til af CSS, eller doven-loadet, eller injiceret af JavaScript, bliver fundet sent. Sæt det i HTML som et almindeligt img-tag, og sæt aldrig
loading="lazy"på det element, der er din LCP. - Tid til første byte. LCP kan ikke starte før HTML' en kommer. Hvis TTFB er 800ms har du brugt en tredjedel af dit budget før gengivelse begynder.
- Stop gengivelsesblokering. Hvert synkront stilark og script i hovedet forsinker malingen.
Kontroller, hvilket element Chrome faktisk overvejer dit LCP, før du optimerer noget - DevTools viser det i Performance-panelet. Folk bruger rutinemæssigt en uge på at optimere et heltebillede, der aldrig var LCP-elementet.
INP: Få siden til at reagere
INP erstattede FID i marts 2024, og det er en meget sværere metrisk at passere. FID målte kun forsinkelsen før den første interaktion blev håndteretINP måler det hele - input forsinkelse, din event handler kører, og browseren faktisk male resultatet - på tværs af hver interaktion på siden, og rapporterer nogenlunde den værste.
Årsagen er næsten altid den samme: for meget JavaScript besætter hovedtråden. Mens en lang opgave kører, kan browseren ikke svare på noget. Besøgende trykker på en menu, der sker ikke noget i 400 millisekunder, de trykker igen, og nu har du to menuer i kø.
Hvad bevæger sig mest
Opdel lange opgaver - alt over 50ms - så browseren får en chance for at reagere mellem dem. Udsæt tredjeparts scripts, der ikke behøver at køre under belastning; analytics, chat widgets og tag ledere er de sædvanlige lovovertrædere, og de er normalt let at udskyde. Undgå at gøre dyrt arbejde synkront inde i en begivenhed handler, og hvis et klik udløser noget tungt, male en anerkendelse først og gøre arbejdet efter.
INP er den ene metric en CDN ikke kan løse for dig. Kanten kan levere din JavaScript bundle i 15 millisekunder; browseren stadig nødt til at analysere og udføre det. Hvis din INP er rød, er arbejdet i din kode, ikke din levering.
CLS: få siden til at holde stille
Layoutskift er det, der får dig til at trykke på den forkerte knap, fordi en annonce indlæste og skubbede alt ned. Det måles som en score i stedet for en tid, der kombinerer hvor meget af visningsområdet flyttede med hvor langt det flyttede.
Rettelserne er unglamorøse og pålideligt effektive. Angiv eksplicitte bredde- og højdeattributter på hvert billede, så browseren forbeholder pladsen, før filen ankommer. Giv annoncepladser og indlejrer en fast minimumshøjde. Indlæs webskrifttyper med font-display: swap og en metrics-matched reserve, så teksten ikke flyder igen, når den rigtige skrifttype lander. Og aldrig indsprøjte et banner, cookie meddelelse eller promo bar over indhold, der allerede har gengivet sætte det i HTML fra starten, eller overlejre det.
Hvor folk spilder deres tid
Tre ting, der føles produktive og ikke bevæger sig:
Jagten på et fyrtårn. Lighthouse er en laboratorietest på en simuleret enhed. Google rangerer på feltdata fra rigtige besøgende. En 100 i Lighthouse og en svigtende CWV-vurdering er en helt normal kombination, og når de er uenige, er feltdata den, der tæller.
Optimer alle tre på én gang. Målingerne er uafhængige, og rettelserne er ikke relateret. Find den i den røde, reparer det, mål igen. Normalt er det LCP.
Genmåling næste morgen. Der er tale om et 28-dages rullende vindue. En rettelse, der er implementeret i dag, vises gradvist i løbet af den følgende måned. Brug en real-user overvågning script, hvis du ønsker hurtigere feedback end det det vil vise dig ændringen inden for timer, selv om den officielle vurdering halter.
Almindelige spørgsmål
Hvad er Core Web Vitals?
Core Web Vitals er tre målinger, som Google bruger til at måle brugeroplevelsen af en side: Største indholdsrige maling (hvor længe indtil det primære indhold gengives), Interaktion med næste maling (hvor hurtigt siden reagerer på klik og tryk) og Cumulative Layout Shift (hvor meget layoutet bevæger sig uventet under indlæsning). De indsamles fra rigtige Chrome-besøg og bruges som et rankingsignal.
Hvad er en god LCP score?
2. 5 sekunder eller mindre, målt ved 75. percentil af rigtige besøg. Mellem 2. 5 og 4 sekunder skal forbedres, og over 4 sekunder er vurderet dårlig. Den mest effektive løsning for de fleste websteder er at betjene det største billede i et moderne format på den viste størrelse fra en CDN-kant nær den besøgende, og sørg for, at browseren kan opdage dette billede tidligt i HTML.
Hvad erstattede den første forsinkelse?
Interaktion til næste maling erstattede første input forsinkelse som en kerne Web Vital i marts 2024. INP er strengere: FID målte kun forsinkelsen, før den første interaktion begyndte at behandle, mens INP måler fuld tid fra en interaktion til den næste visuelle opdatering på tværs af alle interaktioner på siden, og Det er tæt på den værste.
Forbedrer en CDN Core Web Vitals?
Det forbedrer LCP væsentligt og CLS lidt, men ikke INP. En CDN skærer netværkstiden for at levere din HTML og dit største billede, og kan konvertere og ændre størrelsen på billedet automatisk, hvilket er den vigtigste løftestang på LCP. INP afhænger af, hvor meget JavaScript der kører i browseren, hvilken leveringshastighed der ikke ændres.
Hvor lang tid tager det at opdatere Core Web Vitals efter en rettelse?
Vurderingen i Search Console bruger et 28-dages rullende vindue med feltdata, så en løsning, der implementeres i dag, forbedrer den rapporterede score gradvist i løbet af de følgende fire uger i stedet for med det samme. Real-user overvågning på dit eget websted vil vise forbedringen inden for timer, hvis du har brug for hurtigere bekræftelse på, at en ændring virkede.
Hvorfor matcher mit Lighthouse-resultat ikke Search Console?
Lighthouse kører en enkelt simuleret test på en dæmpet forbindelse i et laboratorium, mens Search Console rapporterer feltdata fra rigtige Chrome-brugere på rigtige enheder og netværk. De er rutinemæssigt uenige Feltdata er, hvad Google rangerer på, så behandle Lighthouse som et fejlfindingsværktøj til at finde problemer snarere end en resultattavle.
Hvis du tager en ting væk: find din værste metrisk, fix den største enkelt årsag til det, og vent en måned. Core Web Vitals belønner tålmodighed meget mere end de belønner indsats, og de websteder, der scorer godt, er normalt ikke dem, der forsøgte hårdest - de er dem, der rettede det rigtige en gang.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet i IT - for det meste hosting - siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig, sikker infrastruktur enkel at bruge.
