Lunedì 9 dicembre 2024
Lasciateci memorizzare nella cache, per favore.
Man mano che internet è cresciuto nel corso degli anni, è aumentata anche la quantità di dati sottoposti a scansione da parte di Google. Sebbene l'infrastruttura di scansione di Google abbia sempre supportato meccanismi di memorizzazione nella cache euristica, il numero di richieste che possono essere restituite dalle cache locali è diminuito: 10 anni fa circa lo 0,026% del totale dei recuperi era memorizzabile nella cache, che non è un dato particolarmente impressionante; oggi invece è dello 0,017%.
Perché la memorizzazione nella cache è importante?
La memorizzazione nella cache è un elemento fondamentale del grande puzzle di internet; consente di caricare le pagine a grandi velocità durante le visite ripetute, consente di risparmiare risorse di calcolo e quindi anche risorse naturali, e consente di risparmiare una quantità enorme di costosa larghezza di banda sia per i client che per i server.
In particolare, se avete un sito di grandi dimensioni con contenuti che cambiano raramente in singoli URL, consentire la memorizzazione nella cache a livello locale potrebbe contribuire a eseguire la scansione del vostro sito in modo più efficiente. L'infrastruttura di scansione di Google supporta la memorizzazione nella cache HTTP basata su regole come definita dallo standard HTTP Caching, in particolare tramite l'intestazione della risposta ETag e della richiesta If-None-Match e l'intestazione della risposta Last-Modified e della richiesta If-Modified-Since.
Consigliamo vivamente di utilizzare ETag perché è meno soggetta a errori e sbagli (il valore non è strutturato, a differenza di Last-Modified). Se avete la possibilità, configuratele entrambe: internet vi ringrazierà. Forse.
Sta a voi decidere cosa considerare una modifica che richiede ai client di aggiornare le cache. Vi consigliamo di richiedere un aggiornamento della cache in caso di modifiche significative ai vostri contenuti. Se avete aggiornato solo la data del copyright in fondo alla pagina, probabilmente non si tratta di una modifica importante.
ETag e If-None-Match
I crawler di Google supportano le richieste condizionali basate su ETag esattamente come definito nello
standard di memorizzazione nella cache HTTP.
In altre parole, per indicare la preferenza di memorizzazione nella cache ai crawler di Google, impostate il valore Etag su qualsiasi
stringa ASCII arbitraria (di solito un hash dei contenuti o il numero di versione, ma potrebbe anche essere una
parte del pi greco, a voi la scelta) univoca per la rappresentazione dei contenuti ospitati dall'URL a cui si accede.
Ad esempio, se ospitate versioni diverse degli stessi contenuti nello stesso URL (ad esempio, versione mobile e desktop), ogni versione potrebbe avere un proprio valore ETag univoco.
I crawler di Google che supportano la memorizzazione nella cache invieranno il valore ETag restituito per una precedente scansione dell'URL in If-None-Match header. Se il valore ETag
inviato dal crawler corrisponde al valore corrente generato dal server, il server deve
restituire un codice di stato HTTP 304 (Not modified) senza corpo HTTP. Quest'ultima parte, ovvero l'assenza di un corpo HTTP, è la parte importante per due motivi:
- il server non deve utilizzare risorse di calcolo per la generazione effettiva dei contenuti, il che ancora una volta comporta un risparmio in termini monetari
- il server non deve trasferire il corpo HTTP, il che comporta un risparmio in termini monetari
Su lato client, ad esempio nel browser di un utente o in Googlebot, i contenuti presenti a quell'URL vengono recuperati dalla cache interna del client. Poiché non è necessario trasferire dati, l'operazione avviene molto rapidamente, rendendo felici gli utenti e potenzialmente risparmiando anche alcune risorse.
Last-Modified e If-Modified-Since
Analogamente a ETag, i crawler di Google supportano anche le richieste condizionali Last-Modified based, esattamente come definito nello standard HTTP Caching. Funziona allo stesso modo
di ETag dal punto di vista semantico: un identificatore viene utilizzato per decidere
se la risorsa è memorizzabile nella cache e offre gli stessi vantaggi di ETag su
lato client.
Ecco un paio di consigli se utilizzate Last-Modified come istruzione di memorizzazione nella cache:
-
La data nell'intestazione
Last-Modifieddeve essere formattata in base allo standard HTTP. Per evitare problemi di analisi, vi consigliamo di utilizzare il seguente formato della data: "Giorno della settimana, DD Mon YYYY HH:MM:SS fuso orario". Ad esempio, "Fri, 4 Sep 1998 19:15:56 GMT". -
Sebbene non sia obbligatorio, vi consigliamo di impostare anche il campo
max-agedell'intestazioneCache-Controlper aiutare i crawler a determinare quando eseguire nuovamente la scansione dell'URL specifico. Impostate il valore del campomax-agesul numero di secondi previsto per cui i contenuti rimangono invariati. Ad esempio,Cache-Control: max-age=94043.
Esempi
Se siete come me, non è semplice comprendere bene come funziona la memorizzazione nella cache euristica, tuttavia può essere utile un esempio della catena di richieste e risposte. Ecco due catene, una per ETag/If-None-Match e una per Last-Modified/If-Modified-Since, per visualizzare come dovrebbe funzionare:
ETag/If-None-Match |
Last-Modified/If-Modified-Since |
|
|---|---|---|
La risposta di un server a una scansione: si tratta della risposta da cui un crawler può salvare i campi di precondizione dell'intestazione ETag e Last-Modified.
|
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT ETag: "34aa387-d-1568eb00" ... |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT Cache-Control: max-age=94043 ... |
Richiesta condizionale del crawler successiva: la richiesta condizionale si basa sui valori delle intestazioni della precondizione salvati da una richiesta precedente. I valori vengono inviati nuovamente al
server per la convalida nelle intestazioni della richiesta If-None-Match e If-Modified-Since.
|
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-None-Match: "34aa387-d-1568eb00" ... |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Risposta del server alla richiesta condizionale: poiché i valori delle intestazioni della precondizione inviati dal crawler vengono convalidati lato server, il server restituisce al crawler un codice di stato HTTP 304 (senza un corpo HTTP). Questo accade a ogni richiesta successiva fino a quando le precondizioni non vengono convalidate (la data di ETag o Last-Modified cambia su lato server).
|
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:52 GMT Vary: Accept-Encoding If-None-Match: "34aa387-d-1568eb00" ... |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:51 GMT Vary: Accept-Encoding If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Se il vostro obiettivo è rendere felici i vostri utenti e magari volete anche risparmiare qualche euro sulla fattura dell'hosting, rivolgetevi al vostro provider di hosting o CMS o ai vostri sviluppatori per sapere come attivare la memorizzazione nella cache HTTP per il sito. Se non altro, gli utenti vi apprezzeranno un po' di più.
Se volete parlare di memorizzazione nella cache, rivolgetevi alla community di assistenza di Search Central più vicina e, se avete commenti sulle nostre modalità di memorizzazione nella cache, lasciate un feedback sulla documentazione relativa alla memorizzazione nella cache che abbiamo pubblicato insieme a questo post del blog.