Vier neue Zahlen für ein altes Ärgernis
Seit dieser Woche lässt sich im öffentlichen CrUX-Datensatz erstmals nachschlagen, wie viel eine Website ihrer eigenen Werbung schuldet – nicht geschätzt, sondern gemessen. Google hat vier experimentelle Kennzahlen in den Chrome User Experience Report aufgenommen: Ad Count zählt, wie viele Anzeigen ein typischer Nutzer gleichzeitig sieht, Ad Density beschreibt den Anteil des Viewports, den Werbung einnimmt, und die beiden Ad-Weight-Werte für Netzwerk und CPU zeigen, wie viel Datenvolumen und Rechenlast die Werbung selbst verursacht. Berichtet wird jeweils das 75. Perzentil, für einzelne Seiten und ganze Domains, sofern genug Messdaten vorliegen. Feste Richtwerte gibt es bislang nicht, die Metriken sind explizit experimentell und noch kein Bestandteil der Core Web Vitals. Verfügbar sind sie nur für Seiten mit ausreichend Traffic im CrUX-Datensatz, für einzelne URLs ebenso wie für ganze Domains.
Was ich bisher improvisieren musste
In meiner Beratung war genau diese Zahl bisher das mühsamste Detail einer jeden Performance-Analyse. Ich musste im Network-Panel der DevTools jede Anfrage einzeln nach Drittanbieter-Domain filtern, die Bytes von Hand summieren oder auf eigene Auswertetools zurückgreifen, um Werbe-Assets sauber von redaktionellem Inhalt zu trennen. Screaming Frog, mein Standardwerkzeug für Crawls, kann das bis heute gar nicht: Es erkennt Drittanbieter-Requests, aber keine Werbeklassifizierung. Jetzt bekommen die DevTools dafür einen eigenen Reiter im Application-Panel, der Werbe-Frames direkt im Viewport markiert und zusätzlich das lokale Messergebnis der CrUX-Ad-Metriken für genau diesen Seitenaufruf anzeigt. Auch im Network-Panel lässt sich pro Anfrage jetzt direkt sehen, ob sie als werbebezogen gilt, ohne dass ich vorher jede Domain von Hand nachschlagen muss.
Warum das für Core Web Vitals zählt
Bei werbelastigen Seiten sehe ich in Projekten regelmäßig externe Assets, die allein 1 MB und mehr an Datenvolumen ziehen – das ist meine eigene Überschlagsrechnung aus der Beratungspraxis, keine Zahl von Google. Auf einer durchschnittlichen Mobilverbindung reicht das, um LCP und CLS zuverlässig zu sprengen, weil nachladende Werbeframes den Viewport erst spät stabilisieren und zusätzliche Requests die Ladezeit strecken. Genau das ist in meiner Erfahrung der häufigste Grund, warum Seiten mit viel Werbung bei Core-Web-Vitals-Tests durchfallen, ließ sich bislang aber kaum sauber belegen, weil kein Tool zwischen eigenem Code und Werbelast trennte – Kunden glaubten mir die Zahl oft erst, wenn ich sie händisch vorgerechnet hatte.
Wird das zum Rankingfaktor?
Offiziell ist das noch kein Rankingsignal, und ohne Richtwerte lässt sich auch keins ableiten. Trotzdem stellt sich die Frage zwangsläufig, sobald Google eigene Kennzahlen für etwas veröffentlicht, das die Nutzererfahrung nachweislich verschlechtert – Search Engine Land verweist bereits darauf, dass die Messung langfristig auch beeinflussen könnte, wie Werbetreibende ihr Inventar bewerten. Dass Googles eigene Ad-Plattform Display & Video 360 die Initiative unterstützt, zeigt für mich zuerst ein Geschäftsinteresse an sauberem Inventar, nicht in erster Linie ein Nachhaltigkeitsprojekt. Für die Ladezeit zählt das trotzdem, unabhängig davon, ob daraus je ein offizieller Rankingfaktor wird.
Schau Dir noch heute den Ads-Reiter Deiner eigenen Seite in den DevTools an, bevor Google Dir mit einem Rankingsignal zuvorkommt. Werbelast ließ sich schon immer irgendwie schätzen – jetzt lässt sie sich nicht mehr wegdiskutieren.
Quellen: Search Engine Land: Google Chrome launches new metrics to measure ad-heavy websites · Chrome for Developers: Ads · Chrome for Developers: Ad detection