If you are building server-rendered Angular or Next.js apps, check out next-generation Firebase App Hosting, a full-stack solution for modern web frameworks.

Questa pagina è stata tradotta dall'API Cloud Translation.

Gestisci il comportamento della cache

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

Qualsiasi contenuto statico richiesto viene automaticamente memorizzato nella cache sulla CDN. Se esegui di nuovo il deployment dei contenuti del tuo sito, Firebase Hosting cancella automaticamente tutti i contenuti memorizzati nella cache nella CDN fino alla richiesta successiva.

Tuttavia, poiché i servizi Cloud Functions e Cloud Run generano contenuti in modo dinamico, i contenuti di un determinato URL possono variare in base a fattori quali l'input dell'utente o la sua identità. Per tenere conto di questo, le richieste gestite dal codice di backend non vengono memorizzate nella cache sulla CDN per impostazione predefinita.

Tuttavia, puoi configurare il comportamento di 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 per almeno un breve periodo di tempo.

Allo stesso modo, puoi configurare il comportamento di memorizzazione nella cache per ridurre potenzialmente i costi di esecuzione della funzione, perché i contenuti vengono pubblicati dalla CDN anziché da una funzione attivata. Scopri di più sull'ottimizzazione dell'esecuzione di funzioni e servizi nella documentazione di Cloud Functions e Cloud Run.

L'eccezione riguarda le richieste che restituiscono errori 404. La CDN memorizza nella cache la risposta 404 del tuo servizio a un URL inesistente per 10 minuti, in modo che le richieste successive per quell'URL vengano gestite dalla CDN. Se modifichi il servizio in modo che i contenuti ora si trovino a questo URL, la CDN continua a pubblicare eventuali errori 404 memorizzati nella cache per 10 minuti (al massimo), dopodiché pubblica normalmente i contenuti da quell'URL.

Se una risposta 404 contiene già intestazioni di memorizzazione nella cache impostate dal tuo servizio Cloud Functions o Cloud Run, queste sostituiscono il valore predefinito di 10 minuti e determinano completamente il comportamento di memorizzazione nella cache della CDN.

Scopri di più sul comportamento di memorizzazione nella cache nella documentazione per gli sviluppatori web di Google.

Imposta Cache-Control

Lo strumento principale che utilizzi per gestire la cache dei contenuti dinamici è l'intestazione Cache-Control. Configurando questa intestazione, puoi comunicare sia al browser sia alla CDN per quanto tempo i tuoi contenuti possono essere memorizzati nella cache. Nella tua funzione, imposti Cache-Control nel seguente modo:

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

In questa intestazione di esempio, le direttive svolgono tre funzioni:

public: contrassegna la risposta come public. Ciò significa che sia il browser che le cache intermedie (inclusa la CDN per Firebase Hosting) possono memorizzare nella cache i contenuti.

Nota: per impostazione predefinita, Firebase Hosting imposta Cache-Control su private per i contenuti dinamici. Ciò significa che se non imposti esplicitamente Cache-Control su public, solo il browser dell'utente che ha richiesto il contenuto può memorizzarlo nella cache.
max-age: imposta l'età massima in secondi di una risposta prima che debba essere convalidata nuovamente con il server di origine. Ciò vale per i browser; se non è presente l'intestazione s-maxage, vale anche per tutte le altre cache (inclusa la CDN).
s-maxage: esegue l'override dell'istruzione max-age per le cache condivise (ad esempio la CDN). Quando la CDN trova una risposta più vecchia di s-maxage secondi, la CDN la convalida nuovamente con il server di origine. Nell'intestazione di esempio, i browser possono memorizzare nella cache la risposta per 5 minuti, ma la CDN e qualsiasi altra cache intermedia possono memorizzarla nella cache per 10 minuti.

Per max-age e s-maxage, imposta i valori sul periodo di tempo più lungo che ritieni accettabile per gli utenti che ricevono contenuti obsoleti. Se una pagina cambia ogni pochi secondi, utilizza un valore di tempo ridotto. Tuttavia, altri tipi di contenuti possono essere memorizzati nella cache in modo sicuro per ore, giorni o persino mesi.

Se vuoi impedire completamente la memorizzazione nella cache (ad esempio, per pubblicare sempre la versione più recente dei contenuti statici), puoi configurare questa impostazione in firebase.json utilizzando l'impostazione headers:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

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

Quando vengono pubblicati i contenuti memorizzati nella cache?

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

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

Intestazioni Vary

L'intestazione Vary determina quali intestazioni della richiesta devono essere utilizzate per fornire una risposta appropriata (se i contenuti memorizzati nella cache sono validi o se devono essere convalidati nuovamente con il server di origine).

Firebase Hosting imposta automaticamente un'intestazione Vary appropriata nella tua risposta per le situazioni comuni. Il più delle volte non devi preoccuparti dell'intestazione Vary. Tuttavia, in alcuni casi d'uso avanzati, potresti avere altre intestazioni che devono influire sulla cache. In questo caso, puoi impostare l'intestazione Vary nella risposta. Ad 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 intestazioni 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 di contenuti dinamici. In questo modo, qualsiasi intestazione di autorizzazione di sessione o cookie utilizzata viene inclusa nella chiave cache, il che impedisce perdite accidentali di contenuti.

Tieni presente anche:

È possibile memorizzare nella cache solo le richieste GET e HEAD. Le richieste HTTPS che utilizzano altri metodi non vengono mai memorizzate nella cache.
Fai attenzione quando aggiungi impostazioni all'intestazione Vary. Più impostazioni aggiungi, meno è probabile che la CDN possa pubblicare contenuti memorizzati nella cache. Ricorda inoltre che Vary si basa sulle intestazioni delle richieste, non su quelle delle risposte.

Utilizzo dei cookie

Quando utilizzi Firebase Hosting insieme a Cloud Functions o Cloud Run, i cookie vengono generalmente rimossi dalle richieste in entrata. Questo è necessario per consentire un comportamento della cache della CDN efficiente. Solo il cookie __session con nome speciale può essere trasferito all'esecuzione dell'app.

Se presente, il cookie __session viene automaticamente incluso nella chiave della 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 pubblica contenuti diversi a seconda dell'autorizzazione utente.