Kort svar: Core Web Vitals-rapporten i Search Console grupperer dine URL’er efter, hvor ens de opfører sig – så én række med “520 URL’er: LCP over 2,5 s” peger typisk på én skabelon (fx alle produktsider), ikke 520 separate problemer. Ret skabelonen, bekræft rettelsen i en lab-måling, og start derefter valideringen i rapporten. Tallene bygger på 28 dages feltdata fra rigtige Chrome-brugere, så forbedringer viser sig gradvist. Prioritér mobilfanen – det er dér, de fleste fejler.
Fagligt gennemgået: 2. oktober 2026
Search Consoles Core Web Vitals-rapport er det tætteste, du kommer på Googles eget syn på dit sites hastighed – og samtidig en rapport, mange læser forkert: de ser hundredvis af “dårlige URL’er” og går i panik, hvor én skabelonrettelse ville løse det hele. Denne guide lærer dig at læse grupperne, prioritere, rette det rigtige sted – og validere uden at miste tålmodigheden.
Hvad rapporten måler
Rapporten bygger på Chrome User Experience Report (CrUX): målinger fra rigtige besøgende i Chrome over de seneste 28 dage. Det er altså feltdata, ikke en test fra et laboratorium. Værdien for en gruppe er den 75. percentil – det tal, som 75 % af besøgene klarer eller er bedre end. En LCP på 3,1 sekunder betyder derfor, at hvert fjerde besøg oplever en LCP på 3,1 sekunder eller værre.
Google bruger disse grænser:
| Måletal | God | Trænger til forbedring | Dårlig |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Højst 2,5 s | Højst 4 s | Over 4 s |
| INP (Interaction to Next Paint) | Højst 200 ms | Højst 500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | Højst 0,1 | Højst 0,25 | Over 0,25 |
En gruppes status følger det dårligste af de tre måletal for den enhedstype. En gruppe med god LCP og god CLS, men dårlig INP, står som dårlig. Mobil og desktop vises hver for sig, og en gruppe kan sagtens være grøn på desktop og rød på mobil.
Rapporten tænker i grupper
Google samler URL’er, der ligner hinanden og opfører sig ens – i praksis følger grupperne dine skabeloner: produktsider, kategorisider, artikler. Når en gruppe fejler, viser rapporten nogle eksempel-URL’er; de er stikprøver fra gruppen, ikke nødvendigvis de værste sider. Konsekvensen er befriende: du skal ikke rette 520 sider – du skal finde det fælles træk i skabelonen og rette det ét sted:
Har en gruppe af sider for lidt trafik til at få sine egne tal, kan Google samle dem i en bredere origin-gruppe for hele domænet. Det er grunden til, at små sites ofte ser få og store grupper – og at nogle sider slet ikke optræder.
Før du ændrer noget: Gem et skærmbillede af rapportens grupper og tal for både mobil og desktop, og kør PageSpeed Insights på 2–3 eksempel-URL’er. Så har du et sammenligningsgrundlag. Ret én skabelon og ét måletal ad gangen, og test ændringer på staging, hvis de rører tema, header eller globale scripts.
1. Prioritér grupperne
- Mobil før desktop: mobilmålingerne er næsten altid dårligst – og dækker ofte flest besøgende.
- “Dårlig” før “trænger til forbedring”: røde grupper giver den dårligste oplevelse; gule er næste bølge.
- Flest URL’er og vigtigst forretning først: en fejlende produktside-gruppe slår en fejlende arkiv-gruppe.
- Ét måletal ad gangen: grupper fejler på LCP, INP eller CLS – bland ikke tre kampagner sammen.
2. Find skabelonen bag gruppen
Åbn gruppen, og se på eksempel-URL’erne. Har de samme type indhold, samme sidebyggerlayout eller samme kategori? Notér, hvilken skabelon i temaet eller sidebyggeren de bruger. Er eksemplerne en blanding af forskellige sidetyper, er fællesnævneren sandsynligvis noget globalt: header, menu, cookiebanner, chat-widget eller et script, der indlæses på alle sider.
3. Diagnosticér med lab-målinger
Tag en eksempel-URL fra gruppen, og kør den gennem PageSpeed Insights – nu med felt/lab-brillerne på. Øverst ser du feltdata (de samme kilder som rapporten), nederst en lab-måling, der viser, hvorfor siden er langsom. Diagnosen og rettelsen for hvert måletal har hver sin guide: LCP, INP og CLS.
| Måletal | Typiske årsager i WordPress | Hvor rettelsen ligger |
|---|---|---|
| LCP | Stort hero-billede uden prioritering, lazy load på det øverste billede, høj TTFB, render-blokerende CSS og fonts | Skabelonens øverste sektion, billedstørrelser, cache og hosting |
| INP | Tungt JavaScript fra sidebygger, sliders, chat, tracking og tagmanager; store DOM-træer | Scripts, plugins og tredjepartstags |
| CLS | Billeder og embeds uden dimensioner, cookiebannere og notifikationsbarer, der skubber indhold, fontskift | Skabelonens layout, banner-plugin og fontopsætning |
4. Ret i skabelonen, ikke på siden
Fordi problemet ligger i skabelonen, skal rettelsen også ligge dér – i temaet, blokken, sidebyggerens skabelon eller den globale komponent – så den dækker hele gruppen på én gang. At optimere de fem eksempel-URL’er manuelt flytter ikke gruppen, fordi de andre hundrede sider stadig har problemet. Høj TTFB er en særlig sag: den rammer alle grupper og løses i cache og hosting – se guiden om høj TTFB.
5. Validér – og vent rigtigt
Efter rettelsen: bekræft forbedringen med det samme i en lab-måling, så du ikke venter 28 dage på at opdage en fuser. Klik derefter “Validér rettelse” på gruppen. Google følger så gruppen i en overvågningsperiode på 28 dage og melder tilbage.
Valideringen kan have disse statusser (de engelske navne i parentes, da den danske oversættelse kan variere):
- Ikke startet (Not started): der er ikke bedt om validering.
- Startet (Started): Google indsamler nye data; der er endnu ikke fundet tegn på, at problemet består.
- Ser godt ud (Looking good): de nye data tyder på, at rettelsen virker, men perioden er ikke slut.
- Bestået (Passed): gruppen har ikke længere problemet.
- Mislykkedes (Failed): problemet findes stadig i de nye data.
To tålmodighedsregler: valideringen kan fejle, hvis en del af de nye målinger stadig er dårlige – så vent gerne en uge efter udrulningen, før du starter den. Og en mislykket validering betyder ikke nødvendigvis, at rettelsen var forkert – tjek de aktuelle feltdata i PageSpeed Insights, og se om der er kommet et nyt problem til i perioden, før du konkluderer.
Fang regressioner, før de bliver røde
De fleste grupper, der skifter fra god til dårlig, gør det efter en ændring: et nyt banner, en ny pixel, en plugin-opdatering eller en kampagne med anden trafik. Før en enkel ændringslog over udgivelser og nye scripts, så du kan sammenholde datoen for et fald med det, der skete på sitet. Husk, at rapporten altid ser 28 dage tilbage, så et fald ser du gradvist – ofte først en til to uger efter ændringen.
Verifikation
Arbejdet er i mål, når mobil- og desktop-fanerne kun viser grønne grupper, valideringerne står som bestået, og nye skabeloner følges op i rapporten, når de lanceres. Gør rapporten til en månedlig rutine – ti minutters kig – så opdages regressioner, mens de er én gruppe stor. Og husk konteksten: rapporten kræver nævneværdig trafik; mangler dine sider i den, er det ikke et problem, men et datagrundlag, der endnu er for lille.
Læs også
- Hub: WordPress performance og cache
- PageSpeed Insights vs. CrUX
- Dårlig LCP i WordPress
- Dårlig INP i WordPress
- CLS i WordPress
- Hvad er SEO? Søgemaskineoptimering forklaret
- WordPress hosting hos Hostious – LiteSpeed, NVMe og Redis object cache fra WP StartUp
Ofte stillede spørgsmål om Core Web Vitals-rapporten
Hvorfor viser rapporten færre URL’er, end sitet har?
Kun URL’er med nok feltdata indgår – sider med lidt trafik udelades eller samles i en bredere gruppe. Rapporten beskriver de besøgte dele af sitet; de ubesøgte følger typisk med, når skabelonen rettes.
En gruppe røg fra „god“ til „dårlig“ uden ændringer – hvorfor?
Noget ændrede sig alligevel: et nyt script, et tungere banner, en plugin-opdatering – eller trafik fra langsommere enheder (fx en kampagne med mange mobilbesøg). Sammenlign med udgivelses- og kampagnekalenderen for perioden.
Skal alle grupper være grønne, før det gavner?
Nej – hver gruppe, der rykker fra rød mod grøn, forbedrer oplevelsen for netop de sider. Prioritér forretningskritiske skabeloner, og tag resten løbende.
Hvorfor står der, at der ikke er nok data?
Rapporten kræver en vis mængde besøg fra Chrome-brugere for hver enhedstype. Et nyt eller lille site kan derfor mangle data helt, især på desktop. Brug så lab-målinger i PageSpeed Insights som arbejdsredskab, indtil trafikken er stor nok.
Udgivet 30. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026