Nel contesto di una Rete di distribuzione dei contenuti come Fastly, il valore Time-To-Live (Time-To-Live) è la quantità di tempo per cui un oggetto specifico rimarrà nella cache. Il Time-To-Live è talvolta noto anche come durata di freschezza di un oggetto perché, una volta raggiunto o superato il TTL, l'oggetto diventa obsoleto, il che significa che è probabilmente disponibile una versione più nuova e più “fresca” dell'oggetto da fornire al cliente.
Come funziona il Time-To-Live?
Ogni oggetto contiene intestazioni HTTP utilizzate per trasmettere informazioni tra il client e il server di origine nella richiesta e nella risposta. Puoi impostare determinate intestazioni HTTP nella risposta per controllare quali contenuti vengono memorizzati nella cache e il relativo Time-To-Live. Intestazioni come Cache-Control ed Expires ti consentono di determinare il tempo massimo per cui l’oggetto nella cache viene usato per rispondere alle richieste senza consultare il server di origine. Dopo la scadenza del Time-To-Live, l'oggetto può essere conservato nello storage, ma non verrà utilizzato per rispondere alle richiesta finché non potrà essere rivalidato con il server di origine.
Perché il Time-To-Live è importante?
Consegnare contenuti comporta un costo, sia in termini di costo di uscita, ovvero il costo che i provider di hosting addebitano per spostare i contenuti fuori dallo storage, sia in termini di latenza per il tuo cliente, ovvero il tempo trascorso in attesa dei tuoi contenuti.
Essere strategici con il Time-To-Live può aiutarti a gestire entrambi i costi. Ad esempio, potresti scegliere di assegnare al contenuto statico un Time-To-Live più elevato, perché in genere questo contenuto rimane relativamente invariato e non ci sarà una versione più recente nell’origine. Pensa a immagini, file CSS o JavaScript. Mantenendo questi contenuti nella cache più a lungo, riduci le richieste verso l'origine, abbattendo il costo di uscita. Inoltre, poiché il contenuto viene servito dalla cache, il tempo di latenza per i tuoi clienti si riduce.
D’altra parte, il contenuto dinamico, ovvero il contenuto che cambia a intervalli imprevedibili, dovrebbe probabilmente avere un Time-To-Live inferiore. In questo modo vengono distribuite le informazioni più aggiornate. Ad esempio, elementi come ultime notizie, contenuto generato dall'utente e inventario corrente degli articoli del negozio sono tutti tipi di contenuti che cambiano in modo imprevedibile. Impostare il giusto Time-To-Live ti aiuta a bilanciare le esigenze degli utenti con i costi della tua attività.
Migliori pratiche per Time-To-Live
Impostare il giusto Time-To-Live aiuta a trovare un equilibrio tra prestazioni, costi e disponibilità.
Un Time-To-Live più elevato significa meno richieste all’origine per contenuti “aggiornati”.
Un Time-To-Live più basso significa che l'oggetto nella cache scade più rapidamente e che gli aggiornamenti dalla cache si verificano più frequentemente.
Usa un Time-To-Live più elevato per il contenuto statico che difficilmente subirà modifiche significative: immagini, CSS, file JavaScript. Usa un Time-To-Live più basso per il contenuto dinamico che cambia a intervalli imprevedibili. Questo garantisce che gli utenti abbiano sempre contenuti aggiornati.
Poiché le Rete di distribuzione dei contenuti come Fastly non possono invalidare la cache del browser web di un utente finale, in genere eliminare gli oggetti dalla cache è più semplice, e più sotto il tuo controllo, che svuotare la cache dei browser web degli utenti. Per questo motivo, può avere senso impostare TTL diversi per i contenuti nella cache rispetto ai browser web dell'utente.
Puoi impostare TTL diversi per la cache rispetto ai browser web tramite intestazioni HTTP Surrogate-Control definite dal W3C. Usa queste intestazione HTTP per impostare un Time-To-Live lungo per gli elementi nella cache, ma un Time-To-Live più breve per l'utente che visualizza quell'oggetto in un browser web.
Time-To-Live in Fastly
Non esiste un approccio unico al caching: le esigenze di ognuno possono essere leggermente diverse. In uno scenario reale, i requisiti di caching dipendono da una varietà di fattori e hai bisogno della flessibilità di scegliere per quanto tempo memorizzare nella cache il contenuto statico rispetto al contenuto dinamico.
Poiché è così facile eseguire il purge di un servizio Fastly, sia per un singolo URL, per un gruppo di risorse con tag o per l'intera cache del servizio, puoi permetterti di impostare un Time-To-Live lungo quando salvi elementi nella cache di Fastly. Un Time-To-Live lungo aumenta il rapporto di cache hit e la reattività del sito per l'utente finale e, quando devi eseguire il purge per nuovi contenuti, in genere bastano solo pochi secondi.
Quando hai bisogno di un controllo variabile per il tuo Time-To-Live, Fastly offre diverse opzioni, tra cui:
Configurare un Time-To-Live predefinito globale, chiamato anche Time-To-Live fallback, per memorizzare nella cache tutti gli oggetti in modo coerente anche se hai più origini o applicazione server con impostazioni Time-To-Live incoerenti.
Uso delle intestazioni HTTP per controllare per quanto tempo il contenuto viene memorizzato nella cache nel browser di un utente.
Abilitazione della distribuzione di dati obsoleti nel caso in cui i contenuti scadano ma l’origine non sia raggiungibile per la riconvalida.
Cosa succederà ora
Consulta la nostra guida alle best practice per la memorizzazione nella cache per saperne di più su come diverse intestazione HTTP influiscono sul Time-To-Live e su altri comportamenti della cache.