nginx configurazione · 3 min read · Dec 26, 2025

Fai Cache dei File Statici nei Browser su nginx

Questo tutorial spiega come puoi configurare nginx per impostare l’intestazione HTTP Expires e la direttiva max-age dell’intestazione HTTP Cache-Control dei file statici (come immagini, file CSS e Javascript) a una data futura in modo che questi file vengano memorizzati nella cache dai browser dei tuoi visitatori. Questo salva larghezza di banda e rende il tuo sito web più veloce (se un utente visita il tuo sito per la seconda volta, i file statici verranno recuperati dalla cache del browser).

Non fornisco alcuna garanzia che questo funzionerà per te!

1 Nota Preliminare

Presumo che tu abbia una configurazione nginx funzionante, ad esempio come mostrato in questo tutorial: Installazione di Nginx con PHP5 (e PHP-FPM) e supporto MySQL (LEMP) su Ubuntu 12.04 LTS

2 Configurazione di nginx

L’intestazione HTTP Expires può essere impostata con l’aiuto della direttiva expires che può essere posizionata all’interno di http {}, server {}, location {}, o in un’istruzione if all’interno di un blocco location {}. Di solito la utilizzerai in un blocco location per i tuoi file statici, ad esempio come segue:

| location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 365d; } |

Nell’esempio sopra, tutti i file .jpg, .jpeg, .png, .gif, .ico, .css e .js ricevono un’intestazione Expires con una data 365 giorni nel futuro rispetto al tempo di accesso del browser. Pertanto, dovresti assicurarti che il blocco location {} contenga realmente solo file statici che possono essere memorizzati nella cache dai browser.

Ricarica nginx dopo le tue modifiche:

/etc/init.d/nginx reload

Puoi utilizzare le seguenti impostazioni temporali con la direttiva expires:

  • off fa sì che le intestazioni Expires e Cache-Control non vengano modificate.
  • epoch imposta l’intestazione Expires al 1 gennaio 1970 00:00:01 GMT.
  • max imposta l’intestazione Expires al 31 dicembre 2037 23:59:59 GMT, e il max-age di Cache-Control a 10 anni.
  • Un tempo senza un prefisso @ significa un tempo di scadenza relativo al tempo di accesso del browser. Può essere specificato un tempo negativo, che imposta l’intestazione Cache-Control su no-cache. Esempio: expires 10d; o expires 14w3d;
  • Un tempo con un prefisso @ specifica un tempo di scadenza assoluto, scritto nella forma Hh o Hh:Mm, dove H varia da 0 a 24, e M varia da 0 a 59. Esempio: expires @15:34;

Puoi utilizzare le seguenti unità di tempo:

  • ms: millisecondi
  • s: secondi
  • m: minuti
  • h: ore
  • d: giorni
  • w: settimane
  • M: mesi (30 giorni)
  • y: anni (365 giorni)

Esempi: 1h30m per un’ora e trenta minuti, 1y6M per un anno e sei mesi.

Nota anche che se utilizzi un’intestazione Expires a lungo termine devi cambiare il nome del file del componente ogni volta che il componente cambia. Pertanto è una buona idea versionare i tuoi file. Ad esempio, se hai un file javascript.js e vuoi modificarlo, dovresti aggiungere un numero di versione al nome del file del file modificato (ad esempio, javascript-1.1.js) in modo che i browser debbano scaricarlo. Se non cambi il nome del file, i browser caricheranno il file (vecchio) dalla loro cache.

Invece di basare l’intestazione Expires sul tempo di accesso del browser (ad esempio expires 10d;), puoi anche basarla sulla data di modifica di un file (si prega di notare che questo funziona solo per file reali memorizzati sul disco rigido!) utilizzando la parola chiave modified che precede il tempo:

expires modified 10d;

3 Test

Per testare se la tua configurazione funziona, puoi installare il plugin Live HTTP Headers per Firefox e accedere a un file statico tramite Firefox (ad esempio un’immagine). Nell’output di Live HTTP Headers, dovresti ora vedere un’intestazione Expires e un’intestazione Cache-Control con una direttiva max-age (max-age contiene un valore in secondi, ad esempio 31536000 è un anno nel futuro):

4 Link

Informazioni sull’autore

Falko Timme è il proprietario di Timme Hosting (hosting web nginx ultra-veloce). È il principale manutentore di HowtoForge (dal 2005) e uno dei core developer di ISPConfig (dal 2000). Ha anche contribuito al libro di O’Reilly “Linux System Administration”.

Share: X/Twitter LinkedIn

Ricevi i nuovi post nella tua casella di posta.

Nessuno spam. Disiscriviti in qualsiasi momento.