Core Web Vitals i 2026: LCP, INP og CLS uden jargon
Tre akronymer bestemmer, 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 ændring er det den ændring, der bevæger nummeret mest.
Core Web Vitals er tre tal Google måler på virkelige besøg: hvor hurtigt hovedindholdet vises (LCP, god er 2,5s), hvor hurtigt siden reagerer på et tryk (INP, god er 200ms), og hvor meget siden reagerer på et tryk (INP, god er 200ms), og hvor meget siden er 200ms. layout hopper under indlæsning (CLS, god er 0,1). Du er vurderet til 75. percentil, så tre ud af fire besøg skal være gode - ikke kun dine på en hurtig bærbar computer.
Google har mange rankingsignaler, og de fleste af dem kan du ikke måle. Core Web Vitals er en sjælden undtagelse: tre konkrete tal, der er 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øgerangeringer og besøgende, der ikke bliver irriteret.
De er også, mere end nogen anden præstationsmåling, noget folk bruger måneder på at optimere i den forkerte rækkefølge. Så dette stykke er organiseret omkring, hvad der faktisk bevæger hvert nummer, groft rangeret.
Hvad tæller som godt i 2026
| Metrisk | Foranstaltninger | Godt | Behov for arbejde | Dårlig |
|---|---|---|---|---|
| LCP | Når det største element er færdigt | 2,5s | 2,54s | > 4'ere |
| 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 |
Der er to ting ved den bordtur. Tærsklerne måles ved 75. percentil af reelle besøg over et rullende 28-dages vindue - så en fjerdedel af dine besøgende kan have en dårlig tid, og du passerer stadig, 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: Få det store på skærmen
LCP er næsten altid din heltebillede, din overskrift blok, eller de vigtigste banner. Det er den målemetode, som de fleste websteder fejler, og det er også den mest fikserbare, fordi årsagerne er kedelige og mekaniske.
Hvad bevæger det mest
I grov rækkefølge af, hvor meget forskel de gør på et typisk websted:
- Brug LCP-billedet korrekt. Højre format (AVIF eller WebP), rigtige dimensioner for skærmstørrelsen, fra en kantserver nær den besøgende. Denne enkelt ændring flytter flere steder fra rødt til grønt end alt andet tilsammen.
- Få browseren til at opdage det tidligt. Et billede, der refereres til af CSS, eller et billede, der er ladet eller injiceret af JavaScript, bliver fundet for sent. Sæt det i HTML-koden som et almindeligt img-tag, og sæt aldrig
loading="lazy"på det element, der er dit LCP. - Skær tiden til første byte. LCP kan ikke starte, før HTML-koden kommer. Hvis TTFB er 800 ms, har du brugt en tredjedel af dit budget, før gengivelsen begynder.
- Stop gengivelsesblokering af ressourcer. Alle synkrone stilark og scripts i hovedet forsinker malingen.
Se, hvilket element Chrome rent faktisk overvejer, før du optimerer noget som helst – DevTools viser det i panelet Performance. Folk bruger rutinemæssigt en uge på at optimere et heltebillede, der aldrig har været LCP-elementet.
INP: Få siden til at reagere
INP erstattede FID i marts 2024, og det er en meget sværere måling at passere. FID målte kun forsinkelsen, før den første interaktion blev håndteret. INP måler det hele - inputforsinkelse, din begivenhedshåndtering kører, og browseren maler faktisk resultatet - på tværs af hver interaktion på siden og rapporterer omtrent 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 reagere på noget. Besøgende trykker på en menu, intet sker i 400 millisekunder, de trykker igen, og nu har du to menuer i kø.
Hvad bevæger det mest
Opdel lange opgaver – alt over 50 ms – så browseren får mulighed for at reagere mellem dem. Udsæt tredjeparts scripts, der ikke behøver at køre under belastning; analytics, chat widgets og tag managers er de sædvanlige lovovertrædere, og de er normalt nemme 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 eneste målemetode, som CDN ikke kan rette 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: At få siden til at holde stille
Layoutskift er det, der får dig til at trykke på den forkerte knap, fordi en annonce har indlæst og skubbet alt ned. Det måles som en score snarere end en tid, der kombinerer, hvor meget af visningsområdet der blev flyttet, med hvor langt det blev flyttet.
Reparationerne er uglamorøse og pålideligt effektive. Angiv tydelige attributter for bredde og højde på hvert billede, så browseren reserverer pladsen, før filen ankommer. Giv annoncepladser og indlejrer en fast minimumshøjde. Indlæs webskrifttyper med font-display: swap og en målingsmatchet reservedel, så teksten ikke ændres, når den rigtige skrifttype lander. Og aldrig injicere 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:
Jeg jagter et fyrtårn. Lighthouse er en laboratorietest på en simuleret enhed. Google rangerer efter 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 relaterede. Find den i den røde, fix det, mål igen. Normalt er det LCP.
Genmåling næste morgen. Vurderingen er et 28 dages rullende vindue. En løsning, der er implementeret i dag, vises gradvist i løbet af den følgende måned. Brug et script til overvågning af brugere, hvis du vil have hurtigere feedback end det – det vil vise dig ændringen inden for få timer, selvom den officielle vurdering er forsinket.
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 hovedindholdet 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 faktiske 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 billedet tidligt i HTML.
Hvad erstattede den første inputforsinkelse?
Interaktion med næste maling erstattede første inputforsinkelse som en vigtig del af kerneweben 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å det værste.
Forbedrer en CDN Core Web Vitals?
Det forbedrer LCP betydeligt 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, og hvilken leveringshastighed der ikke ændres.
Hvor lang tid tager det at opdatere Core Web Vitals efter en reparation?
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. Overvågning af din egen hjemmeside vil vise forbedringen inden for få timer, hvis du har brug for hurtigere bekræftelse af, at en ændring har virket.
Hvorfor matcher mit Lighthouse-resultat ikke Search Console?
Lighthouse kører en enkelt simuleret test på en opstryget forbindelse i et laboratorium, mens Search Console rapporterer feltdata fra rigtige Chrome-brugere på rigtige enheder og netværk. De er ofte uenige. Feltdata er det, som Google rangerer efter, så behandl Lighthouse som et værktøj til fejlfinding, når du skal finde problemer, snarere end som en resultattavle.
Hvis du fjerner én ting: Find din værste måling, fix den største enkeltstående årsag til den, 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 med IT – mest som vært – 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 og sikker infrastruktur enkel at bruge.
