Esclusiva Matrice Digitale: bug Cloudflare può trasformare un CLS di 0,003 in 1

🔎 Key findings

• Matrice Digitale ha riprodotto nel beacon Cloudflare 2026.8.4 una trasformazione che converte qualsiasi CLS positivo fino a 1 nell’intero 1.
• Il problema è nel payload WebVitalsV2: lo stesso Math.ceil applicato alle metriche temporali viene utilizzato anche sul CLS, che è frazionario.
• SEO e webmaster non devono modificare CSS, CMP o advertising per inseguire il valore 1 senza prima confrontarlo con misurazioni indipendenti.

Matrice Digitale ha individuato e riprodotto un difetto nel JavaScript pubblico utilizzato da Cloudflare Web Analytics per preparare la telemetria dei Core Web Vitals: il valore del Cumulative Layout Shift viene arrotondato per eccesso all’intero prima dell’invio del payload. La conseguenza è radicale: un CLS reale di 0,003 può diventare 1, esattamente come 0,05, 0,1, 0,25 o 0,999. La redazione ha successivamente segnalato il problema a Cloudflare, fornendo versione del beacon, blocco di codice e casi di riproduzione. La scoperta nasce dall’attività tecnica sul sito della testata, già raccontata nella case history sull’ottimizzazione autonoma di MatriceDigitale.it tra Cloudflare, CSS, server e analisi dei log, ed è particolarmente rilevante per SEO, webmaster e sviluppatori che utilizzano la dashboard Cloudflare per diagnosticare la stabilità visiva delle pagine.

Il bug è nel codice che prepara il payload WebVitalsV2

La verifica condotta il 30 agosto 2026 intorno alle 17:49 CEST ha riguardato esclusivamente la lettura del sito, del JavaScript pubblico referenziato nelle pagine e l’esecuzione locale isolata del blocco responsabile della trasformazione. Nessuna modifica è stata effettuata a WordPress, tema Astra, CSS, CMP, AdSense o configurazione Cloudflare. Sia la homepage di Matrice Digitale sia un articolo pubblicato il 30 agosto referenziavano lo stesso beacon.min.js, identificato dalla versione interna 2026.8.4. La catena osservata è lineare: il beacon include cls nell’array delle metriche ["lcp","cls","fcp","ttfb","inp"]; il callback conserva il valore fornito dalla metrica; durante la costruzione dell’oggetto destinato al percorso WebVitalsV2, però, viene applicato Math.ceil() al campo value di tutte le metriche presenti. La documentazione ufficiale di Cloudflare Web Analytics afferma invece esplicitamente che LCP e INP sono valori temporali, mentre CLS è uno score, distinzione fondamentale anche quando si analizzano discrepanze tra strumenti di misurazione come quelle affrontate nell’inchiesta sulla dipendenza di editori e webmaster dalle dashboard di Google Search Console.

Il blocco rilevato nel beacon è il seguente:

d.forEach(t=>{
  P[t]&&void 0!==P[t].value&&(
    n[t]=P[t],
    n[t]&&n[t].value&&(
      n[t].value=Math.ceil(n[t].value)
    )
  )
})

Per il CLS Math.ceil distrugge l’informazione utile

Applicare Math.ceil() a valori espressi in millisecondi può essere una scelta di normalizzazione discutibile ma facilmente comprensibile: 209,2 millisecondi diventano 210. Applicare la stessa operazione al CLS cambia invece completamente il significato della metrica, perché il Cumulative Layout Shift è deliberatamente costruito come valore frazionario adimensionale. Google considera buono un CLS minore o uguale a 0,1, da migliorare un valore superiore a 0,1 e fino a 0,25, e insufficiente un valore superiore a 0,25; la stessa documentazione Cloudflare utilizza queste soglie. Di conseguenza, Math.ceil(0.003) restituisce 1, ma restituiscono 1 anche Math.ceil(0.1), Math.ceil(0.1001), Math.ceil(0.25) e Math.ceil(0.999). Il beacon perde quindi la capacità di distinguere praticamente tutto l’intervallo compreso fra un CLS appena superiore a zero e un CLS estremamente grave. È un problema concettualmente diverso dalle normali discrepanze tra strumenti SEO: nell’analisi sul monopolio invisibile della misurazione Google Matrice Digitale aveva già sottolineato come una dashboard possa condizionare decisioni operative, ma qui il problema non è l’opacità dell’algoritmo: la trasformazione è leggibile direttamente nel JavaScript pubblico. Le soglie ufficiali di web.dev confermano che 0,1 e 0,25 sono i confini semantici della metrica.

Leggi anche: Case History MatriceDigitale.it: addio ai WEB e SEO specialist

Dodici test mostrano deterministicamente come i decimali scompaiono

La redazione ha estratto soltanto il blocco di trasformazione e lo ha eseguito localmente con dodici valori di controllo, senza caricare l’intero script remoto e senza generare traffico verso Cloudflare. Il risultato è deterministico: 0 resta 0; 0.0001, 0.003, 0.01, 0.05, 0.1, 0.1001, 0.25, 0.251, 0.999 e 1 diventano tutti 1; 1.001 diventa 2. Il punto più importante per chi gestisce performance e SEO è che il difetto non si limita ad alterare leggermente la precisione: cancella completamente le fasce Good e Needs Improvement per ogni sessione con CLS positivo, almeno nel valore preparato dal percorso analizzato. Un CLS ottimo di 0,003 e un CLS realmente pessimo di 0,999 diventano indistinguibili nel payload trasformato. È proprio il tipo di anomalia che può portare un webmaster a cercare inesistenti errori di layout, intervenendo magari su cache, tema, pubblicità o JavaScript quando invece il problema è nella telemetria; il rischio di prendere decisioni infrastrutturali sulla base di indicatori non correttamente interpretati è già emerso nel lavoro di Matrice Digitale su cache Cloudflare, CSS e diagnosi server effettuate direttamente sui dati tecnici.

Perché il pattern P50, P75, P90 e P99 tutti a 1 diventa spiegabile

La scoperta è partita da una situazione anomala nella dashboard: percentili CLS concentrati sul valore 1 e assenza della normale distribuzione intermedia. Prima di trovare l’arrotondamento, una simile rappresentazione poteva far pensare a spostamenti giganteschi prodotti da annunci AdSense, Funding Choices, CSS o caricamenti tardivi di componenti. Nell’ispezione responsive a 360 × 800 pixel erano effettivamente presenti annunci e un elemento adsbygoogle-noablate da circa 345 × 110 pixel, mentre erano stati osservati dettagli di layout come uno spostamento verticale Funding Choices di appena otto pixel; questi elementi potevano contribuire a un CLS reale, ma non erano sufficienti per ricostruire il valore aggregato della sessione. La trasformazione Math.ceil() fornisce invece una spiegazione concreta del perché anche un piccolo CLS maggiore di zero possa comparire come 1, senza postulare spostamenti enormi della pagina. È una distinzione essenziale per gli editori che vivono contemporaneamente di performance e advertising, un equilibrio diventato ancora più delicato nell’ecosistema in cui Google controlla ricerca, AdSense, Analytics, Discover e parte degli strumenti utilizzati per misurare e monetizzare il pubblico. Google ricorda inoltre che elementi pubblicitari e widget di terze parti che cambiano dimensione sono cause reali di layout shift: proprio per questo un bug nella telemetria rischia di mandare il debugging nella direzione sbagliata.

Cloudflare stessa documenta il CLS come numero decimale

C’è un elemento ulteriore che rende il comportamento osservato difficile da conciliare con la semantica documentata del prodotto. Nella documentazione del RUM beacon, Cloudflare mostra esplicitamente un esempio nel quale il campo CLS vale 0.001. Nella documentazione Web Analytics aggiornata il 24 agosto 2026, Cloudflare specifica inoltre che il campo Value è espresso in millisecondi per LCP e INP ma come score per CLS. Non è quindi una metrica che, per specifica del prodotto, debba necessariamente essere rappresentata come intero. La stessa pagina spiega che Web Analytics assegna automaticamente le classi Good, Needs Improvement e Poor secondo le soglie Google. Questo rende la perdita dei decimali particolarmente rilevante per chi utilizza il pannello come strumento di diagnosi invece di affiancarlo a CrUX, Search Console o strumenti RUM indipendenti. La differenza tra dato grezzo e rappresentazione del provider ricorda il principio già affrontato da Matrice Digitale nell’analisi dei log rispetto ai dati di Search Console: strumenti differenti osservano livelli differenti e non devono essere considerati intercambiabili. La documentazione RUM di Cloudflare usa proprio 0.001 come valore CLS esemplificativo.

Il beacon osservato dichiara la versione 2026.8.4

Il JavaScript verificato sulle due pagine di Matrice Digitale era https://static.cloudflareinsights.com/beacon.min.js/v3d52b47920f24c319d37e2661827c42b1787588026925 e dichiarava internamente versions:{js:"2026.8.4"}. La snapshot testuale utilizzata durante l’analisi è stata conservata con SHA-256 D617E1921C83E1628DFBFE4D48B1012B887AB6A3AFA55266A02D983BFA4F606B. Una rilevazione pubblica indipendente del traffico del beacon effettuata negli stessi giorni mostra anch’essa payload Cloudflare che dichiarano la versione 2026.8.4, elemento che conferma l’esistenza della build nel periodo analizzato, anche se non sostituisce la snapshot conservata dalla redazione. Il changelog ufficiale di Cloudflare Web Analytics registra il 20 agosto 2026 l’aggiornamento della libreria Google web-vitals alla versione 6.1.0 e nuove capacità per le soft navigation, ma non menziona il Math.ceil() sul CLS e non consente di stabilire quando quella specifica trasformazione sia stata introdotta. Questa prudenza è importante: come già dimostrato nell’analisi degli ecosistemi Cloudflare dove configurazione, proxy e strumenti infrastrutturali possono produrre effetti molto diversi a seconda del livello osservato, versione corrente, data di introduzione del bug e periodo dei dati alterati sono tre questioni differenti.

L’aggiornamento di web-vitals 6.1.0 non prova l’origine del problema

Sarebbe quindi scorretto attribuire automaticamente il bug all’aggiornamento del 20 agosto. La libreria ufficiale web-vitals di Google mantiene correttamente per il CLS le soglie frazionarie 0.1 e 0.25, e il codice pubblico della funzione onCLS tratta la metrica come valore numerico decimale. Il problema riprodotto da Matrice Digitale emerge invece nella fase successiva del beacon Cloudflare, quando l’oggetto già popolato viene trasformato prima dell’invio. In altre parole, la diagnosi disponibile indica che il valore viene ricevuto con i decimali e successivamente normalizzato mediante Math.ceil() insieme alle altre metriche. Questo dettaglio è essenziale per gli sviluppatori perché separa un eventuale errore nella libreria di raccolta Google da un errore nella pipeline che prepara la telemetria Cloudflare. Nel lavoro quotidiano dei webmaster questa distinzione è paragonabile a quella affrontata quando un problema di cache o proxy viene erroneamente attribuito all’applicazione WordPress sottostante: diagnosticare lo strato sbagliato porta quasi sempre alla correzione sbagliata. Il codice pubblico di Google web-vitals continua infatti a definire CLSThresholds come [0.1, 0.25].

Cosa questa analisi dimostra e cosa non può dimostrare

La verifica consente di affermare che il blocco di trasformazione presente nel beacon osservato perde deterministicamente i decimali del CLS quando viene eseguito sui valori testati. Consente inoltre di affermare che homepage e articolo analizzati referenziavano la stessa build e che il comportamento matematico 0.003 → 1 è riproducibile in isolamento. Non consente invece di recuperare il CLS originario delle visite già aggregate nel report, stabilire quale fosse la reale distribuzione dei valori degli utenti, dimostrare che tutte le visite presentassero CLS buoni o determinare senza accesso ai sistemi Cloudflare se esistano correzioni server-side successive all’invio. Non è stato nemmeno acquisito nella stessa sessione un confronto completo CLS grezzo rilevato dalla Performance API → payload effettivamente trasmesso → valore mostrato in dashboard. Questa separazione tra ciò che è provato e ciò che resta da verificare è fondamentale anche nel lavoro SEO: come Matrice Digitale ha evidenziato nella critica alle diagnosi automatiche fondate esclusivamente su dashboard e indicatori esterni, una correlazione grafica non può sostituire la verifica del percorso tecnico del dato.

SEO e webmaster non devono correggere il sito per inseguire un CLS 1

La conseguenza operativa è forse la parte più importante dell’esclusiva. Un webmaster che vede P50, P75, P90 e P99 inchiodati a 1 potrebbe essere portato a cercare immediatamente colpevoli nel template, negli spazi pubblicitari, nella CMP, nei font o negli script di terze parti. Sono tutti elementi che possono effettivamente produrre CLS e devono continuare a essere analizzati, ma il valore Cloudflare osservato non dovrebbe essere utilizzato da solo come prova della gravità dello spostamento finché il comportamento del beacon non sarà chiarito. Correggere artificialmente altezze, eliminare annunci, modificare Astra o alterare Funding Choices per compensare un valore trasformato nella telemetria rischierebbe di peggiorare il sito senza risolvere alcun problema reale. La stessa prudenza vale quando publisher e SEO prendono decisioni economiche sulla base di dati di advertising e traffico, settore nel quale Matrice Digitale ha già documentato come sistemi di tracking e monetizzazione possano restituire una rappresentazione diversa dal comportamento reale dell’utente. Per la misura del CLS reale restano utili strumenti indipendenti come CrUX, Search Console, PageSpeed Insights, DevTools e una propria implementazione RUM della libreria web-vitals, tenendo conto delle differenze inevitabili fra lab e field data.

Il problema interessa soprattutto chi usa Cloudflare come strumento di debugging

La gravità pratica non deriva soltanto dal numero mostrato nella dashboard, ma dalla funzione che Cloudflare assegna al proprio Vitals Explorer. La documentazione presenta la sezione Core Web Vitals come uno strumento capace di individuare gli elementi che incidono negativamente sull’esperienza, filtrare per URL, browser, sistema operativo, Paese ed elemento e confrontare P50, P75, P90 e P99. Se il campo CLS utilizzato nella pipeline perde i decimali prima della successiva elaborazione, il rischio è che una funzione nata per discriminare problemi sottili di stabilità visiva riceva in ingresso una metrica drasticamente impoverita. Per un sito editoriale con pubblicità, consenso, immagini, font e componenti dinamici questo può spostare ore di debugging verso elementi che non giustificano il valore mostrato. È lo stesso tema di fondo presente nell’inchiesta sulla Search Console ferma durante gli update Google: quando uno strumento è utilizzato come strumentazione di bordo da professionisti e aziende, la qualità della telemetria diventa parte della qualità del servizio stesso. Cloudflare descrive ufficialmente il proprio Debug View come uno strumento per individuare gli elementi con impatto negativo sui Core Web Vitals.

Continua con:

• Google, Search Console ferma e il monopolio invisibile che decide la vita su Internet
• Bot AI superano il traffico umano: Cloudflare, Altman e Nadella lanciano l’allarme

Matrice Digitale segnala il difetto a Cloudflare e attende chiarimenti

Dopo avere isolato e riprodotto il comportamento, la redazione di Matrice Digitale ha segnalato tecnicamente il caso a Cloudflare, indicando URL e versione del beacon, blocco contenente Math.ceil(), esempi come 0,003 → 1 e 0,1 → 1 e il pattern osservato nei report. I punti che richiedono una risposta sono quattro: se il CLS debba essere escluso dall’arrotondamento all’intero; quali build e quale intervallo temporale siano eventualmente interessati; se i valori precedenti alla trasformazione restino recuperabili a valle nei sistemi Cloudflare; e come sia possibile distinguere nella dashboard dati raccolti prima e dopo un’eventuale correzione. Fino a quel momento la posizione tecnica più prudente per SEO e developer è semplice: non ignorare i problemi reali di layout, ma non modificare un sito sano per compensare una trasformazione osservata nel beacon di terze parti. È il metodo già applicato dalla testata nella gestione diretta di Cloudflare, server, CSS, cache e log che ha permesso di separare sintomi apparenti da cause realmente misurabili. Il bug individuato non dimostra che il CLS reale degli utenti di Matrice Digitale fosse buono, ma dimostra qualcosa di altrettanto importante per chi lavora sul Web: un valore visualizzato da una piattaforma non deve mai diventare una verità tecnica prima di avere verificato come quel valore viene costruito.