La pagina è caricata, il visitatore non fa più nulla, ma alcune richieste HTTP continuano a partire. Un'indagine BitHub su 124 eCommerce distingue il traffico risparmiato dalla cache dal lavoro che può proseguire dopo il caricamento.
Osservatorio BitHub · Ricerca tecnica esplorativa · 27 ottobre 2026
Aprire un eCommerce non significa semplicemente scaricare una pagina. Immagini, JavaScript, applicazioni di marketing, sistemi di misurazione e servizi remoti partecipano a una sequenza che può continuare anche quando l'utente smette di interagire. La domanda, però, va posta con precisione: quali attività proseguono davvero, quanto sono frequenti e in quali condizioni il browser le sospende?
Per rispondere abbiamo riunito due livelli di osservazione. Il primo è una campagna su 124 negozi online operanti in Italia: 253 indirizzi selezionati, 2.087 registrazioni complessive tra rete, CPU, mobile e test sperimentali sugli script. Il secondo è un test mirato sull'inattività di 15 siti, monitorando le richieste di rete per cinque minuti con schede visibili e nascoste. Non sono misure di energia elettrica, né un campione statistico rappresentativo del commercio elettronico italiano. Sono dati riproducibili su ciò che Chrome ha effettivamente osservato.
La cache alleggerisce la rete. Non cancella la pagina
Il primo risultato è netto. Su 175 URL appartenenti a 97 negozi, per le quali esiste almeno una misurazione utilizzabile in entrambe le condizioni, la mediana dei dati trasferiti è 4,82 MB nella visita cold e 0,153 MB nella visita warm. Calcolando la riduzione su ogni singola URL e prendendone la mediana, otteniamo −96,8%. I megabyte sono decimali e rappresentano byte trasferiti osservati dallo strumento, non dimensioni dei file installati sul server.
Serve una cautela importante. Nella versione utilizzata, alcune prove dichiarate cold potevano comunque essere servite da service worker; questo altera il significato sperimentale della "cache fredda". Escludendo tutte le URL sulle quali è stato osservato un intervento del service worker, restano 147 URL di 81 negozi: la mediana è 4,85 MB cold, 0,156 MB warm, con una riduzione mediana del 96,7%. Neppure quest'ultimo filtro prova l'assenza assoluta di ogni forma di caching, ma mostra che il risultato generale non dipende soltanto dai casi più evidenti.
Il risparmio è reale per la rete del browser in queste condizioni di prova, non automaticamente per la CPU o per l'energia. Anche quando gli script sono in cache possono dover essere inizializzati ed eseguiti; il browser può continuare a costruire il DOM, calcolare layout, mostrare componenti dinamici e avviare richieste applicative. I contatori CPU di questa campagna presentavano problemi metodologici e sono stati esclusi dalle conclusioni. Non possiamo quindi scrivere che la cache riduca il consumo energetico del 96,8%.
JavaScript e pagine interne: due punti spesso sottovalutati
Fra 177 URL cold con rilevazioni utilizzabili, scegliendo una prova rappresentativa per URL, gli script costituiscono il 44,2% dei byte attribuiti alle risorse, contro il 34,9% delle immagini. È un risultato specifico del campione e diverso da quello della rilevazione BitHub precedente. Non significa che "JavaScript consuma il 44% dell'energia": sono grandezze differenti. Suggerisce però che concentrarsi esclusivamente su fotografie e banner può lasciare intatta una parte considerevole del carico di rete.
L'homepage è altrettanto poco rappresentativa dell'intero negozio. Tra 19 eCommerce con homepage, categoria e scheda prodotto tutte confrontabili, sei hanno almeno una pagina interna che trasferisce più della homepage. Per esempio, nelle URL misurate di un negozio di articoli sportivi il prodotto raggiunge 5,39 MB, contro 4,63 MB della homepage; in una catena di abbigliamento la categoria analizzata trasferisce 19,36 MB, contro 18,39 MB della pagina iniziale. Sono confronti tra pagine precise, non giudizi sulla qualità complessiva dei negozi.
Un terzo test esplorativo ha confrontato, su 11 siti, il caricamento ordinario con una variante nella quale alcuni servizi esterni venivano bloccati. In tutte le 11 coppie sono diminuiti i byte scaricati; la diminuzione mediana è 16,7%, ma con differenze molto ampie tra negozi. Ogni variante è stata misurata una sola volta e in ordine fisso: il risultato segnala un possibile margine tecnico, non dimostra un effetto causale isolato né un risparmio di CO₂.
Cinque minuti senza un clic: cosa succede davvero
Per verificare se le comunicazioni proseguono dopo il caricamento abbiamo sviluppato un protocollo di osservazione specifico in Chrome. Dopo 60 secondi di assestamento, ogni pagina viene lasciata senza interazioni per 300 secondi, con registrazioni ogni 30 secondi. Contiamo le richieste HTTP iniziate, il metodo, l'host di destinazione e alcuni eventi di rete; non conserviamo cookie, corpi delle richieste o identificativi personali.
La campagna parallela ha coinvolto 15 eCommerce di 12 settori, con due ripetizioni previste e due condizioni per sito: scheda visibile e scheda nascosta. Erano dunque attese 60 sessioni. Il motore ne ha concluse 39, ciascuna con dieci intervalli: 390 osservazioni di 30 secondi. L'export conteneva inoltre 30 intervalli ereditati da una campagna precedente, tenuti separati dai conteggi qui presentati.
Il limite più importante riguarda la visibilità reale: durante la prima ripetizione Chrome ha segnalato hidden per tutte le schede che avrebbero dovuto essere visibili. Quelle sessioni non sono state considerate un confronto valido. Nella seconda ripetizione sono risultate complete e correttamente classificate entrambe le condizioni per 10 negozi. È su questi dieci casi, non su tutti i quindici, che basiamo il confronto seguente.
Nei dieci confronti validi della seconda ripetizione, durante i cinque minuti senza interazioni, abbiamo osservato 138 richieste HTTP con scheda visibile e 23 con scheda nascosta. Nove negozi su dieci hanno generato almeno una richiesta in condizione visibile, tre su dieci in condizione nascosta. Nella seconda metà dei cinque minuti si osservano ancora 65 richieste complessive nelle schede visibili e 11 nelle schede nascoste, queste ultime concentrate in due negozi. Il dato descrive questa prova, non una frequenza media dei siti italiani.
Quattro esempi per capire le differenze
Una catena di abbigliamento è un caso di attività prolungata quando la scheda rimane visibile: nella seconda ripetizione abbiamo contato 16 POST verso un host clarity.ms nei cinque minuti di inattività, con sette richieste nella seconda metà dell'osservazione. La corrispondente scheda nascosta non ha generato nuove richieste nella finestra registrata. Il risultato non autorizza a sostenere che nessuno dei due comportamenti sia universale: in un test precedente, con condizioni diverse, erano state osservate comunicazioni anche a scheda nascosta.
Un pet shop online ha continuato a comunicare in entrambe le condizioni: 31 richieste con scheda visibile e 14 con scheda nascosta. Fra gli host interessati compaiono servizi riconducibili a Microsoft Clarity, VTEX e telemetria applicativa Azure. Anche nella seconda metà del test la scheda nascosta ha avviato sette richieste, e non soltanto nei primi secondi dopo il caricamento.
Un eCommerce di cosmetica naturale ha mostrato nove richieste con scheda visibile e otto con scheda nascosta, con contatti verso host di Microsoft Clarity e Microsoft Advertising. Nella seconda metà del periodo le richieste a scheda nascosta sono state quattro. È un esempio utile di comunicazioni osservate ben oltre la fase iniziale di caricamento.
Un negozio di articoli per l'infanzia presenta il comportamento opposto: 35 richieste in condizione visibile, prevalentemente collegate al widget di recensioni Trustpilot, e nessuna richiesta avviata nella corrispondente finestra nascosta. Non tutti i siti si comportano allo stesso modo, né tutte le comunicazioni sono riconducibili ad analytics: alcuni componenti possono aggiornarsi o recuperare contenuti anche senza un clic.
Questi quattro esempi non sono una classifica di sostenibilità o di protezione della privacy. Misurano tentativi di comunicazione osservati dal browser, e la contemporaneità di molte finestre costituisce una condizione di laboratorio che può influire sul comportamento delle pagine.
"Inviano i nostri dati" è un'affermazione diversa
Un browser non autenticato non è necessariamente anonimo: una richiesta web può esporre al destinatario l'indirizzo IP della connessione e, secondo il contesto, cookie, altri identificativi, intestazioni e dati della pagina o dell'evento. Sistemi di analytics e session recording possono inoltre associare più eventi a una stessa sessione. Ma dal numero di POST non possiamo dedurre il contenuto di un payload. Nei nostri export sono presenti metodi e host, non i dati effettivamente trasmessi. Alcune risposte HTTP 204 No Content indicano semplicemente che il server non ha restituito un corpo di risposta, non che il browser non abbia inviato informazioni.
Per questo l'affermazione sostenuta dall'esperimento è: alcuni eCommerce hanno continuato a generare richieste di rete per diversi minuti in assenza di interazione, talvolta anche a scheda nascosta. Non è dimostrato, con questi dati, che abbiano trasmesso dati personali specifici, violato consensi o trasferito grandi quantità di informazioni. Il traffico osservato dal browser non coincide neppure con il traffico server-to-server.
E i bot AI? È un'altra parte del problema
Il traffico dei crawler va analizzato separatamente. La differenza cold/warm di un browser non può essere applicata ai bot: molti crawler recuperano soprattutto documenti HTML, non eseguono la pagina come un utente reale e possono sfruttare le cache lato CDN o le risposte condizionali. Il rapporto Cloudflare Radar 2025 ha stimato che, nella rete osservata, i bot AI diversi da Googlebot rappresentassero in media il 4,2% delle richieste HTML, mentre Googlebot ne rappresentava il 4,5%; si tratta di dati Cloudflare, non di misure BitHub sui negozi del campione.
Per quantificare il lavoro imposto dai crawler a un singolo eCommerce servirebbero log di accesso, cache hit/miss, numero di richieste all'origine, tempi applicativi e possibilmente CPU e consumo energetico dell'infrastruttura. Un browser non offre questi dati. Allo stesso modo, i byte trasferiti non permettono di calcolare direttamente i kWh o i litri d'acqua utilizzati nei data center.
Che cosa dovrebbe fare, allora, chi gestisce un eCommerce?
La prima domanda non è "quanto pesa la homepage?", ma quali pagine e quali servizi fanno lavoro evitabile. Conviene esaminare categorie, schede prodotto, filtri e ricerca interna; distinguere gli asset essenziali da quelli opzionali; ottimizzare immagini e bundle JavaScript; identificare timer, polling e widget che restano attivi senza apportare valore all'utente. Alcuni aggiornamenti sono indispensabili — per esempio per sessioni, disponibilità o funzionalità in tempo reale — mentre altri possono essere sospesi, diradati o raggruppati quando la pagina non è visibile, testando attentamente effetti su affidabilità e misurazione.
La seconda domanda riguarda l'unità funzionale: byte per pagina vista, richieste per sessione, lavoro server per ricerca o per ordine completato. Sono parametri diversi. Un intervento è convincente quando riduce un costo tecnico osservabile senza peggiorare accessibilità, conversioni, affidabilità e correttezza dei dati. Definire un sito "green" dai soli megabyte, o una piattaforma "inefficiente" dal linguaggio utilizzato, sarebbe un salto logico.
Per un primo controllo delle tue pagine puoi usare gratis il Green Web Audit di BitHub, che misura peso della pagina, Core Web Vitals e stima della CO₂; nell'articolo su CO₂ e performance di un sito spieghiamo perché pagine più leggere costano meno, e in quello sui Core Web Vitals cosa conta per l'esperienza di chi compra.
La conclusione dello studio non è che tutti gli eCommerce continuino a inviare dati all'infinito. È più concreta: la fine del caricamento non coincide sempre con la fine delle comunicazioni e la cache warm, pur alleggerendo enormemente i trasferimenti, non basta a descrivere tutto ciò che un negozio online chiede al browser e all'infrastruttura. Per migliorare bisogna prima sapere quale lavoro continua, perché continua e se può essere evitato.
Nota metodologica e limiti dello studio
Campione non casuale, selezionato per coprire più settori; acquisizione in Chrome mediante Chrome DevTools Protocol; consensi segnati manualmente prima delle prove. Nella campagna rete, 248 URL su 253 erano eleggibili alla scansione, 175 hanno un confronto cold/warm utilizzabile e 147 costituiscono il sottoinsieme prudenziale privo di service worker osservati. Il numero di registrazioni non equivale al numero di negozi o a unità statistiche indipendenti. Sono esclusi risultati HTTP anomali e casi di qualità insufficiente. Il test inattività v2.10 contiene 390 intervalli prodotti da 39 sessioni, non 60 sessioni complete; 10 coppie visibile/nascosta sono comparabili nella seconda ripetizione. Una risposta di un sistema anti-bot, anche HTTP 200, non deve essere trattata come una pagina commerciale valida senza verifica. La modalità "scheda nascosta" può comportare limitazioni di timer e attività imposte da Chrome. È possibile che un intervallo di cinque minuti non catturi eventi con periodicità maggiore. I risultati non misurano il contenuto dei POST, l'energia consumata né il comportamento del visitatore medio.
Fonti e materiali
- Osservatorio BitHub 2026, esportazioni originali del 23 e 26 ottobre 2026, rapporti tecnici V4 e QA, e acquisizioni Idle v2.8/v2.10 del 27 ottobre 2026. Dataset e procedure disponibili per la verifica; il rapporto QA identifica le esclusioni e i limiti.
- HTTP Archive, Web Almanac 2025 — Page Weight: quadro esterno su peso delle pagine, tipologie di risorse e differenza tra homepage e pagine interne.
- Cloudflare, Radar 2025 Year in Review: quote di richieste HTML attribuite a crawler e bot AI nella rete Cloudflare.
- MDN, Page Visibility API: gestione della visibilità delle schede e limitazioni di esecuzione in background.
Domande frequenti su cache e richieste dopo il caricamento
La cache riduce il consumo energetico di un eCommerce?
Non lo abbiamo misurato. Nel campione la cache ha ridotto i dati trasferiti dalla rete del 96,8% in mediana, ma gli script in cache devono comunque essere inizializzati ed eseguiti, e i contatori CPU della campagna sono stati esclusi dalle conclusioni per problemi metodologici.
Un eCommerce può continuare a fare richieste quando non lo sto usando?
Sì. Nei dieci confronti validi del test, nove negozi su dieci hanno avviato almeno una richiesta HTTP nei cinque minuti senza interazioni con la scheda visibile, e tre su dieci anche con la scheda nascosta. Le cause osservate vanno da analytics e session recording a widget di recensioni e servizi applicativi.
Queste richieste significano che il sito invia i miei dati personali?
Il test non lo dimostra: abbiamo registrato metodi e host di destinazione, non il contenuto delle richieste. Ogni richiesta può però esporre al destinatario l'indirizzo IP e, secondo il contesto, cookie e altri identificativi.
Basta misurare la homepage per capire quanto pesa un eCommerce?
No. Tra 19 negozi con homepage, categoria e scheda prodotto confrontabili, sei avevano almeno una pagina interna che trasferiva più dati della homepage.