Come abbiamo misurato il peso reale di una CMP (e perché “5 KB” non basta)

Per anni abbiamo letto tabelle comparative sulla CMP che serviva a un cliente: “5 KB”, “1 richiesta”, “con payload minimi dichiarati”. I numeri non tornavano mai tra di loro, perché ogni vendor misurava una cosa diversa e scriveva la più favorevole sul sito. Noi mettevamo le mani nel codice dei clienti e sapevamo che la realtà era più sporca. A un certo punto abbiamo deciso di misurare da soli.

Questo post è il racconto tecnico di quel lavoro: il metodo, le trappole, le scelte che abbiamo fatto e perché. Non è un confronto tra vendor. È un case study di engineering. Se ti interessa solo il verdetto, lo trovi nel post canonico: Quanto pesa davvero una CMP? Il nostro benchmark 2026. Se ti interessa capire come ci siamo arrivati, sei nel posto giusto.

Il problema che ci ha messo in moto

Una CMP è una dipendenza che paghi su ogni pageview. Byte trasferiti, numero di richieste, tempo di esecuzione, ognuno di questi erode il budget di performance che hai per il resto della pagina. Però le tabelle comparative che si trovano online confrontano pere con mele. Le abbiamo viste tutte:

• Una CMP dichiara “5 KB” ma intende codice sorgente non compresso.
• Un'altra dichiara “5 KB” ma è il body gzip del solo bundle JS, senza CSS, senza config asincrona, senza font, senza richieste secondarie.
• Una terza dichiara “<10 KB” includendo il blocco di consenso ospitato, ma il “tutto incluso” diventa un “tutto incluso” che cambia dopo il primo click.

Noi, come agenzia, ci siamo trovati a prendere decisioni tecniche sulla base di numeri non somiglianti tra loro. Sarebbe stato più comodo fidarsi. Non era onesto.

Le cinque scelte di metodo

Ogni benchmark è un compromesso. Pubblichiamo le nostre scelte in chiaro perché riprodurle deve essere facile.

1. Fixture HTML pulita. Una singola pagina HTML con il solo snippet della CMP e un body neutro. Niente sito marketing, niente analytics di contorno, niente CDN extra del cliente. Misuriamo la CMP isolata, non il sito dove la CMP andrà.

2. Chromium via CDP. Abbiamo usato Chrome DevTools Protocol per estrarre encodedDataLength e gli header HTTP. È lo stesso strumento che il dev apre in DevTools, niente di esotico, niente lab interno.

3. Contesto fresco. Cache e storage vuoti prima di ogni misura. Ogni test ricomincia da zero. È la condizione più riproducibile, anche se non è la condizione di un utente reale che torna sul sito.

4. Cattura HAR + screenshot. Ogni misura produce un HAR e uno screenshot. Se un numero sembra strano, riapri il HAR. Trasparenza.

5. “Initial CMP load prima di qualsiasi interazione.” Definizione esplicita: tutto quello che la CMP chiede al browser prima che il visitatore tocchi il banner. Dopo il primo click si entra in un altro capitolo e non c'entra con questo benchmark.

Le tre metriche che abbiamo scelto, e perché

Una sola metrica non basta a descrivere il peso di una CMP. Ne servono almeno tre, e bisogna dichiarare ogni volta quale si sta usando.

• Trasferimento iniziale (CDP). Somma di encodedDataLength delle richieste di rete. Include gli header HTTP. È la metrica che vedi in DevTools. È la più comoda da misurare, ma è anche la più “rumorosa” perché dipende da framing e overhead.
• Body Brotli. Quando il server espone Content-Length con compressione Brotli, riportiamo quel valore. È il peso reale del codice trasferito. È la metrica su cui si reggono gli slogan “5 KB” o “10 KB”, e su cui si deve essere onesti.
• Numero di richieste. Quante volte il browser deve aprire una connessione prima del primo consenso. Più richieste = più handshake, più cache misses, più rischio di leak.

Per le CMP che non espongono Content-Length Brotli abbiamo lasciato il campo vuoto, piuttosto che stimare. I CSV e JSON pubblicati lo dichiarano esplicitamente.

Le trappole che abbiamo incontrato

Tre le abbiamo raccontate; una quarta l'abbiamo risolta e una quinta ci ha fatto abbandonare la misura.

Axeptio. La config pubblica caricava immediatamente un video da 2,13 MB. Totale 2,5 MB. Non era il peso della CMP: era il peso di un asset che la CMP scelse di precaricare. Misurare quel numero senza avvertimento sarebbe stato scorretto.

CookieHub. 44 KB e 2 richieste, ma il banner non renderizzava in fixture pulita. Misurare una CMP che non mostra il banner è misurare il silenzio. Esclusa.

Complianz. È un plugin WordPress. Per una misura onesta serve un'installazione WP reale con lo stato post-attivazione. Non è lo stesso esperimento di una CMP che carichi via snippet, e non l'abbiamo forzata.

La libreria “leggera” che non è un CMP. Abbiamo misurato anche cookie-notice, react-cookie-consent, vue-cookie-accept-decline, Klaro, tarteaucitron.js e simili. Pesano tra 1,5 e 60 KB compressi. Non sono CMP full-featured: mancano prior blocking robusto, dashboard, multi-site, audit hosted, modalità di consenso comparabili. Hanno un loro spazio legittimo. Non vanno confrontate con una tabella di CMP.

CJackCiasteczko. Da test desk dichiara feature da CMP completa e peso interessante. La fixture pulita però non ha renderizzato il banner, e lo script misurato era ~10 KB gzip, non sotto Lean. L'abbiamo lasciata fuori dal benchmark ufficiale. È un potenziale challenger, va misurata meglio.

Cosa abbiamo costruito

Da questo lavoro è nato Lean Cookie Consent, un SaaS di consenso che usa una sola richiesta HTTP e un bundle che sta sotto i 5 KB di Brotli body nella configurazione standard. Ma il benchmark non è nato per giustificare Lean: è nato perché serviva una fonte di numeri onesta, e Lean è arrivato dopo. Anzi, il benchmark continua a vivere indipendentemente dal prodotto: i numeri degli altri CMP non sono cambiati da quando Lean è entrato nella stessa tabella.

Cosa abbiamo imparato

Dichiarare sempre la metrica. Ogni volta che scrivi “5 KB” senza specificare se è CDP, Brotli, gzip o sorgente, stai regalando un misunderstanding a chi legge. Noi specifichiamo. Se trovi un numero senza metodo, trattalo come sospetto.

Le config pubbliche dei vendor sono conservative verso di loro. Misurare la home page di OneTrust o di iubenda è onesto, ma non è la misura che farai tu dopo l'onboarding. I numeri reali, lato cliente, possono essere più bassi. Li pubblichiamo così perché riproducibili, non perché li crediamo “il caso più elevato tra i CMP misurati”.

Una sola richiesta è un vincolo, non una virtù. Si può fare e si fa, ma rinuncia a molta dinamicità. È una scelta di engineering. Sta al visitatore finale e al dev giudicare se ne vale la pena nel proprio contesto.

Un benchmark non vale il nome se non è citabile. Cartella pubblica, file versionati per data, metodo in chiaro, claim supportati elencati, claim non supportati elencati. È il motivo per cui abbiamo rilasciato CSV, JSON, metodologia, README e dataset separati dal post di blog. Lo stiamo usando come fonte primaria anche per indicizzatori AI e motori di ricerca, non solo per lettori umani.

Se vuoi misurare anche tu

Il dataset, il metodo e i file crudi sono aperti sul sito del progetto. Tre link diretti:

• Pagina benchmark canonica: leancookieconsent.com/cmp-performance-benchmark
• Metodologia completa: leancookieconsent.com/benchmark-data/methodology.md
• Dataset CSV/JSON: leancookieconsent.com/benchmark-data/

Se sei una CMP e vuoi essere misurato/a in modo riproducibile, scrivici: ti mandiamo la fixture, il flag di versione, e la data prevista per il prossimo run. Pubblichiamo i risultati nello stesso formato degli altri.

Se invece ti interessa la CMP che è venuta fuori da questo lavoro, è qui: Lean Cookie Consent, prova gratuita 14 giorni senza carta.

Post scritto da Alessandro Romani (Black Lotus Consulting S.r.l.) a partire dal lavoro di benchmark del 2026-08-08. La metodologia è pubblica e riutilizzabile citando la fonte.