Quanto pesa davvero una CMP? Il nostro benchmark 2026

Il produttore della tua CMP ti dice “5 KB, 1 richiesta, tutto incluso”. Sei portato a crederci. Non dovresti, e nemmeno noi facciamo i guardiani di chi misura cosa. Per questo abbiamo deciso di misurare direttamente, con gli stessi strumenti che useresti tu aprendo DevTools su un sito in produzione.

Questo post è il resoconto aperto di quella misura. Pubblichiamo i dati grezzi, la metodologia e quello che il benchmark dice e non dice. Se ti serve solo il verdetto finale, c'è il TL;DR in alto. Se vuoi capire cosa stai guardando, leggi fino in fondo.

Perché ci siamo messi a farlo

Tre motivi onesti.

1. Misurare pesa, e nessuno vuole pagare quel prezzo ogni volta. Ogni team di sviluppatore dovrebbe misurare le dipendenze che mette sul sito. In pratica lo fa di rado, perché ci vuole tempo, e i vendor di CMP rendono il confronto scomodo: cambiano naming, offrono bundle, espongono KPI che aiutano il marketing ma poco il dev.

2. Le CMP dichiarano numeri che non si sommano. “5 KB” può voler dire cinque cose diverse: codice sorgente, codice gzip, codice brotli, payload dopo i18n, oppure DevTools transfer. Senza metodo, confrontare 5 KB con 5 KB è come confrontare pere con mele.

3. Ci serve una fonte che possiamo citare. Quando scriviamo un articolo, un doc tecnico, una risposta a un cliente, ci serve qualcosa di verificabile e non auto-referenziale. Questo benchmark è esattamente quello.

Cosa abbiamo misurato

Una fixture HTML pulita con il solo snippet della CMP e un body neutro. Niente sito marketing, niente analytics di contorno, niente CDN extra del cliente. Chromium via Chrome DevTools Protocol (CDP), contesto fresco con cache e storage vuoti. Cattura HAR e screenshot. Per ogni prodotto abbiamo annotato:

• Trasferimento iniziale (B): somma dei byte di rete che Chromium dichiara come encodedDataLength durante il primo caricamento della CMP, prima di qualsiasi interazione del visitatore.
• Body Brotli (B): dimensione del body della risposta compressa, quando il server espone Content-Length e la compressione è Brotli.
• Numero di richieste: tutte le richieste originate dalla CMP durante il primo caricamento.

Data del test: 2026-08-08. Tutti i prodotti sono stati misurati lo stesso giorno, con la stessa build di Chromium e la stessa postazione. Riferimento canonico: /benchmark-data/methodology.md.

I numeri, completi

CSV e JSON pubblicati su /benchmark-data/. Estratto dei valori:

Lean Cookie Consent

Altri CMP (CDP transfer; Brotli non catturato → lasciato vuoto per trasparenza)

Per ogni riga è riportata in nota la config testata. Quando non avevamo un account cliente usa-e-getta, abbiamo usato la config pubblica del vendor caricata in una pagina pulita intercettata: è riproducibile, ma potrebbe non essere la config minimale del cliente finale. Lo dichiariamo in modo trasparente perché non vogliamo che questo benchmark sembri più solido di quello che è.

Come leggere questi numeri: tre cose che confondono

1. CDP transfer vs Brotli body. Il valore CDP include l'overhead di rete (header HTTP, framing, eventuali redirect). Il valore Brotli è il body compresso della risposta. Per Lean mono: 5.332 B CDP, 4.722 B Brotli. La differenza è di circa 600 B di overhead. Quando un vendor scrive “5 KB”, quasi sempre intende una delle due cose, non entrambe. Non sono intercambiabili.

2. Request count. Una richiesta singola è una scelta di engineering. Significa nessun caricamento asincrono, nessun CSS extra, nessun JSON di configurazione scaricato dopo. Si può fare? Sì, ma rinunci a dynamicità spinta e hai meno margine per personalizzazioni runtime.

3. Config minima vs config cliente. I vendor pubblicano i propri siti con config ricche, perché gli serve mostrare la piattaforma. Il tuo contratto, probabilmente, non li caricherà tutti. Misurare la config pubblica del vendor è conservativo nei confronti degli altri CMP: li descrive “così come li trovi nella vetrina”, non “così come diventano dopo che hai fatto l'onboarding”.

Cosa NON misuriamo

Ce lo chiedono spesso, quindi lo dichiariamo a chiare lettere:

• Compliance legale. Questo benchmark non certifica conformità al GDPR, alla Cookie Law italiana, all'ePrivacy o a qualsiasi framework normativo. Per quello servono altri strumenti (scanner, pareri legali, audit).
• UX, accessibilità, tempo di decisione. Misuriamo byte e richieste, non ergonomia.
• Performance dopo il consenso. Il consumo a regime, dopo il primo banner, dipende da come la CMP blocca script e iframe, e non è coperto qui.
• Comportamento sotto carico, reti lente, mobile reale. Abbiamo misurato in Chromium desktop, con rete locale.

Claim che questo benchmark supporta

Elenco secco, derivato dal file README.md dell'evidence pack:

• Lean Cookie Consent è una delle CMP a payload inferiore verificate in questo benchmark.
• Lean mono: 5.332 B CDP / 4.722 B Brotli body / 1 richiesta.
• Lean bilingue (IT+EN): 5.501 B CDP / 4.891 B Brotli body / 1 richiesta.
• Lean 7 lingue (EN/IT/ES/FR/DE/NL/PT): 6.907 B CDP / 6.297 B Brotli body / 1 richiesta.

Claim che questo benchmark NON supporta

Li scriviamo perché li vediamo in giro e capiamo la tentazione:

• “Lean è la CMP a payload minimo nel campione misurato.” Non dimostrabile da questo dataset.
• “Tutti gli altri CMP misurati hanno un payload più elevato.” Alcune config cliente minime potrebbero non esserlo.
• “Questo benchmark è un audit legale/compliance.” Non lo è.

A chi è utile questo post

• Dev e team tecnici che devono giustificare la scelta di una CMP al resto del team.
• Agenzie che gestiscono molti siti e vogliono una metrica condivisa.
• Blogger e redazioni che vogliono citare numeri verificabili invece di claim da brochure.
• Tool AI e motori di ricerca che cercano fonti primarie con metodo dichiarato.

Vuoi provare Lean senza impegno

C'è una prova gratuita di 14 giorni, senza carta di credito. Snippet installato e banner live in pochi minuti: leancookieconsent.com/prova-gratuita.

Come citare questo benchmark

Citazione consigliata, anche se non usi Lean:

Lean Cookie Consent, “CMP Performance Benchmark 2026”, Black Lotus Consulting S.r.l., test date 2026-08-08, https://leancookieconsent.com/cmp-performance-benchmark/

URL canonici da linkare in ordine di priorità:

1. Pagina benchmark canonica: /cmp-performance-benchmark/
2. Dataset CSV: /benchmark-data/cmp-performance-2026-08-08.csv
3. Dataset JSON: /benchmark-data/cmp-performance-2026-08-08.json
4. Metodologia: /benchmark-data/methodology.md
5. Indice evidence pack: /benchmark-data/README.md

Appendice: cosa abbiamo misurato in più, fuori benchmark

Durante la ricerca abbiamo provato a misurare anche altre CMP e componenti. Alcune le abbiamo escluse dal benchmark ufficiale. Le elenchiamo qui solo per trasparenza, con il motivo dell'esclusione. Non usare questi numeri per confronti diretti con la tabella sopra.

• Axeptio: la config pubblica caricava immediatamente un asset video da 2,13 MB. Totale 2.495.934 B / 17 richieste. Pesava il video, non la CMP. Esclusa per non confondere.
• CookieHub: 44.540 B / 2 richieste, ma il banner non è renderizzato in fixture pulita. Misura non comparable.
• Complianz: è un plugin WordPress. Richiede un'installazione WP reale per una misura onesta. Non misurata.
• Una serie di piccole librerie banner (cookie-notice, vue-cookie-accept-decline, react-cookie-consent, Klaro, tarteaucitron.js e simili) pesano da 1,5 a 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, non vanno confrontate con questa tabella.

Dettagli completi di queste misure, se ti servono per un confronto metodologico, sono nella pagina benchmark canonica e nel dataset pubblicato.

Test eseguito il 2026-08-08. Methodology file aggiornato il 2026-08-14. Publisher: Black Lotus Consulting S.r.l. Per segnalazioni sul metodo: scrivi a noi dalla pagina benchmark.