Google gav annoncetæthed et tal. Tærsklen ligger i et andet produkt

Hvad Chrome begyndte at måle den 15. september

Chrome-teamet udgav fire eksperimentelle annoncemetrikker i Chrome User Experience Report den 15. september 2026. De dækker to ting, der ikke tidligere fandtes som feltdata fra rigtige brugere: hvor meget plads annoncerne fylder, og hvad de koster i ressourcer.

• Ad count — det gennemsnitlige antal distinkte annoncerammer, der er synlige i viewporten, mens brugeren scroller.
• Ad density — den gennemsnitlige andel af det synlige viewportareal, annoncerammerne optager gennem sessionen.
• Ad weight: CPU — den kumulative hovedtrådstid, der går til at hente og køre annoncescripts og -assets, i millisekunder.
• Ad weight: network — den kumulative netværkstrafik fra de samme, i kilobytes.

Tallene følger samme dimensioner og kriterier som Web Vitals og aggregeres over et rullende 28-dagesvindue. I CrUX-API'et hedder felterne experimental_ad_count, experimental_ad_density, experimental_ad_cpu og experimental_ad_kilobytes, og de returneres som p75 — ét tal, ingen histogram, ingen god/dårlig-inddeling. De findes i CrUX Vis, CrUX-API'et, History-API'et og DevTools' annoncepanel. BigQuery er ikke med endnu, og dokumentationen noterer, at metrikkerne kun rapporteres for sider, der er omfattet af ad metrics.

Dokumentationen flyttede dem ind i SEO. Google tog rangeringen ud igen

Den 22. september dukkede de fire metrikker op som en enkelt linje i Googles egen page experience-dokumentation — den side, der ellers samler de signaler, man som sitejer forventes at arbejde med. Danny Sullivan præciserede kort efter, at metrikkerne blev taget med, fordi de hjælper med at vurdere sitets tilstand, og at ikke alt er en direkte rangeringsfaktor (Search Engine Land, 22. september 2026).

Den afvisning er værd at læse præcist. Ad weight CPU er hovedtrådstid, og hovedtrådstid er det stof, INP er lavet af. Annoncer, der lægger beslag på tråden, mens brugeren trykker, er ikke en teoretisk risiko — det er selve mekanikken bag en dårlig INP. Metrikken uden en tærskel er altså diagnosen på den metrik, der har en. Det gør den ikke til en rangeringsfaktor, men det gør den til noget mere end kuriosa på en SEO-side.

Tærsklen findes. Den ligger i et andet Google-produkt

Ordet «ad density» er ikke nyt hos Google. Better Ads Standards har haft en grænse i årevis: annoncer, der optager mere end 30 % af den lodrette højde i en mobilsides hovedindhold, er en af de mindst foretrukne annonceoplevelser. Højden regnes ved at lægge annoncehøjderne sammen og dividere med hovedindholdets samlede højde — header, footer og navigation tæller ikke med, og annoncer under hovedindholdet heller ikke. Sites, der falder igennem, får deres annoncer filtreret i Chrome. Det er den eneste af de tre målinger med en reel konsekvens.

CrUX måler noget andet. Her er tætheden en andel af det synlige viewportareal, målt løbende mens brugeren scroller og aggregeret over sessionen. En lang artikel med tre annoncer fordelt over otte skærmhøjder kan ligge lavt i CrUX og samtidig nærme sig de 30 % i Better Ads-regnestykket — og omvendt kan en kort side med en enkelt stor annonce i første skærmbillede se slem ud i CrUX og være helt ren efter standarden. De to tal er ikke oversættelige.

Den tredje grænse er den hårdeste og den mest oversete. Chromes heavy ad intervention fjerner en annonceramme, brugeren ikke har interageret med, hvis den bruger mere end 4 MB netværk, mere end 15 sekunders hovedtråd i et vilkårligt 30-sekundersvindue, eller mere end 60 sekunders hovedtråd i alt. Rammen erstattes af en grå boks, og der sendes en intervention-rapport til både annoncerammen og forælderen. Her er der ingen tvetydighed: tallene er hårde, og noget forsvinder fra siden.

Sådan bygger du den tærskel, Google ikke gav dig

Et p75-tal uden en grænse er ikke ubrugeligt — det mangler bare en sammenligning. Og fordi CrUX er offentligt på origin-niveau, ligger sammenligningen lige for. Strukturen i opsætningen, ikke koden:

1. Lav listen først. Ti til femten origins i din branche, dit eget iblandt dem. Konkurrenter, ikke tilfældige store sites — en nyhedsforside og en B2B-produktside hører ikke til i samme fordeling.
2. Slå op på origin-niveau, ikke URL. URL-opslag kræver mere trafik for at blive rapporteret, og du er ude efter sitets profil, ikke en enkelt sides.
3. Del på formfaktor. Kør hvert opslag for både telefon og desktop. Annoncetæthed på mobil er en anden historie end på desktop, og Better Ads-grænsen findes kun for mobil.
4. Hent baseline bagud én gang. History-API'et giver omkring 40 ugentlige punkter. Det er hele grundlaget for at kunne se, om en ændring i annoncestakken flyttede noget — hentet i ét opslag, før du begynder at måle fremad.
5. Gem fire felter og en dato pr. origin pr. uge. Mere er der ikke i det. En ugentlig kørsel ved siden af dine Core Web Vitals-tal er nok.
6. Læs din placering i fordelingen, ikke tallet. Din tærskel er ikke et Google-tal. Den er medianen i din egen branche, og det handlingsbare er afstanden til den.

Jeg ville ikke sætte et alarmpunkt på et tal, Google selv kalder eksperimentelt. Men jeg ville begynde at opsamle det nu, for det eneste, der gør den slags data brugbare senere, er, at man har historikken, når definitionen holder op med at være ny.

Hvad tallene ikke kan

Feltdataene kommer fra Chrome — ikke fra Chrome på iOS, ikke fra Android WebView, ikke fra andre browsere. På et dansk site med tung Safari-trafik fra iPhone beskriver metrikkerne altså en delmængde af dine brugere. Dertil kommer, at der kun udleveres p75: du kan ikke se halen, og du kan ikke se, om den ene dårlige værdi skyldes 5 % af sessionerne eller 40 %.

Hvad der overhovedet tælles som en annonce, afgøres af Chromes egen annoncedetektion, ikke af din opsætning. Og metrikkerne er eksplicit eksperimentelle: navne og metode kan ændre sig, præcis som feltnavnenes experimental_-præfiks siger. Det er samme mønster som resten af efteråret — Google udvider målingen hurtigere, end rapporterne følger med, hvilket opdelingen af søgetypen Web i Search Console er et andet eksempel på.