Per valutare la WordPress performance di un sito monetizzato non basta osservare quanto velocemente viene mostrato il contenuto iniziale. Slot, iframe, bidder, script e creatività pubblicitarie possono continuare a usare CPU e rete durante tutta la permanenza dell’utente sulla pagina.
Chrome ha aggiunto a CrUX quattro metriche sperimentali dedicate all’esperienza pubblicitaria: Ad Count, Ad Density, Ad Weight – CPU e Ad Weight – Network. Questi indicatori ampliano l’analisi tecnica dei siti con advertising, ma non sostituiscono i Core Web Vitals. Google non ha inoltre pubblicato soglie qualitative né annunciato che le quattro metriche siano fattori di ranking autonomi.
Di cosa parlerò in questa pagina
Che cosa cambia nell’analisi dei siti WordPress con annunci
Le nuove metriche permettono di osservare separatamente quattro aspetti dell’infrastruttura pubblicitaria:
- quanti annunci risultano visibili;
- quale porzione dello schermo occupano;
- quanto tempo di elaborazione consumano;
- quanti dati trasferiscono attraverso la rete.
Per agenzie e freelance il loro impiego più prudente è il confronto tra configurazioni diverse dello stesso sito. Possono essere utili, per esempio, per analizzare gli effetti di una modifica a un plugin pubblicitario, agli slot, ai formati, al refresh o ai bidder.
Un valore elevato, tuttavia, non consente di identificare automaticamente il componente responsabile. Per risalire a un plugin, un network o uno script specifico è necessario affiancare ai dati aggregati un audit tecnico.
Le quattro metriche CrUX dedicate agli annunci
Ad Count
Ad Count indica il numero medio di annunci visibili nel viewport. È sufficiente che un solo pixel dell’annuncio sia visibile perché questo venga conteggiato. La metrica può quindi risentire della presenza di anchor, annunci sticky, video floating e slot collocati ai margini dell’area visibile.
Ad Density
Ad Density indica la percentuale media dello schermo occupata dagli annunci. Nel calcolo rientra soltanto la porzione effettivamente visibile. Questo rende importante distinguere desktop e mobile: una configurazione accettabile su uno schermo ampio può occupare una parte rilevante del viewport di uno smartphone.
Ad Weight – CPU
Ad Weight – CPU accumula il tempo di elaborazione utilizzato da frame, script e worker pubblicitari. Non riguarda quindi soltanto l’elemento grafico mostrato nella pagina, ma anche il lavoro eseguito dai componenti associati all’advertising.
Ad Weight – Network
Ad Weight – Network accumula i dati trasferiti dalle risorse pubblicitarie. L’analisi deve considerare anche richieste, iframe e creatività avviati per slot che non vengono poi mostrati all’utente.
Come vengono raccolti e interpretati i dati
Ad Count e Ad Density vengono campionate una volta al secondo. Ad Weight – CPU e Ad Weight – Network sono invece accumulate per l’intera sessione.
La misurazione inizia quando vengono ricevuti i primi byte HTML e termina quando si verifica una delle seguenti condizioni:
- la pagina viene scaricata;
- la scheda viene chiusa;
- il browser termina.
I risultati CrUX sono riportati al 75° percentile. Non descrivono quindi una singola visita o una prova isolata eseguita dal team tecnico.
Anche la modalità con cui gli annunci vengono nascosti richiede attenzione. Gli elementi con display:none non aumentano Ad Count e Ad Density, ma gli script e le risorse collegati possono comunque consumare CPU e rete.
La durata e il comportamento della sessione possono modificare le medie. Tra i casi da considerare rientrano:
- scroll infinito;
- permanenza prolungata sulla pagina;
- navigazioni di tipo SPA;
- caricamenti o aggiornamenti degli annunci successivi alla visualizzazione iniziale.
Per questo i dati CrUX possono differire dai risultati ottenuti localmente con DevTools. I primi sono dati aggregati provenienti da esperienze reali, mentre un test locale rappresenta uno scenario specifico. Una singola rilevazione non deve essere trattata come sintesi dell’esperienza complessiva degli utenti.
Checklist WordPress: slot, script e layout da verificare
1. Creare baseline separate
Prima di modificare il sito, è utile organizzare una baseline per:
- mobile e desktop;
- template e tipologia di pagina;
- pagine brevi e contenuti lunghi;
- pagine con quantità e formati pubblicitari differenti.
Separare gli scenari evita che una media generale nasconda criticità presenti soltanto su alcuni layout.
2. Mappare i formati visibili
L’audit dovrebbe censire almeno gli annunci above the fold, sticky, anchor, overlay, interstitial, video floating e gli inserimenti automatici tra i paragrafi. Su mobile è necessario verificare quanto spazio occupino realmente e se più formati possano essere presenti contemporaneamente.
3. Cercare slot duplicati
Una duplicazione può aumentare contemporaneamente conteggio, consumo di CPU, traffico di rete e rischio di layout shift. Le origini da controllare comprendono:
- tema e template;
- page builder;
- shortcode e hook;
- plugin pubblicitari;
- implementazioni tramite Google Tag Manager.
La verifica deve riguardare sia gli elementi mostrati sia gli slot inizializzati senza diventare visibili.
4. Analizzare il lavoro delle terze parti
Network pubblicitari, bidder, iframe, worker e creatività possono continuare a incidere sulla pagina dopo il caricamento iniziale. Cache, minificazione e CDN possono intervenire sulle risorse del sito, ma non neutralizzano automaticamente il costo dei provider pubblicitari di terze parti.
5. Gestire gli slot fuori viewport
Per gli annunci collocati fuori dall’area visibile si può valutare il lazy loading. È inoltre opportuno riservare con il CSS dimensioni o proporzioni coerenti per gli slot, verificando poi il comportamento insieme al CLS.
6. Incrociare le metriche pubblicitarie con i Core Web Vitals
Le quattro metriche non sostituiscono CLS, INP e LCP. Devono essere lette insieme a questi indicatori per capire se l’infrastruttura pubblicitaria coincide con problemi di stabilità del layout, reattività o caricamento del contenuto principale.
Consenso, scenari di test e requisito ads.txt
Un audit attendibile deve includere i diversi stati del consenso e della pagina. La checklist può comprendere:
- consenso accettato e rifiutato;
- CMP aperta;
- utenti nuovi e utenti di ritorno;
- mobile e desktop;
- pagine brevi e lunghe.
Questi scenari aiutano a controllare se script e richieste vengono attivati in modo diverso e se la presenza della CMP modifica l’area disponibile nel viewport.
È inoltre necessario verificare che il file /ads.txt sia raggiungibile, non sia bloccato e contenga almeno un venditore autorizzato reale. I dati CrUX aggregati relativi a queste metriche vengono pubblicati soltanto per i siti con un file ads.txt che contiene almeno un venditore autorizzato.
Come impostare un confronto prima e dopo
In assenza di soglie ufficiali, il confronto storico è uno degli impieghi più concreti delle metriche. Il processo può essere organizzato in cinque passaggi:
- registrare la situazione iniziale per dispositivo, template e tipologia di pagina;
- individuare una sola variabile da modificare;
- intervenire su plugin, slot, refresh, bidder o formato selezionato;
- osservare almeno un intero periodo CrUX prima di confrontare i dati;
- valutare insieme metriche tecniche, ricavi pubblicitari ed engagement.
Cambiare più elementi contemporaneamente rende più difficile attribuire l’eventuale variazione a una causa precisa. Allo stesso modo, ridurre indiscriminatamente gli annunci non garantisce da solo il miglior risultato complessivo: l’analisi deve tenere conto anche della monetizzazione e del comportamento degli utenti.
Che cosa si può concludere, e che cosa no
Le quattro metriche sono sperimentali e potrebbero cambiare. Al momento non sono disponibili soglie ufficiali per classificare i risultati come “buoni”, “da migliorare” o “scarsi”.
È corretto considerarle indicatori utili per comprendere il peso dell’infrastruttura pubblicitaria sull’esperienza percepita e per confrontare interventi tecnici. Non è invece corretto presentarle come nuovi fattori di ranking confermati o attribuire a Google requisiti operativi che non ha annunciato.
I Core Web Vitals rimangono un piano di analisi distinto. L’eventuale utilizzo futuro delle nuove metriche nel ranking non deve essere trattato come un annuncio di Google.
Audit tecnico per siti WordPress con advertising
Un audit mirato può collegare slot, script, CPU e traffico di rete ai Core Web Vitals, distinguendo i problemi del sito da quelli legati alle integrazioni pubblicitarie. L’obiettivo è costruire confronti verificabili prima e dopo ogni intervento, senza attribuire responsabilità sulla base di un solo dato.
AI Modified
Fonti
- Google Adds New Ad Experience Metrics To CrUX Report via @sejournal, @martinibuster (www.searchenginejournal.com)
- CrUX ad metrics measurement methodology | Ads | Chrome for Developers (developer.chrome.com)
- Understanding Google Page Experience | Google Search Central | Documentation | Google for Developers (developers.google.com)
Domande frequenti
No. Ad Count, Ad Density, Ad Weight – CPU e Ad Weight – Network ampliano l’analisi dell’esperienza pubblicitaria, ma non sostituiscono CLS, INP e LCP.
Ad Count misura il numero medio di annunci visibili nel viewport e conteggia un annuncio anche quando è visibile un solo pixel. Ad Density misura la percentuale media dello schermo occupata dagli annunci, considerando soltanto la porzione effettivamente visibile.
Ad Weight – CPU accumula il tempo di elaborazione utilizzato da frame, script e worker pubblicitari. Ad Weight – Network accumula i dati trasferiti dalle risorse pubblicitarie. Entrambe considerano l’intera sessione misurata.
CrUX presenta dati aggregati al 75° percentile, mentre DevTools fotografa una specifica esecuzione locale. Dispositivo, durata della sessione, scroll, stato del consenso e comportamento della pagina possono produrre risultati differenti.
I dati CrUX aggregati per le metriche pubblicitarie vengono pubblicati soltanto per siti con un file ads.txt contenente almeno un venditore autorizzato. Il file deve quindi essere raggiungibile e non bloccato.
Google non ha annunciato che siano fattori di ranking autonomi. Non esistono neppure soglie qualitative ufficiali. Qualsiasi possibile uso futuro non deve essere presentato come un fatto confermato.
