Come impostare i tempi di cache del browser per velocizzare il sito

I tempi di cache del browser si configurano tramite regole HTTP che indicano per quanto tempo i file statici del sito devono restare salvati nel browser del visitatore. In pratica, per CSS, JavaScript, immagini, font e icone si definiscono intestazioni come Cache-Control e, in alcuni ambienti, Expires; ad esempio 1 anno per file CSS e JS versionati, da 30 giorni a 1 anno per le immagini, mentre per le pagine HTML è preferibile usare durate brevi o la riconvalida. Una configurazione corretta evita di scaricare più volte gli stessi file, accelera l’apertura delle pagine e contribuisce a migliorare le metriche Core Web Vitals.

In questa guida vedremo come funziona la cache del browser, quanti secondi assegnare ai diversi tipi di file e come applicare le impostazioni su Apache, Nginx, LiteSpeed, WordPress e CDN. L’obiettivo non è soltanto ottenere un punteggio verde in uno strumento di test della velocità: significa servire file aggiornati agli utenti, usare in modo efficiente le risorse del server, ridurre TTFB e consumo di banda e rendere molto più rapide le visite successive. Soprattutto su hosting condiviso, hosting WordPress e progetti web aziendali, una strategia di cache ben pensata è uno degli interventi di performance più efficaci a parità di costo. Pacchetti web hosting Hostragons

Che cos’è la cache del browser?

La cache del browser è il salvataggio temporaneo, sul dispositivo dell’utente, delle risorse statiche scaricate durante l’apertura di una pagina web. Quando un visitatore entra nella home page, il browser scarica logo, fogli di stile CSS, file JavaScript, font e immagini. Se questi file hanno intestazioni di cache corrette, quando l’utente passa a una seconda pagina o torna sul sito in un secondo momento, il browser non deve richiedere nuovamente una parte di quelle risorse al server. Il risultato è un caricamento più veloce.

Immaginiamo una home page da 2 MB. Se 1,4 MB sono immagini, 300 KB sono CSS e JS e 100 KB sono font, alla prima visita queste risorse possono essere scaricate normalmente. Alla seconda visita, però, se il browser riutilizza localmente i file statici, la quantità di dati trasferiti via rete diminuisce in modo drastico. Questa differenza si nota ancora di più su connessioni mobili, reti instabili e siti con traffico elevato.

La cache del browser non va confusa con la cache lato server. La cache del server conserva sul server l’output PHP, le pagine generate o i risultati di query al database. La cache del browser, invece, consente di riutilizzare risorse già presenti sul dispositivo del visitatore. Per ottenere le migliori prestazioni, i due livelli devono essere pianificati insieme. Nei siti WordPress, page cache, object cache, cache CDN e browser cache sono spesso parti della stessa strategia di ottimizzazione. hosting WordPress e ottimizzazione delle prestazioni

Perché il browser caching è importante per la SEO?

Google tende a valorizzare i siti che offrono un’esperienza rapida, stabile e piacevole. La cache del browser da sola non garantisce un miglioramento di posizionamento; tuttavia supporta la SEO perché influisce su velocità di pagina, latenza di interazione ed efficienza nel caricamento delle risorse. La differenza è evidente soprattutto in scenari come visite ricorrenti, navigazione tra categorie, passaggi tra schede prodotto e lettura di più articoli dello stesso blog.

Negli standard SEO del 2026, la performance tecnica non si riduce più a un semplice punteggio Lighthouse. L’esperienza utente valutata da Google è collegata a LCP, INP, CLS, TTFB e dati reali degli utenti. Il download ripetuto e inutile di file CSS e JS può allungare il tempo LCP. Font richiesti da zero a ogni pagina possono incidere sulla stabilità visiva. Immagini pesanti non memorizzate in cache possono creare una forte percezione di lentezza negli utenti mobile.

• Visite successive più rapide: l’utente non scarica di nuovo gli stessi file.
• Minore consumo di banda: il traffico verso il server diminuisce e le risorse hosting vengono usate meglio.
• Migliore efficienza di scansione: la distribuzione delle risorse statiche diventa più ordinata per utenti e bot.
• Minore rischio di abbandono: pagine che si aprono velocemente favoriscono interazioni e permanenza.
• Prestazioni più costanti: CDN e hosting gestiscono meglio picchi e variazioni di carico.

Le principali intestazioni HTTP per la cache

I tempi di cache del browser vengono gestiti tramite intestazioni di risposta HTTP. Le più comuni sono Cache-Control, Expires, ETag e Last-Modified. Nei progetti moderni il punto di controllo principale è l’intestazione Cache-Control; Expires viene usata soprattutto per compatibilità con browser o sistemi più datati.

Cache-Control

Cache-Control indica al browser e ai sistemi di cache intermedi come deve essere conservato un file. Le direttive più utilizzate sono:

• max-age: specifica per quanti secondi la risorsa deve essere considerata fresca. Per esempio max-age=31536000 corrisponde a circa 1 anno.
• public: indica che la risorsa può essere salvata sia dal browser sia da cache condivise come una CDN.
• private: indica che la risorsa deve essere salvata solo nel browser dell’utente.
• no-cache: indica che la risorsa deve essere riconvalidata con il server prima dell’uso; non significa disattivare completamente la cache.
• no-store: indica che la risorsa non deve essere salvata da nessuna parte; è adatta a pagine di pagamento, pannelli riservati e dati personali.
• immutable: comunica che la risorsa non cambierà fino alla scadenza; è ideale per asset con nome file versionato.

Un esempio di intestazione per un file statico potrebbe essere: Cache-Control: public, max-age=31536000, immutable. In questo modo si dice al browser che il file può essere conservato per 1 anno e che non è necessario ricontrollarlo finché il nome del file non cambia.

Expires

L’intestazione Expires indica fino a quale data e ora una risorsa deve essere considerata valida. Per un’immagine, ad esempio, si può impostare un valore Expires a 30 giorni nel futuro. Tuttavia Expires usa una data assoluta, quindi è meno flessibile di Cache-Control. Nelle configurazioni moderne Cache-Control dovrebbe avere la priorità, mentre Expires può essere aggiunta come supporto per ambienti meno recenti.

ETag e Last-Modified

ETag e Last-Modified sono meccanismi di validazione. Il browser può chiedere al server se la versione del file che possiede è ancora aggiornata. Se il file non è cambiato, il server restituisce una risposta 304 Not Modified e il corpo del file non viene scaricato nuovamente. Questo approccio è utile soprattutto per contenuti che possono cambiare spesso, come l’HTML, o per file a cui non si vuole assegnare una cache molto lunga.

Quale durata di cache usare per ogni tipo di file?

L’errore più frequente è assegnare la stessa durata a tutti i file. In realtà HTML, CSS, JS, immagini, font e risposte API hanno comportamenti di aggiornamento diversi. La regola generale è semplice: se il nome del file può cambiare, si può usare una cache lunga; se il contenuto cambia spesso senza cambiare nome file, meglio usare una durata breve o la riconvalida.

Questa tabella è un buon punto di partenza. In un e-commerce, le pagine HTML che contengono stock e prezzi non dovrebbero essere memorizzate in cache in modo aggressivo. Al contrario, le immagini prodotto possono restare in cache anche 1 anno se il nome file cambia quando vengono aggiornate. In un sito aziendale, logo, font e file del tema possono essere conservati a lungo; se invece i banner promozionali cambiano spesso, una finestra di 7-30 giorni è più prudente.

Come pianificare i tempi di cache del browser?

Per costruire una strategia di cache efficace, il primo passo è classificare i file presenti sul sito. Dal punto di vista tecnico bisogna scrivere regole in base all’estensione dei file; dal punto di vista strategico bisogna decidere la durata in base alla frequenza con cui quei file vengono aggiornati.

1. Separare risorse statiche e dinamiche

File CSS, JS, JPG, PNG, WebP, SVG e WOFF2 sono risorse statiche. HTML, carrello, area utente, risultati di ricerca e risposte API vanno considerati contenuti dinamici. Le risorse statiche possono essere memorizzate in cache per periodi lunghi, mentre i contenuti dinamici richiedono più attenzione. In particolare, per contenuti personalizzati per l’utente non si dovrebbe usare cache pubblica.

2. Usare il versionamento dei file

Il modo più sicuro per usare una cache lunga è versionare i file. Se imposti 1 anno di cache su style.css e poi ne modifichi il contenuto, alcuni utenti potrebbero continuare a vedere il vecchio design. Se invece usi nomi come style.2026.01.css, app.v12.js o app.8f3a2.js con hash nel nome file, al momento dell’aggiornamento viene pubblicato un nuovo nome e il browser scarica automaticamente la nuova risorsa.

I temi WordPress e i moderni strumenti di build possono gestire automaticamente questo processo. Se sviluppi un tema, usare il parametro version nelle funzioni wp_enqueue_style e wp_enqueue_script rende più semplice gestire la versione tramite query string o nome file. Tuttavia, poiché alcune configurazioni CDN trattano in modo diverso le query string nella cache, inserire un hash direttamente nel nome file è spesso una soluzione più solida.

3. Non essere aggressivo con l’HTML

Le pagine HTML contengono il contenuto principale visibile all’utente, quindi in genere vanno gestite con cache breve o riconvalida. Per articoli di blog possono bastare 5-10 minuti di cache; per news, promozioni o pagine prezzo è meglio usare durate ancora più brevi. Se utilizzi page cache su WordPress, le intestazioni di cache del browser devono essere pensate insieme alla cache server e al meccanismo di purge della CDN.

4. Disattivare la cache sulle pagine sensibili

Per login, area clienti, checkout, riepilogo ordine, fatture e pagine che contengono dati personali è preferibile usare intestazioni come Cache-Control: no-store, private. La cache del browser serve a migliorare le prestazioni, ma non deve mai mettere a rischio la sicurezza dei dati. Anche l’uso di SSL, in questo contesto, è un requisito di base. Certificati SSL Hostragons

Impostare la cache del browser con Apache .htaccess

Sui server Apache, la cache del browser viene spesso configurata tramite il file .htaccess. Per molti proprietari di siti su hosting condiviso è il metodo più pratico. Prima di tutto, devono essere attivi i moduli mod_expires e mod_headers. Nella maggior parte degli ambienti hosting di qualità questi moduli sono già disponibili.

La logica da seguire è questa: durata lunga per immagini e font, durata lunga per CSS e JS, riconvalida o durata breve per HTML. Nel file .htaccess si definiscono regole per tipo di file usando ExpiresByType e Header set Cache-Control. Per esempio, si può impostare 1 anno per image/webp, image/jpeg, image/png, image/svg+xml; 1 anno per text/css e application/javascript; no-cache per text/html.

Prima di intervenire, crea sempre una copia di backup del file .htaccess. Una regola scritta male può causare un errore 500 Internal Server Error. Dopo la modifica, apri il sito in una finestra in incognito e controlla nella scheda Network di DevTools la sezione response headers del file interessato. Se Cache-Control non compare, il modulo del server potrebbe essere disattivato, la CDN potrebbe modificare le intestazioni o un plugin potrebbe sovrascrivere le regole.

Valori iniziali sensati su Apache sono: max-age=31536000 per CSS e JS, max-age=31536000 per immagini, max-age=2592000 per PDF, max-age=0 e no-cache per HTML. Sono valori utili come base, ma vanno adattati al flusso editoriale e tecnico del sito. Se usi l’infrastruttura hosting Hostragons e applichi ottimizzazioni tramite .htaccess, verifica sempre che non ci siano conflitti con le impostazioni di cache del tema o dei plugin. impostazioni delle prestazioni .htaccess di Apache

Configurare il browser caching con Nginx

Sui server Nginx, le intestazioni di cache vengono definite all’interno dei blocchi server o location. Nginx è spesso scelto per progetti ad alto traffico grazie alla sua efficienza nel servire file statici. Anche qui la logica principale consiste nel creare regole location basate sulle estensioni e impostare i valori expires e add_header Cache-Control.

Un approccio tipico è assegnare expires 1y e Cache-Control public, immutable a risorse statiche come CSS, JS, WebP, JPG, PNG, SVG e WOFF2. Per l’output HTML si preferisce expires off oppure no-cache. Se utilizzi una CDN, devi anche verificare come la CDN interpreta le intestazioni Cache-Control provenienti dal server origin.

Un aspetto importante nelle configurazioni Nginx è che la direttiva add_header, in alcuni casi, viene applicata solo a determinati codici di risposta. Nelle configurazioni moderne si può usare il parametro always. Inoltre, se la stessa intestazione viene aggiunta dall’applicazione, da Nginx e dalla CDN, possono comparire valori Cache-Control duplicati o in conflitto. In questo caso bisogna chiarire la catena di priorità e decidere quale livello è l’autorità principale.

Cache su LiteSpeed e siti WordPress

I server LiteSpeed offrono un forte vantaggio prestazionale soprattutto nei progetti WordPress grazie al plugin LiteSpeed Cache. Tuttavia è importante distinguere tra cache del browser e page cache. Quando l’opzione Browser Cache viene attivata nel plugin LiteSpeed Cache, le intestazioni per i file statici possono essere applicate automaticamente. Conviene comunque controllare le durate impostate.

Su WordPress la pratica consigliata è salvare in cache per periodi lunghi gli asset statici e mantenere attivo il versionamento dei file. Quando aggiorni il tema, modifichi CSS o cambi JavaScript, il plugin dovrebbe svuotare la cache; se usi una CDN, deve essere eseguito anche il purge della CDN. In caso contrario, alcuni utenti potrebbero visualizzare un vecchio layout o riscontrare comportamenti JavaScript non corretti.

Nei plugin di cache più diffusi si trovano opzioni come Browser Cache, Minify, Combine, Critical CSS, integrazione CDN e Object Cache. Attivarle tutte in modo aggressivo non è sempre la scelta migliore. Prima sistema le intestazioni della cache del browser, poi testa minify e combine. Nel 2026 HTTP/2 e HTTP/3 sono ormai molto diffusi, quindi unire ogni file non è più indispensabile come in passato; in alcune situazioni può persino ridurre l’efficienza della cache.

Se il tuo sito WordPress è lento, il problema potrebbe non essere soltanto la browser cache. Database appesantito, tema troppo pesante, troppi plugin, immagini non ottimizzate e hosting con poche risorse influenzano molto le prestazioni. Per questo le impostazioni di cache vanno valutate insieme a un hosting affidabile, una versione PHP aggiornata e una configurazione SSL corretta. Hosting WordPress Hostragons

Come impostare i tempi di cache quando si usa una CDN?

Una CDN distribuisce i file statici da server edge geograficamente vicini all’utente. La cache del browser, invece, conserva il file direttamente nel browser del visitatore. Quando questi due livelli lavorano insieme, il miglioramento delle prestazioni diventa molto più evidente. Tuttavia la durata della cache edge definita nel pannello CDN deve essere coerente con le intestazioni Cache-Control del server origin.

Un’impostazione generale può essere questa: sul server origin assegna 1 anno di Cache-Control ai file statici e definisci nella CDN un TTL uguale o comunque controllato. Quando un file cambia, usa il versionamento del nome file oppure esegui un purge della CDN. Per le pagine HTML, se vuoi usare cache CDN, crea regole specifiche; carrello, account, pagamento e pannelli amministrativi devono essere esclusi senza eccezioni.

Un problema comune nei siti con CDN è vedere ancora vecchi file dopo un aggiornamento. Di solito succede perché il contenuto viene modificato senza cambiare nome file oppure perché non viene eseguito il purge della CDN. Il metodo più robusto è generare file con hash durante il processo di build e richiamare nel codice HTML il nuovo nome file. Così, anche se browser e CDN conservano la vecchia risorsa, la nuova pagina richiederà il nuovo file.

Checklist pratica passo dopo passo

La checklist seguente offre un piano operativo per impostare correttamente i tempi di cache del browser. Su un piccolo sito aziendale può essere applicata in 30-60 minuti; su e-commerce o applicazioni personalizzate è meglio prevedere una fase di test più lunga.

• 1. Fai l’inventario dei file: separa CSS, JS, immagini, font, PDF, HTML e risposte API.
• 2. Definisci la frequenza di aggiornamento: annota quali file cambiano ogni giorno e quali una volta al mese.
• 3. Scegli una strategia di versionamento: usa hash nel nome file, parametro di versione o numero di build.
• 4. Aggiungi le regole server: definisci le intestazioni Cache-Control su Apache, Nginx, LiteSpeed o nel pannello CDN.
• 5. Escludi le pagine sensibili: usa no-store su admin, checkout, carrello, area utente e pagine con dati personali.
• 6. Testa la configurazione: verifica con Chrome DevTools, curl -I, WebPageTest, Lighthouse e dispositivi reali.
• 7. Monitora dopo la pubblicazione: controlla eventuali file vecchi, layout rotti o errori JavaScript.

Come testare la cache del browser?

Il modo più rapido per capire se le impostazioni funzionano è usare gli strumenti per sviluppatori del browser. In Chrome, apri la pagina, vai nella scheda Network di DevTools, clicca su un file CSS o su un’immagine e controlla il valore Cache-Control nella sezione Response Headers. Al secondo caricamento, nella colonna Status potresti vedere indicazioni come memory cache o disk cache.

Se usi la riga di comando, il comando curl -I tuodominio.com/file.css mostra le intestazioni di risposta. Qui puoi controllare Cache-Control, Expires, ETag e Last-Modified. Se l’intestazione attesa non è presente, uno dei livelli tra applicazione, web server e CDN potrebbe aver modificato o sovrascritto la configurazione.

Per i test di performance puoi usare Lighthouse, PageSpeed Insights e WebPageTest. Tuttavia non conviene applicare i suggerimenti in modo automatico: valuta sempre il contesto reale degli utenti. Per esempio Lighthouse può suggerire una cache lunga per i file statici, ma non si aspetta la stessa aggressività sulle pagine HTML. Inoltre gli strumenti di test a volte segnalano script di terze parti; per Google Fonts, reti pubblicitarie o widget social potresti non avere controllo diretto sui tempi di cache.

Errori frequenti

La cache del browser sembra semplice, ma una configurazione sbagliata può causare problemi di aggiornamento, rischi di sicurezza e peggioramenti dell’esperienza utente. Gli errori seguenti sono particolarmente comuni quando si inizia a ottimizzare un sito.

• Assegnare 1 anno di cache a tutto: HTML, risposte API e contenuti personalizzati non dovrebbero rientrare in questa regola.
• Usare cache lunga senza versionare i file: gli utenti possono continuare a ricevere vecchi CSS o JS.
• Dimenticare il purge della CDN: anche se l’origin è aggiornato, la CDN può continuare a servire file vecchi.
• Sovrapporre più plugin di cache: più plugin possono scrivere le stesse intestazioni e creare conflitti.
• Interpretare male gli avvisi sui servizi esterni: le intestazioni di script di terze parti possono non essere sotto il tuo controllo.
• Mettere in cache pagine sensibili: su pagamento e account deve essere usato no-store.

Valori iniziali consigliati

Per un nuovo sito, una configurazione iniziale sicura può essere riassunta così: 1 anno per file CSS e JS se sono versionati; 1 anno per le immagini, ma 30 giorni per immagini promozionali che cambiano spesso; 1 anno per i font; da 7 a 180 giorni per i PDF in base alla frequenza di aggiornamento; no-cache o pochi minuti per le pagine HTML. Questo approccio mantiene un buon equilibrio tra prestazioni e freschezza dei contenuti.

Se il tuo sito è una vetrina aziendale, durate di cache lunghe di solito non creano problemi. Se gestisci un e-commerce, puoi impostare una cache lunga sui file statici della pagina prodotto, ma devi escludere prezzo, stock, carrello e dati utente. Se hai un sito di news o un blog, puoi conservare a lungo immagini e file del tema, mentre l’output HTML dovrebbe avere una cache breve in base al ritmo di pubblicazione. Anche dominio, SSL e infrastruttura hosting fanno parte della catena delle prestazioni. Verifica dominio Hostragons Soluzioni hosting aziendale Hostragons

Conclusione

I tempi di cache del browser, quando sono pianificati correttamente, possono migliorare in modo significativo le prestazioni del sito nelle visite successive. La regola di base è semplice: cache lunga per file statici versionati, durata breve o no-store per HTML e pagine con dati personali. Su Apache, Nginx, LiteSpeed, WordPress e CDN la logica resta la stessa: riconosci il tipo di risorsa, definisci la frequenza di aggiornamento, testa le intestazioni Cache-Control e continua a monitorare dopo la pubblicazione.

In sintesi, il browser caching è un’ottimizzazione a basso costo ma ad alto impatto. Se ospiti il tuo sito sull’infrastruttura Hostragons, puoi scegliere impostazioni di cache adatte al tuo tipo di hosting e rafforzare sia l’esperienza utente sia la performance SEO tecnica. Per trovare la soluzione di hosting più adatta alle tue esigenze, puoi consultare le opzioni Hostragons o verificare passo dopo passo la configurazione cache del tuo sito attuale. Pacchetti Hosting Hostragons

Domande frequenti

Quanto deve durare la cache del browser?

Per file statici versionati come CSS, JS, immagini e font, una durata tra 30 giorni e 1 anno è generalmente ideale. Per le pagine HTML, dove l’aggiornamento del contenuto è più importante, è preferibile usare no-cache, max-age=0 o una durata breve di pochi minuti.

Qual è la differenza tra Cache-Control ed Expires?

Cache-Control è un’intestazione HTTP moderna e più flessibile, basata su regole in secondi come max-age. Expires indica invece una data e un’ora specifiche. Nei progetti attuali conviene usare Cache-Control come riferimento principale e aggiungere Expires solo per compatibilità.

Come si attiva il browser caching in WordPress?

In plugin come LiteSpeed Cache, WP Rocket o W3 Total Cache si può attivare l’opzione Browser Cache o cache del browser. In alternativa, si possono aggiungere intestazioni Cache-Control per tipo di file tramite .htaccess o configurazione server.

Con una cache lunga gli aggiornamenti del sito non si vedono?

Se aggiorni lo stesso file CSS o JS senza cambiarne il nome, alcuni utenti potrebbero continuare a vedere la vecchia versione. Per evitarlo bisogna usare versionamento dei file, nomi con hash e purge della CDN quando necessario.

Le pagine di pagamento e area utente devono essere memorizzate in cache?

No. Pagine di pagamento, carrello, account, fatture e pannelli amministrativi contengono dati personali e devono usare intestazioni sicure come Cache-Control: no-store, private. Le prestazioni non devono mai compromettere la sicurezza.