Come ridurre le richieste al container server

da | Nov 10, 2026 | Fondamenti e hosting del container server-side

Come ridurre le richieste al container server

Un e-commerce con 50.000 sessioni al mese e un tracciamento "completo" arriva facilmente a superare il milione di richieste mensili verso il container server. Non perché vende tanto, ma perché manda allo stesso endpoint tre eventi di scroll, un timer ogni 15 secondi, il page_view duplicato dal plugin e lo stesso purchase due volte verso Meta. Ogni singola chiamata è un’unità di costo: capire quali servono davvero è la differenza tra un’infrastruttura da poche decine di euro e una bolletta che ti fa dubitare del server-side.

Come ridurre le richieste al container server? La risposta in breve

Si riducono eliminando le richieste duplicate, inutili o non umane, non tagliando eventi che portano valore. L’ordine corretto è: prima misuri da dove arrivano le chiamate, poi togli i duplicati tra browser e server, poi filtri bot e preflight, infine riduci il rumore (scroll, timer, hover) e solo alla fine metti mano alle impostazioni dell’hosting.

Una richiesta verso il container server è ogni chiamata HTTP che arriva al tuo endpoint di tracciamento, tipicamente il sottodominio first-party tipo sgtm.tuodominio.it. Ci rientrano gli hit degli eventi raccolti dai client (client GA4, client Meta, client personalizzati), le richieste di script serviti dal container (gtm.js, gtag.js), le chiamate di preflight CORS, le scansioni di bot e scanner di sicurezza. Non sono richieste, invece, le chiamate in uscita che i tag fanno verso Google, Meta o altre piattaforme: quelle non le conti come traffico in ingresso, ma consumano CPU e tempo di esecuzione.

Una precisazione che vale più di tutto il resto: ridurre le richieste non è una strategia di privacy. Il server-side non aggira il consenso e togliere eventi per risparmiare non sostituisce una gestione corretta del Consent Mode v2 lato server. Sono due problemi distinti, con soluzioni distinte.

Perché il numero di richieste decide la bolletta?

Dipende da come fattura il tuo hosting. I tre modelli più diffusi contano cose diverse.

Modello Unità fatturata La riduzione delle richieste…
Hosting gestito a volume Numero di richieste/eventi mensili Incide direttamente: meno richieste, meno costo o piano più basso
Cloud Run (autogestito) vCPU-secondi, memoria, istanze attive, traffico in uscita Incide indirettamente: meno richieste → meno istanze attive e meno tempo CPU
Server dedicato / VPS a canone Istanza fissa Non incide sul canone, ma su quando sei costretto a salire di taglia

Su Cloud Run la variabile vera non è il conteggio nudo, ma quanto tempo di CPU consuma ogni richiesta. Un evento che attiva sei tag server (GA4, Google Ads, Meta CAPI, TikTok, un webhook e un log su BigQuery) costa molto più di un evento che ne attiva uno. Per questo tagliare un singolo tag ridondante può valere più che tagliare mille richieste di scroll.

Un calcolo con ipotesi dichiarate

Facciamo i conti su un e-commerce ipotetico. Ipotesi: 50.000 sessioni/mese, 8 eventi medi per sessione inviati al server, 1 richiesta di caricamento script per sessione.

  • Eventi: 50.000 × 8 = 400.000 richieste
  • Script serviti: 50.000 richieste
  • Totale stimato: 450.000 richieste/mese

Ora togli il rumore. Se 3 degli 8 eventi sono scroll a soglie multiple, timer e un page_view duplicato da un plugin, scendi a 5 eventi per sessione: 250.000 + 50.000 = 300.000 richieste. Un terzo in meno senza aver toccato un solo evento di conversione.

I numeri reali li trovi nel tuo pannello. Per gli ordini di grandezza di spesa, nella guida su quanto costa davvero un container server side ci sono le cifre con i vari modelli a confronto.

Cosa ti serve prima di iniziare

Non partire a tagliare trigger a istinto. Prima raccogli questi elementi:

  1. Accesso ai log del container server o alle statistiche del provider, con dati di almeno 30 giorni.
  2. Accesso in modifica ai container GTM web e server, e la possibilità di pubblicare versioni separate.
  3. Una baseline di conversioni: numero di purchase/lead in GA4, conversioni in Google Ads e Meta per gli ultimi 28 giorni. Ti serve per il confronto dopo.
  4. La mappa dei client attivi sul container server: quali client (GA4, Meta, personalizzati) sono accesi e su quali path rispondono.
  5. Un ambiente di anteprima funzionante, sia lato web sia lato server.

Se non hai la baseline, fermati e prendila. Ottimizzare senza un prima/dopo significa non sapere se hai risparmiato o rotto il tracciamento.

Da dove arrivano davvero le richieste? Audit in 4 passi

Passo 1 — Leggi i log per tipo di client

Apri i log del container (su Cloud Run, Cloud Logging; su hosting gestito, la sezione statistiche) e raggruppa le richieste per percorso. Vedrai subito cose come /g/collect, /gtm.js, /gtag/js, i path dei client custom e una quota di richieste che non corrisponde a nessun client: quelle sono scansioni, 404 e preflight.

Segna le prime cinque voci per volume. Nel 90% dei casi il problema sta lì.

Passo 2 — Conta le richieste per singolo evento in anteprima

Apri l’anteprima del container server, naviga il sito come un utente: home → categoria → prodotto → carrello → checkout → thank you page. Conta quante righe compaiono nella colonna di sinistra.

Se per una sola pagina prodotto vedi page_view, view_item, due scroll, un user_engagement e un gtm.timer, hai trovato sei richieste dove ne bastavano due.

Passo 3 — Isola le richieste senza valore

Cerca questi pattern:

  • Eventi duplicati: stesso event_name con lo stesso event_id entro pochi secondi.
  • Traffico interno e di test: il tuo IP, gli ambienti di staging che puntano al container di produzione.
  • Bot e scanner: user agent vuoti, richieste senza parametri attesi, hit su path inesistenti.
  • Preflight CORS: richieste OPTIONS generate quando il container risponde su un dominio diverso da quello del sito. Si eliminano quasi del tutto con un sottodominio first-party configurato correttamente.

Passo 4 — Classifica ogni evento

Metti ogni evento in una di tre colonne:

  • Essenziale: alimenta una conversione, un pubblico di remarketing o un report usato davvero (purchase, begin_checkout, generate_lead, add_to_cart).
  • Utile: serve a diagnosticare o segmentare, ma può essere campionato o aggregato (view_item_list, search).
  • Eliminabile: non lo guarda nessuno da sei mesi (scroll ogni 10%, hover, timer generici).

Se un evento è nella terza colonna, non deve arrivare al server. Punto.

Quali eventi inviare al server e quali eliminare?

L’errore più comune è replicare lato server l’intero set di eventi del container web, come fosse un backup. Non è un backup: è una moltiplicazione dei costi.

Aggrega invece di moltiplicare

Tre eventi di scroll diventano uno solo con un parametro. Prima:

dataLayer.push({ event: 'scroll_25' });
dataLayer.push({ event: 'scroll_50' });
dataLayer.push({ event: 'scroll_75' });
dataLayer.push({ event: 'scroll_90' });

Dopo, un unico push alla soglia che conta davvero:

dataLayer.push({
  event: 'page_engagement',
  engagement_type: 'scroll',
  scroll_depth: 75,
  content_group: 'blog'
});

Quattro richieste diventano una. Su 50.000 sessioni sono 150.000 chiamate in meno al mese.

CMS e plugin che sdoppiano gli eventi

Su WooCommerce capita spesso di avere il tema che inserisce gtag, un plugin GA4 che fa lo stesso e GTM che aggiunge il suo: tre purchase per un ordine. Su Shopify convivono il pixel nativo delle Customer Events, le app di tracciamento e il container: controlla il checkout, è il punto dove si sommano. Su PrestaShop i moduli di tracciamento tendono a duplicare add_to_cart quando l’aggiunta avviene via AJAX e la pagina si ricarica.

La verifica è banale: apri l’anteprima, completa un ordine di test, conta i purchase. Se sono più di uno, hai trovato il tuo risparmio. Un Data Layer ben strutturato per l’e-commerce risolve il problema alla radice, perché smetti di dipendere dagli automatismi dei plugin.

Come evitare richieste duplicate tra web e server?

Qui c’è l’opinione netta: se hai attivato la Conversions API (CAPI) di Meta lato server e la deduplicazione funziona, il Meta Pixel browser per quegli stessi eventi va spento. Tenerlo "per sicurezza" non aumenta la copertura, raddoppia le richieste e introduce un rischio di doppio conteggio quando l’event_id non combacia.

La deduplicazione si regge su due parametri identici nei due flussi: event_name e event_id. Generi l’ID una volta sola e lo propaghi.

dataLayer.push({
  event: 'purchase',
  event_id: 'ord-' + orderId,   // stesso valore su browser e server
  value: 89.90,
  currency: 'EUR',
  transaction_id: orderId
});

Nel container web crei una variabile Data Layer DLV - event_id e la mappi nel campo Event ID del tag Meta. Nel container server, il tag Conversions API legge lo stesso valore dall’evento in arrivo. Se entrambi i flussi restano attivi, Meta scarta il secondo. Il procedimento completo, con i casi limite, è nella guida su come deduplicare gli eventi tra browser e server.

Regola operativa: un solo flusso per piattaforma e per evento. Il doppio flusso ha senso solo nella finestra di transizione, quando stai verificando che il server-side raccolga almeno quanto il client-side. Finita la verifica, spegni il browser per quegli eventi.

Come filtrare bot e traffico non umano prima che arrivi al container?

Le scansioni automatiche non chiedono il permesso e, sugli hosting a volume, si fatturano come gli utenti veri. Tre livelli di difesa, dal più economico al più invasivo:

1. A monte, sul CDN o sul bilanciatore. È il filtro che costa meno, perché la richiesta non raggiunge nemmeno il container: blocchi per user agent noti, applichi rate limiting per IP, consenti solo i path effettivamente usati dai tuoi client.

2. Nel client del container server. Configura il client GA4 perché risponda solo sui percorsi attesi e scarti le richieste prive dei parametri minimi (tid, cid, en).

3. Nei trigger dei tag. Un’eccezione sul trigger che blocca l’esecuzione quando mancano parametri attesi. Attenzione: qui la richiesta è già arrivata e già contata. Risparmi CPU, non volume.

Il limite è onesto: non tutti i bot sono riconoscibili e un filtro troppo stretto taglia utenti reali — tipicamente chi naviga da VPN aziendale o da reti mobili con IP condivisi. Parti largo, misura, stringi. Le regole pratiche e le liste da usare sono nell’articolo dedicato a come filtrare bot e spam nel container server.

Cache, batching e impostazioni dell’hosting: cosa aiuta davvero?

Leva Effetto atteso Rischio Difficoltà
Cache di gtm.js/gtag.js su CDN Meno richieste di script al container Aggiornamenti dei tag propagati con ritardo Media
Alzare la concorrenza per istanza (Cloud Run) Meno istanze attive a parità di traffico Latenza in crescita se i tag sono pesanti Media, con monitoraggio
Istanze minime a 0 Zero costo in idle Cold start sul primo evento, rischio di perderlo Bassa, ma rischiosa su e-commerce
Istanze minime a 1+ Nessun cold start Costo fisso continuo Bassa
Ridurre i tag server per evento Meno CPU per richiesta Perdita di destinazioni se tagli male Media

Il caching degli script è la leva con il miglior rapporto beneficio/rischio: quelle richieste non portano dati, servono solo a consegnare un file. Su un sito con molte pagine per sessione, spostarle sul CDN con un TTL ragionevole libera volume senza toccare un evento.

Sulle istanze minime: non scendere a zero su un e-commerce con traffico continuo. Il cold start di sGTM si misura in centinaia di millisecondi e nei picchi — una campagna email, un lancio — perdi eventi proprio quando valgono di più. Risparmiare dieci euro al mese per perdere conversioni nel giorno di punta è una pessima operazione. Il confronto tra gestire l’infrastruttura in proprio e appoggiarsi a un hosting dedicato è trattato nel pezzo su Cloud Run come alternativa all’hosting gestito.

Come verificare di non aver perso dati dopo la riduzione?

Pubblica le modifiche a blocchi, non tutte insieme. Un blocco per volta ti dice quale intervento ha causato l’eventuale scostamento.

Poi confronta su un periodo comparabile — 14 giorni prima contro 14 giorni dopo, stesso giorno della settimana:

  • GA4: numero di purchase/generate_lead, ricavo totale, utenti attivi.
  • Google Ads: conversioni importate e tempo di arrivo. Se dopo l’intervento le conversioni scendono mentre GA4 regge, il problema è nel tag Ads, non nel volume. Lo scenario è analizzato in perché le conversioni Google Ads non corrispondono a GA4.
  • Meta: eventi ricevuti e qualità della corrispondenza nel Gestore eventi. Se il punteggio scende dopo aver spento il Pixel browser, mancano parametri utente nel payload server.

Controlla anche il consenso: gli eventi degli utenti che non hanno acconsentito devono continuare a comportarsi come previsto, in modalità consentita e senza identificatori. La procedura di controllo è descritta in come verificare che il consenso venga rispettato.

Infine, imposta un presidio: un alert sul volume di richieste giornaliere e un budget con notifica sul provider. Una modifica al sito, un nuovo plugin o un attacco automatizzato possono far risalire i numeri in una notte.

Quando conviene farsi affiancare?

In autonomia puoi fare molto: classificare gli eventi, ripulire i push del Data Layer, spegnere i tag duplicati, impostare la deduplicazione con event_id, attivare la cache degli script.

Conviene invece farsi affiancare quando ricorre uno di questi segnali:

  • più domini o più brand che condividono lo stesso container;
  • oltre cinque client attivi, con integrazioni custom;
  • e-commerce con volumi alti e picchi stagionali marcati;
  • una gestione del consenso articolata, con regimi diversi per area geografica;
  • un calo di conversioni dopo l’ottimizzazione che non riesci a spiegare.

In questi casi l’errore costa più della consulenza: un purchase perso per tre settimane su un account Ads che ottimizza in automatico si paga in budget sprecato. Se vuoi un confronto sulla configurazione attuale prima di tagliare, puoi scriverci e descrivere il tuo setup.

Domande frequenti

Quante richieste al mese gestisce un container server prima di costare molto?

Non esiste una soglia universale, perché dipende dal modello di fatturazione. Sugli hosting a volume paghi scaglioni di richieste, quindi il salto di costo avviene quando superi la soglia del piano. Su Cloud Run paghi tempo di CPU e istanze attive: lì contano più i tag per evento che il numero di richieste. Il modo corretto di stimare è moltiplicare le sessioni mensili per gli eventi medi inviati al server, aggiungere le richieste di script e confrontare il risultato con il listino del tuo provider.

Ridurre le richieste peggiora la qualità dei dati?

Solo se tagli gli eventi sbagliati. Eliminare duplicati, traffico bot e micro-interazioni che nessuno analizza non toglie nulla ai report né alle piattaforme pubblicitarie. Diventa un problema se rimuovi eventi usati per pubblici di remarketing, conversioni importate in Google Ads o segmenti già attivi. Per questo la classificazione in essenziale/utile/eliminabile va fatta prima di toccare i trigger, e serve una baseline di conversioni da confrontare dopo.

Conviene disattivare il Meta Pixel web se uso la Conversions API?

Sì, per gli eventi che invii già lato server e la cui deduplicazione hai verificato. Tenere entrambi i flussi raddoppia le richieste senza aumentare la copertura, visto che Meta scarta comunque il duplicato quando event_name ed event_id coincidono. L’eccezione è la fase di transizione: tieni i due flussi per due o tre settimane, confronta i volumi nel Gestore eventi e solo quando il server-side raccoglie almeno quanto il browser spegni il Pixel per quegli eventi.

Le richieste dei bot vengono fatturate come quelle degli utenti?

Sulla maggior parte degli hosting a volume sì: il contatore registra ogni chiamata HTTP che arriva all’endpoint, indipendentemente da chi la genera. Su Cloud Run consumano CPU e possono far scalare le istanze. Per questo il filtro più efficace è quello a monte, sul CDN o sul bilanciatore, dove la richiesta viene bloccata prima di raggiungere il container. I filtri impostati nei trigger risparmiano risorse di elaborazione, ma la richiesta è già stata conteggiata.