CrUX Ad Metrics: Chromes vier neue Werte zur Werbelast

Am 19. September habe ich in CrUX Vis die Adresse von focus.de eingegeben und auf den neuen Reiter „Ad metrics“ geklickt. Für das Handy stand beim 75. Perzentil eine Werbe-Datenmenge von 6.241 KB pro Seitenbesuch. Direkt danach habe ich seo-kreativ.de eingegeben. In allen vier Diagrammen stand „unavailable“.

Der Unterschied erklärt viel über die neuen Metriken. Chrome erfasst damit nicht jede Form von Werbung. Erfasst werden Anzeigen, die nach der dokumentierten Methode als Werbung erkannt werden. Und das nur auf Sites, die über ihre ads.txt Verkäufer für ihre Werbeplätze angeben.

Mein News-Radar hatte die Meldung am 18. September mit zwei Fachmedien geführt. Einen Tag später stand sie in über einem Dutzend, darunter t3n und OnlineMarketing.de. In keinem der Beiträge, die ich gelesen habe, standen Werte für konkrete Sites. Deshalb habe ich die vier Metriken für zehn deutsche Nachrichtenseiten abgerufen, für Telefon und Desktop. Jeden Wert habe ich gegen die Rohdaten aus Googles Schnittstelle geprüft.

Hier stehen die Zahlen, was sie messen, wo sie in die Irre führen können und wie du sie für deine eigene Site abrufst. Am Ende geht es um die Frage, die in der SEO-Welt zuerst kam: Ist das ein Rankingfaktor?

Am 15. September 2026 hat das Chrome-Team im Chrome-Developer-Blog vier neue Metriken für den Chrome User Experience Report angekündigt, kurz CrUX. Das ist derselbe Datensatz, aus dem auch die Felddaten der Core Web Vitals stammen. Die neuen Werte heißen Ad Count, Ad Density, Ad Weight: CPU und Ad Weight: Network.

Alle vier sind als „experimental“ gekennzeichnet. Chrome schreibt, man sei offen für Rückmeldungen und könne die Metriken weiterentwickeln. Als Zielgruppe nennt die Ankündigung ausdrücklich Werbetreibende und die Dienstleister, über die sie Anzeigen buchen. Dazu kommen Zitate aus der Werbebranche, unter anderem von WPP, The Guardian, Mediavine, Index Exchange und Display & Video 360 von Google.

Ein Satz aus der Ankündigung ist für alle wichtig, die sich mit Core Web Vitals beschäftigen:

„CrUX ad metrics are not part of Core Web Vitals and don’t have suggested targets or thresholds.“

Es gibt also kein „gut“ und kein „schlecht“. Die Metriken sind Messwerte ohne Bewertung. Barry Pollard vom Chrome-Team hat die Einführung am selben Tag in einem Thread auf Bluesky vorgestellt. Dort schreibt er auch, dass die Werte schwer zu messen seien und CrUX deshalb in einer besonderen Position sei, sie zu veröffentlichen.

Die Definitionen stehen in der Chrome-Dokumentation zu den Anzeigen-Metriken. Kurz zusammengefasst:

Anzahl und Fläche misst Chrome einmal pro Sekunde im sichtbaren Bereich und bildet daraus einen Durchschnitt über den Besuch. Für die Anzahl reicht ein sichtbares Pixel. Jede Anzeige zählt einzeln, auch wenn eine andere sie überdeckt. Bei der Fläche zählt eine Überlappung dagegen nur einmal. CPU und Datenmenge werden aufsummiert. Die Messung beginnt mit dem ersten Byte des HTML-Dokuments und endet, wenn die Seite verlassen, der Tab geschlossen oder der Browser beendet wird. Auf Android endet sie auch, wenn der Browser in den Hintergrund geht. Bei Sites, die ohne Neuladen navigieren, läuft sie bis zum Schließen des Tabs weiter. Das steht in der Methodik-Seite.

Gemeldet wird jeweils das 75. Perzentil über ein rollierendes 28-Tage-Fenster, pro Origin und pro URL. Chrome erklärt das an einem Beispiel: Ein p75 von 23 Prozent bei Ad Density heißt, dass 75 Prozent aller Besuche eine Anzeigenfläche von 23 Prozent oder weniger hatten. Bei den übrigen 25 Prozent war sie höher.

Spannend ist, wie Chrome eine Anzeige überhaupt erkennt. Laut der Seite zur Anzeigenerkennung gleicht der Browser Anfragen mit einer verkürzten Fassung der EasyList ab, einer offenen Filterliste gegen Werbung. Zusätzlich prüft er, ob eine Anfrage von einem bereits erkannten Werbeskript ausgelöst wurde. Ein iframe, der einmal als Werbung gilt, bleibt es, auch wenn er später etwas anderes lädt. Das Hauptdokument selbst gilt nie als Werbe-Frame.

Dieselbe Erkennung nutzt Chrome laut der Doku zur Anzeigenerkennung auch für Eingriffe im Browser, etwa um Anzeigen zu entladen, die übermäßig viel CPU oder Daten verbrauchen.

Wie die zehn Sites ausgewählt sind: Ausgangspunkt waren allgemeine Nachrichtenangebote. Davon habe ich die zehn mit dem höchsten geschätzten organischen Google-Traffic in Deutschland genommen, für die CrUX Anzeigenwerte meldet. Die Schätzung stammt aus meiner eigenen Abfrage im SEO-Werkzeug DataForSEO am 19.09.2026. Sie ist die eines Drittanbieters und keine offizielle Google-Zahl. Die Angebote von tagesschau.de, zdf.de, ndr.de und br.de liegen dort zwar weit vorn, haben aber keine ads.txt mit autorisierten Verkäufern und deshalb keine Anzeigenwerte. web.de liegt ebenfalls vor einigen der zehn, ist aber ein E-Mail- und Webportal und kein allgemeines Nachrichtenangebot.

Telefon

Desktop

Drei Dinge fallen beim Lesen auf. Erstens die Spanne bei der Datenmenge auf dem Handy. Zwischen bild.de mit 454 KB und focus.de mit 6.241 KB liegt knapp das Vierzehnfache. Sieben der zehn Sites lagen zwischen 1.900 und 2.900 KB.

Zweitens der Desktop. Dort standen bei allen zehn Sites mehr Anzeigen gleichzeitig im Bild als auf dem Handy. Die Anzeigen belegten auch mehr Fläche. Ein größerer sichtbarer Bereich kann dazu beitragen. Die Ursache lässt sich aus den Daten allein nicht bestimmen. Die höchste Werbe-CPU-Zeit in dieser Auswahl hatte focus.de mit 13.745 ms pro Seitenbesuch am Desktop.

Drittens die Fläche. Mobil lagen die p75-Werte zwischen 8 und 16 Prozent des sichtbaren Bereichs, am Desktop zwischen 13 und 26 Prozent.

Beim Abgleich mit den Rohdaten ist mir etwas aufgefallen, das in keiner Meldung stand, die ich gelesen habe. Die Werte für Ad Count sind nicht beliebig. In den 20 Werten der beiden Tabellen kommen nur elf verschiedene Zahlen vor. Wo zwei davon benachbart sind, liegt der Abstand bei rund 15 Prozent: 1,54 · 1,77 · 2,03 · 2,33 · 2,68.

Für die Praxis heißt das: Zwei Sites mit 2,03 sind nicht zwingend gleich. Und eine Site mit 2,33 liegt eine Stufe über einer mit 2,03, mehr lässt sich daraus nicht ablesen. Warum die Werte so gestuft sind, erklären die Doku-Seiten zu den Anzeigen-Metriken nicht. Ich lese kleine Unterschiede beim Ad Count deshalb nicht als Unterschied.

Der zweite Punkt betrifft CPU und Datenmenge. Beide werden über den ganzen Seitenbesuch aufsummiert. Eine Seite, auf der Nutzer lange bleiben und Anzeigen nachladen, kommt so auf höhere Werte als eine gleich schwere Seite, die man nach zehn Sekunden verlässt. Ein hoher Wert kann also auch an langen Besuchen liegen.

Der dritte Punkt steht in der Doku zur CPU-Metrik:

„The CPU time is measured for ad frames only and excludes CPU time for main frame ad scripts.“

Gezählt wird also nur, was in Werbe-Frames läuft. Werbeskripte, die direkt im Hauptdokument arbeiten, fehlen in Ad Weight: CPU. Harry Roberts weist in seiner Kolumne bei CSS Wizardry darauf hin, dass dieser Anteil erheblich sein kann. Und zwar auf Sites, deren Werbe-Tags früh im Dokument laufen und die Werbe-Frames erst später erzeugen. Eine Site, die ihre Werbung stärker im Hauptdokument steuert, kann bei der CPU-Zeit also niedriger ausfallen als eine vergleichbare Site mit mehr Werbe-Frames.

Dazu kommen die Grenzen der Erkennung. Was nicht auf der Filterliste steht und nicht von einem erkannten Werbeskript kommt, wird nicht als Anzeige erfasst. Und Chrome auf iOS fehlt ganz. Für eine Site mit vielen iPhone-Lesern beschreiben die Werte nur einen Teil des Publikums.

Die Regel steht in der Methodik-Seite. CrUX meldet die Anzeigen-Metriken nur für Sites, deren ads.txt mindestens einen autorisierten Verkäufer nennt. Fehlt die Datei oder steht darin nur ein Platzhalter, bleibt die Site draußen. Daneben gelten die allgemeinen Aufnahmekriterien des Chrome UX Report, etwa eine Mindestzahl an Besuchern. Die ads.txt ist die Datei, mit der Publisher öffentlich festhalten, wer ihre Werbeplätze verkaufen darf.

Auf seo-kreativ.de liefert /ads.txt einen 404. Die Seiten laden auch keine Werbeskripte von Google oder anderen Netzwerken. Das habe ich am 19.09.2026 für die Startseite und zwei Beiträge im Quelltext geprüft.

Werbung gibt es hier trotzdem. Seit August stehen in fünf englischen Beiträgen bezahlte Platzierungen, gekennzeichnet mit „Paid placement“. Es sind Textblöcke direkt im Artikel, ohne iframe und ohne Werbeskript. Nach der dokumentierten Erkennungsmethode würden sie voraussichtlich auch mit ads.txt nicht als Anzeige erfasst, weil das Hauptdokument nie als Werbe-Frame gilt.

Das ist die Grenze der neuen Metriken. Sie beschreiben vor allem Anzeigen, die über Werbenetzwerke und deren Technik ausgeliefert werden. Direkt verkaufte Platzierungen im Text, Affiliate-Links oder Advertorials sind Werbung, werden von diesen Metriken nach den dokumentierten Regeln aber voraussichtlich nicht erfasst. Einzelne Ressourcen im Hauptdokument kann Chrome allerdings als werbebezogen einstufen.

Laut der Tooling-Seite von Chrome gibt es drei Wege. BigQuery soll später dazukommen. Ich habe für diesen Beitrag CrUX Vis genutzt, weil es ohne jede Einrichtung im Browser läuft.

1. CrUX Vis: Öffne cruxvis.withgoogle.com, gib deine Origin ein und wähle links „Ad metrics“. Oben kannst du zwischen Telefon und Desktop umschalten. Jede Metrik ist ein eigenes Diagramm mit dem Verlauf der letzten Wochen. Bei den Sites in meiner Auswahl reichen die Daten bis zum Fenster 05.07. bis 01.08.2026 zurück, also vor die Ankündigung. Für die Zahlen aus diesem Beitrag gehst du im Diagramm auf das Fenster 16.08. bis 12.09.2026 zurück. Der aktuelle Stand zeigt wegen des rollierenden Fensters andere Werte.
2. CrUX API und CrUX History API: Die Metrik-Schlüssel lauten experimental_ad_count, experimental_ad_density, experimental_ad_cpu und experimental_ad_kilobytes. Du brauchst einen API-Schlüssel aus der Google Cloud Console.
3. DevTools: Das Ads-Panel misst lokal auf deinem Rechner. Laut Methodik-Seite zeigt es die Werte auch auf Seiten ohne ads.txt. In CrUX landen diese Messungen aber nur, wenn die ads.txt autorisierte Verkäufer nennt.

Wie du die DevTools auch für ein komplettes Audit nutzt, habe ich im Beitrag zum Lighthouse-Audit mit Chrome DevTools MCP beschrieben.

Die erste Frage in der SEO-Welt war erwartbar: Rankt eine Seite mit weniger Werbung besser? In der Ankündigung, der zugehörigen Methodik und im Thread von Barry Pollard wird keine Nutzung dieser vier Metriken als Signal der Google-Suche beschrieben. Chrome spricht von Transparenz für Werbetreibende und Publisher. Aus meiner Sicht sollte man die Metriken deshalb nicht als Rankingfaktor behandeln, solange Google nichts anderes sagt.

Was Google zur Suche sagt, steht an anderer Stelle. In der Search-Central-Seite zur Seitennutzung gibt es eine Liste von Fragen zur Selbstprüfung. Eine davon lautet:

„Does your content avoid using an excessive amount of ads that distract from or interfere with the main content?“

Auf derselben Seite schreibt Google: „Core Web Vitals are used by our ranking systems.“ Die Anzeigen-Metriken werden dort nicht erwähnt. Die Frage nach zu viel Werbung ist eine Selbstprüfung ohne Messwert.

Der indirekte Weg ist trotzdem real. Werbeskripte brauchen CPU-Zeit und Daten. Chrome schreibt selbst, dass das die Leistung einer Seite beeinflussen kann. Ob das bei dir auf INP oder LCP durchschlägt, siehst du in den Core Web Vitals, nicht in den Anzeigen-Metriken. Wie du die drei Werte misst und verbesserst, steht in meinem Guide zu den Core Web Vitals. Warum Drittanbieter-Skripte das Rendering bremsen können, erkläre ich im Beitrag zu JavaScript-SEO und Rendering.

Für Publisher gibt es noch einen zweiten Grund, die Werte im Blick zu behalten. Sie sind öffentlich. Werbekäufer können sie für jede erfasste Site abrufen. Chrome schreibt, dass sie genau dafür gedacht sind. Was das für Preise und Buchungen heißt, lässt sich heute noch nicht sagen.

Welche Signale nach heutigem Stand wirklich ins Ranking eingehen und welche nur vermutet werden, habe ich im Beitrag zu den Google-Rankingfaktoren zusammengetragen.

Für zehn große deutsche Nachrichtenseiten liegen die Werte jetzt offen. Auf dem Handy reichte die Werbe-Datenmenge pro Seitenbesuch von 454 KB bis 6.241 KB.

Aus meiner Sicht sind die Metriken vor allem ein Werkzeug für Publisher und Werbekäufer. Für SEO sind sie ein Hinweis, wo sich ein Blick in die Core Web Vitals lohnt. Mehr nicht. Wer sie für Vergleiche nutzt, sollte die Stufen beim Ad Count kennen und im Kopf behalten, dass CPU und Datenmenge über den ganzen Besuch summiert sind. Besuche mit Chrome auf iOS fehlen ganz.

Quellen

Chrome for Developers: New ad metrics in Chrome User Experience Report vom 15.09.2026 (Ankündigung, Eigenmeldung) · CrUX ad metrics overview · Methodik · Anzeigenerkennung · Ad Weight: CPU · Tooling · CrUX-Methodik und Lizenz, alle abgerufen am 19.09.2026.

Barry Pollard (Chrome-Team): Thread auf Bluesky vom 15.09.2026. Google Search Central: Understanding page experience in Google Search results, Stand 10.12.2025. Harry Roberts: Web-Perf Wednesday 009 vom 16.09.2026.

Datenquelle: Google Chrome User Experience Report (CrUX), experimentelle Anzeigen-Metriken, abgerufen über CrUX Vis am 19.09.2026, Origin-Ebene, 75. Perzentil, Fenster 16.08. bis 12.09.2026. CrUX-Datensätze von Google stehen unter CC BY 4.0. Auswahl der Origins und Darstellung: Christian Ott. Auswahlkriterium: geschätzter organischer Google-Traffic in Deutschland laut DataForSEO, abgerufen am 19.09.2026.