Introduzione
Quando si parla di cache, spesso si mette tutto nello stesso sacco. In realtà la cache lato server e la cache lato browser lavorano in punti diversi della catena e servono a obiettivi diversi. La prima riduce il lavoro del server e accelera la generazione delle pagine. La seconda riduce il numero di richieste ripetute dal client e rende più rapido il caricamento per l’utente finale.
Capire questa differenza non è un esercizio teorico: cambia il modo in cui si configura un sito, si gestiscono gli aggiornamenti, si evita di rompere layout e contenuti, e si misura davvero il miglioramento di performance.
Cache lato server: cosa fa davvero
La cache lato server è tutto ciò che permette al server web, al reverse proxy, al CMS o all’applicazione di evitare lavoro ripetitivo. Invece di ricostruire ogni volta una pagina o un frammento dinamico, il server può servire una versione già pronta o semi-pronta.
Può agire a livelli diversi:
- Page cache: memorizza l’HTML già generato.
- Object cache: memorizza risultati di query, oggetti PHP, sessioni o dati applicativi.
- Opcode cache: conserva il bytecode PHP compilato in memoria.
- Reverse proxy cache: Nginx, Varnish o soluzioni equivalenti mettono in cache risposte HTTP complete.
Il vantaggio principale è semplice: meno CPU, meno query al database, meno latenza. Se un sito WordPress riceve molte visite sulla stessa pagina, la cache lato server può abbattere il carico in modo drastico.
Esempio pratico
Un articolo blog molto visitato, senza cache, può richiedere PHP, MySQL, plugin, temi e query multiple ad ogni visita. Con una page cache ben impostata, il server restituisce direttamente l’HTML pronto. L’utente non aspetta la generazione dinamica e il server regge molto meglio i picchi.
Cache lato browser: cosa fa davvero
La cache lato browser vive sul dispositivo dell’utente. È il browser che conserva localmente file statici e risorse riutilizzabili: immagini, CSS, JavaScript, font e, in alcuni casi, risposte HTTP intere se gli header lo consentono.
Il suo obiettivo è evitare di scaricare di nuovo contenuti che non sono cambiati. Se una pagina usa lo stesso file CSS da ieri e quel file non è stato modificato, il browser può riutilizzare la copia già presente in locale.
Qui il guadagno non è tanto sul server, quanto sull’esperienza utente:
- meno traffico trasferito;
- meno richieste HTTP;
- caricamenti più rapidi nelle visite successive;
- migliore percezione di velocità, soprattutto su mobile.
La cache del browser è quindi fondamentale per le visite ripetute e per i siti ricchi di asset statici.
Differenza sostanziale tra le due cache
La distinzione vera è questa: la cache lato server ottimizza la produzione della risposta, mentre la cache lato browser ottimizza il riuso della risposta già ricevuta.
In pratica:
- se il server deve generare una pagina lenta, la cache lato server la rende veloce;
- se il browser deve ricaricare file già noti, la cache lato browser evita download inutili.
Le due cose non si escludono. Anzi, in un sito ben fatto si usano insieme. Un sito può servire HTML già cacheato dal server e, contemporaneamente, far sì che CSS e JS vengano conservati dal browser per le visite future.
Casi d’uso della cache lato server
La cache lato server è la scelta giusta quando il collo di bottiglia è nella generazione del contenuto o nell’accesso al database.
- WordPress con molti visitatori: page cache e object cache riducono il carico e migliorano il TTFB.
- E-commerce: si possono cacheare categorie e pagine prodotto pubbliche, ma con attenzione al carrello, al checkout e ai contenuti personalizzati.
- Portali editoriali: articoli e pagine statiche cambiano poco e beneficiano enormemente della cache server-side.
- API ad alto traffico: caching di risposte idempotenti e non sensibili riduce latenza e costi.
- Hosting condiviso o VPS limitata: una cache ben configurata compensa risorse hardware ridotte.
Qui la regola è semplice: più la risposta è uguale per molti utenti, più la cache lato server ha senso.
Casi d’uso della cache lato browser
La cache lato browser è utile quando il sito contiene risorse statiche riutilizzabili e si vuole migliorare il comportamento nelle visite successive.
- CSS e JavaScript: sono i candidati naturali, soprattutto se versionati correttamente.
- Immagini: loghi, icone, sfondi e asset non soggetti a cambi frequenti.
- Font web: evitano download ripetuti e rendono più stabile il rendering.
- Risorse di terze parti: quando affidabili e compatibili con le policy di cache.
- PWA e app web: la cache del browser, insieme al service worker, diventa parte dell’esperienza offline o quasi offline.
La cache browser-side è meno utile per la prima visita, ma diventa molto efficace dalla seconda in poi.
Quando la cache lato server è più importante
È prioritaria quando il sito è lento a generare contenuti, quando il database è sotto pressione o quando il traffico cresce oltre le capacità del server.
Segnali tipici:
- TTFB alto;
- CPU del server saturata;
- molte query lente;
- picchi di traffico che causano timeout;
- pagine dinamiche identiche per utenti diversi.
In questi casi, agire solo sulla cache del browser non risolve il problema principale. Il browser può scaricare più velocemente i file già presenti, ma il server continua a lavorare troppo per generare la pagina.
Quando la cache lato browser è più importante
È prioritaria quando il sito ha molti asset statici, risorse pesanti o utenti che ritornano spesso. È anche fondamentale per non far percepire “lento” un sito che magari lato server è già ottimizzato.
Segnali tipici:
- scaricamenti ripetuti degli stessi file a ogni pagina;
- molti kilobyte trasferiti inutilmente;
- asset senza intestazioni di cache corrette;
- esperienza mobile penalizzata da richieste ridondanti.
Un sito con server veloce ma browser cache mal configurata può sembrare comunque pesante, soprattutto nella navigazione interna.
Header HTTP essenziali da conoscere
La cache browser-side si controlla soprattutto tramite header HTTP. I più importanti sono:
- Cache-Control: indica come e per quanto tempo il browser può conservare la risorsa.
- Expires: data di scadenza, ancora presente in alcuni contesti ma meno flessibile di Cache-Control.
- ETag: consente di verificare se il contenuto è cambiato.
- Last-Modified: aiuta il browser a fare richieste condizionali.
Un’impostazione prudente per file statici versionati è dare una durata lunga alla cache e cambiare nome file quando il contenuto cambia. Per esempio, un CSS con hash nel nome può essere cacheato a lungo senza rischio di servire una versione vecchia.
Per contenuti dinamici o pagine personali, invece, la cache browser deve essere più conservativa o disattivata dove serve.
Errori tipici da evitare
La cache è utile solo se non rompe aggiornamenti, login, carrelli e contenuti personalizzati. Gli errori più comuni sono prevedibili:
- Cache troppo aggressiva sui contenuti dinamici: l’utente vede dati vecchi o non coerenti.
- File statici senza versioning: il browser conserva una vecchia copia e l’aggiornamento non si vede.
- Esclusioni incomplete nel server cache: pagine private o sessioni vengono servite in modo errato.
- Purge mancante dopo deploy: il sito mostra asset obsoleti.
- Confusione tra cache e compressione: gzip o brotli riducono il peso, ma non sono cache.
Una buona politica di cache non deve solo essere veloce, ma anche prevedibile.
WordPress: come ragionare in modo corretto
Su WordPress la distinzione è particolarmente importante. La cache lato server può essere gestita da plugin, da Nginx, da LiteSpeed, da Varnish o da un livello del provider. La cache lato browser si regola invece tramite header e configurazione del web server o del plugin di performance.
In un sito WordPress ben impostato, di solito la logica è questa:
- HTML pubblico: cache lato server;
- CSS, JS, immagini, font: cache lato browser lunga;
- aree utente, carrello, checkout, admin e sessioni: esclusione dalla cache o durata minima.
Questo approccio evita sia il carico inutile sia i problemi di contenuto sbagliato.
Apache, Nginx, LiteSpeed: differenze pratiche
Il concetto resta lo stesso, ma cambia lo strumento.
- Apache: spesso si lavora su header, mod_expires, mod_headers e plugin applicativi.
- Nginx: ottimo per reverse proxy, cache di risposta e gestione efficiente degli asset statici.
- LiteSpeed: molto usato in hosting per la page cache integrata e la buona integrazione con WordPress.
La scelta del web server influenza la facilità con cui si implementa la cache, ma non cambia il principio: server-side per ridurre lavoro, browser-side per evitare download ripetuti.
Come decidere quale cache usare
La domanda giusta non è “qual è meglio?”, ma “dove sta il collo di bottiglia?”.
- Se il server è lento a generare pagine, lavora prima sulla cache lato server.
- Se gli asset statici vengono scaricati troppe volte, lavora sulla cache lato browser.
- Se il sito ha entrambe le criticità, usa entrambe in modo coordinato.
In molti casi la soluzione migliore è un modello a strati: page cache server-side, object cache per il backend, browser cache lunga per gli asset statici e purge automatico quando si pubblica una nuova versione.
Misurare se la cache funziona
Non basta attivarla: va verificata. I segnali utili da osservare sono:
- TTFB più basso dopo l’attivazione della cache server-side;
- cache hit ratio elevata sul reverse proxy o sul plugin;
- riduzione delle richieste ripetute nel browser;
- peso totale della pagina più stabile tra una visita e l’altra;
- meno query al database e meno CPU consumata.
Strumenti utili: DevTools del browser, header HTTP, log del web server, metriche del pannello hosting e test ripetuti da rete pulita e da visita successiva.
Buone pratiche operative
Per usare bene la cache senza effetti collaterali, conviene seguire alcune regole semplici:
- Versionare sempre CSS e JS quando cambiano.
- Escludere login, carrello, checkout e area utente dalla cache pubblica.
- Impostare purge automatico dopo aggiornamenti e deploy.
- Tenere separati contenuti pubblici e dati personalizzati.
- Controllare gli header di risposta dopo ogni modifica.
La cache è una leva di performance, ma anche una disciplina di coerenza. Se la si tratta come un interruttore acceso/spento, prima o poi crea problemi.
Conclusione operativa
La cache lato server e la cache lato browser non competono tra loro: si completano. La prima alleggerisce il server e accelera la generazione della risposta. La seconda riduce i download inutili e migliora l’esperienza dell’utente nelle visite successive. Se il sito è dinamico, traffico alto o WordPress con molti plugin, la cache server-side è spesso il primo passo. Se il sito carica molte risorse statiche, la cache browser-side è indispensabile. La soluzione migliore, quasi sempre, è usarle insieme con regole chiare, esclusioni corrette e verifiche dopo ogni modifica.
La cache efficace non è quella più aggressiva, ma quella che accelera senza mentire al contenuto.
In pratica: server cache per lavorare meno, browser cache per scaricare meno. Due problemi diversi, due strumenti diversi, un unico obiettivo: rendere il sito più veloce senza renderlo fragile.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.