L’avviso su un sito WordPress “Specify a cache validator” in Pingdom, GTmetrix o Google PageSpeed Insights è dovuto alla mancanza di intestazioni di cache HTTP che dovrebbero essere invece presenti in ogni risposta del server di origine, in quanto entrambe convalidano e impostano la lunghezza della cache. Se gli header non vengono trovati, sarà generata ogni volta una nuova richiesta per la risorsa, aumentando così il carico sul server. Gli header della cache assicurano che le richieste successive non debbano essere caricate dal server, risparmiando così banda e migliorando le prestazioni per l’utente.
L’avviso di Pingdom dice:
Alle seguenti risorse manca un validatore di cache. Le risorse che non specificano un validatore di cache non possono essere aggiornate in modo efficiente. Specificare un’intestazione LastModified o ETag per abilitare la validazione della cache per le seguenti risorse.
Seguite questa procedura per rimuovere l’avviso “Specify a cache validator”.
Rimuovere l’Avviso “Specify a cache validator”
La prima cosa importante da notare di questo avviso è che si può risolvere solo per le richieste che sono sul vostro server. Se viene generato per richieste di terze parti, non c’è nulla che possiate fare perché non avete il controllo dei loro server web. Potete comunque condividere questo articolo con loro. E ricordate, con Pingdom potreste aver bisogno di eseguire il test un paio di volte. L’avviso potrebbe apparire la prima volta e sparire la seconda volta. La prima volta lo strumento esegue il priming della cache delle risorse dal server.
Ci sono quattro diversi tipi di intestazioni che possono essere utilizzate in modi diversi per rimuovere questo avviso. Qui può diventare un po’ complicato, ma cercheremo di spiegarlo nel modo più semplice possibile.
Headers che Convalidano la Cache
Le prime due intestazioni sono last-modified e ETag. Queste intestazioni aiutano il browser a determinare se il file è stato modificato dall’ultima volta che è stato richiesto. O meglio, convalidano la cache.
1. Last-Modified
L’header last-modified viene generalmente inviato automaticamente dal server. È un’intestazione che generalmente non sarà necessario aggiungere manualmente. Viene inviata per vedere se il file nella cache del browser è stato modificato dall’ultima volta che è stato richiesto. Potete analizzare la richiesta dell’header in Pingdom o in Chrome DevTools per vedere il valore dell’ultima intestazione modificata.
2. ETag
L’header ETag è molto simile all’ultimo header modificato. È utilizzato anche per convalidare la cache di un file. Se si esegue Apache 2.4 o superiore, l’intestazione ETag viene aggiunta automaticamente utilizzando la direttiva FileETag. E per quanto riguarda NGINX, dal 2016 l’intestazione ETag è abilitata di default.
È possibile abilitare manualmente l’intestazione ETag in NGINX utilizzando il seguente codice.
etag onHeader che Determinano la Lunghezza della Cache
Le successive due intestazioni sono Cache-Control e Expires. Questi header permettono di stabilire per quanto tempo il file deve essere tenuto in cache prima di recuperare una nuova copia dal server. Ricordate, per eliminare gli avvisi che vedete in Pingdom o GTmetrix, dovete assicurarvi di avere un header che convalidi la cache e uno che determini la lunghezza della cache.
3. Cache-Control
Cache-Control è un header composto da diverse direttive che permettono di definire la lunghezza della cache. Alcune delle direttive più comuni sono le seguenti:
- max-age: stabilisce per quanto tempo un file deve essere memorizzato nella cache.
- public: permette a qualsiasi cache di memorizzare pubblicamente la risposta.
- private: memorizzabile nella cache solo tramite il browser che accede al file.
Nell’esempio, vediamo che l’asset sta utilizzando la direttiva max-age. 604800 secondi equivarrebbe a una cache di sette giorni. Per configurarla in Apache, è sufficiente aggiungere il seguente codice al file .htaccess.
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
Per configurarlo in NGINX, bisognerà aggiungere il seguente codice al file di configurazione. Tutti i file di configurazione NGINX si trovano nella directory /etc/nginx/. Il file di configurazione principale è /etc/nginx/nginx.conf.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
add_header Cache-Control "public";
}Per saperne di più sulle diverse direttive, consultate questo articolo di approfondimento su Cache-Control.
4. Expires
E per ultimo c’è l’header expires. Secondo questo articolo di Google Developers, l’header HTTP Caching: Cache-Control è stato definito come parte della specifica di HTTP/1.1 e sostituisce gli header precedenti (in questo caso l’header Expires) utilizzati per definire le politiche di response caching. Tutti i browser moderni supportano Cache-Control, quindi questo è tutto ciò di cui si ha bisogno. Tuttavia, non farà male a nessuno averli entrambi, ma ricordate che ne verrà utilizzato solo uno. L’intestazione Expires utilizza una data effettiva, mentre l’intestazione Cache-Control consente di specificare un periodo di tempo prima della scadenza.
Per aggiungere l’intestazione Expires in Apache, è sufficiente aggiungere il seguente codice al file .htaccess.
## EXPIRES HEADER CACHING ##
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 7 days"
## EXPIRES HEADER CACHING ##Non dimenticate di aggiungere il blocco dell’header Expires sotto direttive come mod_rewrite, GZIP, ecc. In fondo al file è il posto più sicuro.
Per aggiungere le intestazioni Expires in NGINX, è sufficiente aggiungere il seguente codice al file di configurazione.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
}In molti casi, su NGINX, l’intestazione Cache-Control e l’intestazione Expires sono utilizzate insieme, anche se questo non è tecnicamente richiesto:
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
add_header Cache-Control "public";
}Tutte le intestazioni descritte sopra sono aggiunte di default su tutti i server di Kinsta, quindi se siete clienti di Kinsta non vedrete mai questo avviso e non dovrete quindi preoccuparvi. La maggior parte dei provider di CDN di terze parti, come KeyCDN e Cloudflare, aggiungono automaticamente questi header alla consegna delle risorse. Se vedete gli avvisi, potrebbe essere che il vostro host stia utilizzando software obsoleto o che abbia configurato male il server. Di solito, questo accade sugli host condivisi. Potrebbe anche essere che state configurando il vostro server, nel qual caso alcune delle intestazioni descritte sopra potrebbero non essere ancora state aggiunte.
E se tutto va bene, e non avete richieste di terze parti che non utilizzano correttamente l’intestazione, dovreste vedere un miglioramento del punteggio in strumenti di speed test come Pingdom (come si vede qui sotto).
