Gestisci il comportamento della cache

Firebase Hosting utilizza un potente CDN globale per rendere il tuo sito il più veloce possibile.

Qualsiasi contenuto statico richiesto viene automaticamente memorizzato nella cache del CDN . Se ridistribuisci i contenuti del tuo sito, Firebase Hosting cancella automaticamente tutti i contenuti statici memorizzati nella cache attraverso il CDN fino alla richiesta successiva.

Tuttavia, poiché i servizi Cloud Functions e Cloud Run generano contenuti in modo dinamico, i contenuti per un determinato URL possono variare in base a fattori quali l'input o l'identità dell'utente. Per tenere conto di ciò, le richieste gestite dal codice di back-end non vengono memorizzate nella cache del CDN per impostazione predefinita, ad eccezione delle richieste che restituiscono errori 404. Per cancellare i risultati 404 memorizzati nella cache, ridistribuisci Firebase Hosting; la ridistribuzione di Cloud Functions e Cloud Run non invalida automaticamente la cache.

Puoi, tuttavia, configurare il comportamento della memorizzazione nella cache per i contenuti dinamici . Ad esempio, se una funzione genera nuovi contenuti solo periodicamente, puoi velocizzare la tua app memorizzando nella cache i contenuti generati almeno per un breve periodo di tempo.

Puoi anche potenzialmente ridurre i costi di esecuzione della funzione perché il contenuto viene servito dal CDN anziché tramite una funzione attivata. Leggi ulteriori informazioni sull'ottimizzazione dell'esecuzione delle funzioni e dei servizi nella documentazione di Cloud Functions e Cloud Run .

Ulteriori informazioni sul comportamento della memorizzazione nella cache nella documentazione per sviluppatori web di Google .

Imposta il controllo della cache

Lo strumento principale utilizzato per gestire la cache per il contenuto dinamico è l'intestazione Cache-Control . Configurando questa intestazione, puoi comunicare sia al browser che al CDN per quanto tempo il tuo contenuto può essere memorizzato nella cache. Nella tua funzione, imposti Cache-Control in questo modo:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

In questa intestazione di esempio, le direttive fanno tre cose:

• public — Contrassegna la cache come public . Ciò significa che sia il browser che i server intermedi (ovvero il CDN per Firebase Hosting) possono memorizzare nella cache il contenuto.

• max-age — Indica al browser e al CDN per quanti secondi possono memorizzare nella cache il contenuto. Allo scadere del tempo impostato, il browser e il CDN devono riconvalidare il contenuto con il server di origine. Nell'intestazione di esempio, consentiamo al browser e al CDN di memorizzare nella cache il contenuto per cinque minuti (vedere s-maxage di seguito per i controlli specifici per la memorizzazione nella cache del CDN).

• s-maxage — Sostituisce la direttiva max-age solo per il caching CDN; indica al CDN per quanti secondi può memorizzare nella cache il contenuto. Allo scadere del tempo impostato, il CDN deve riconvalidare il contenuto con il server di origine. Nell'intestazione di esempio, sovrascriviamo l'impostazione per max-age solo per il CDN e consentiamo al CDN di memorizzare nella cache il contenuto per dieci minuti.

Per max-age e s-maxage , imposta i relativi valori sul periodo di tempo più lungo in cui ritieni che gli utenti ricevano contenuti obsoleti. Se una pagina cambia ogni pochi secondi, usa un piccolo valore temporale. Tuttavia, altri tipi di contenuto possono essere memorizzati nella cache in modo sicuro per ore, giorni o addirittura mesi.

Puoi saperne di più sull'intestazione Cache-Control su Mozilla Developer Network e nella documentazione per sviluppatori web di Google .

Quando viene pubblicato il contenuto memorizzato nella cache?

Il browser e il CDN memorizzano nella cache i tuoi contenuti in base a:

• Il nome host
• Il sentiero
• La stringa di query
• Il contenuto delle intestazioni della richiesta specificate nell'intestazione Vary

Varia le intestazioni

L' intestazione Vary determina quali intestazioni di richiesta devono essere utilizzate per fornire una risposta appropriata (se il contenuto memorizzato nella cache è valido o se il contenuto deve essere riconvalidato con il server di origine).

Firebase Hosting imposta automaticamente un'intestazione Vary appropriata sulla tua risposta per situazioni comuni. La maggior parte delle volte, non devi preoccuparti dell'intestazione Vary . Tuttavia, in alcuni casi d'uso avanzati, potresti avere altre intestazioni necessarie per influenzare la cache. In tal caso, puoi impostare l'intestazione Vary sulla tua risposta. Per esempio:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

In questo caso, il valore dell'intestazione Vary è:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Con queste impostazioni, due richieste altrimenti identiche con X-My-Custom-Header diverse vengono memorizzate nella cache separatamente. Tieni presente che Hosting aggiunge Cookie e Authorization all'intestazione Vary per impostazione predefinita quando viene effettuata una richiesta per contenuto dinamico. Ciò garantisce che qualsiasi intestazione di autorizzazione di sessione o cookie utilizzata sia inclusa nella chiave della cache, impedendo perdite accidentali di contenuto.

Nota anche:

• È possibile memorizzare nella cache solo le richieste GET e HEAD . Le richieste HTTPS che utilizzano altri metodi non vengono mai memorizzate nella cache.

• Prestare attenzione quando si aggiungono impostazioni all'intestazione Vary . Maggiore è il numero di impostazioni aggiunte, minore è la probabilità che il CDN possa servire contenuto memorizzato nella cache. Ricorda inoltre che Vary si basa sulle intestazioni della richiesta , non sulle intestazioni della risposta .

Utilizzo dei cookie

Quando si utilizza Firebase Hosting insieme a Cloud Functions o Cloud Run, i cookie vengono generalmente rimossi dalle richieste in arrivo. Ciò è necessario per consentire un comportamento efficiente della cache CDN. Solo il cookie __session dal nome speciale può passare attraverso l'esecuzione della tua app.

Quando presente, il cookie __session viene automaticamente reso parte della chiave di cache, il che significa che è impossibile per due utenti con cookie diversi ricevere la risposta memorizzata nella cache dell'altro. Utilizza il cookie __session solo se la tua app offre contenuti diversi a seconda dell'autorizzazione dell'utente.