O Firebase Hosting usa um poderoso CDN global para tornar seu site o mais rápido possível.
Qualquer conteúdo estático solicitado é automaticamente armazenado em cache no CDN . Se você reimplantar o conteúdo do seu site, o Firebase Hosting limpa automaticamente todo o conteúdo estático em cache na CDN até a próxima solicitação.
No entanto, como os serviços Cloud Functions e Cloud Run geram conteúdo dinamicamente, o conteúdo de um determinado URL pode variar com base em itens como a entrada do usuário ou a identidade do usuário. Para explicar isso, as solicitações tratadas pelo código de back-end não são armazenadas em cache na CDN por padrão, com exceção das solicitações que retornam erros 404. Para limpar os resultados 404 em cache, reimplante o Firebase Hosting; a reimplantação do Cloud Functions e do Cloud Run não invalida automaticamente o cache.
Você pode, no entanto, configurar o comportamento de cache para conteúdo dinâmico . Por exemplo, se uma função gera novo conteúdo apenas periodicamente, você pode acelerar seu aplicativo armazenando em cache o conteúdo gerado por pelo menos um curto período de tempo.
Você também pode reduzir potencialmente os custos de execução da função porque o conteúdo é servido a partir do CDN, e não por meio de uma função acionada. Leia mais sobre como otimizar a execução de funções e serviços na documentação do Cloud Functions e do Cloud Run .
Saiba mais sobre o comportamento de armazenamento em cache na documentação do desenvolvedor da Web do Google.
Definir controle de cache
A principal ferramenta que você usa para gerenciar o cache para conteúdo dinâmico é o cabeçalho Cache-Control
. Ao configurar esse cabeçalho, você pode comunicar ao navegador e ao CDN por quanto tempo seu conteúdo pode ser armazenado em cache. Em sua função, você define Cache-Control
assim:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
Neste cabeçalho de exemplo, as diretivas fazem três coisas:
public
— Marca o cache comopublic
. Isso significa que tanto o navegador quanto os servidores intermediários (ou seja, o CDN para Firebase Hosting) podem armazenar em cache o conteúdo.max-age
— Informa ao navegador e ao CDN quantos segundos eles podem armazenar em cache o conteúdo. Quando o tempo definido expirar, o navegador e o CDN devem revalidar o conteúdo com o servidor de origem. No cabeçalho de exemplo, estamos permitindo que o navegador e o CDN armazenem o conteúdo em cache por cinco minutos (consultes-maxage
abaixo para obter os controles específicos para o armazenamento em cache do CDN).s-maxage
— Substitui a diretivamax-age
apenas para o cache CDN; informa ao CDN quantos segundos ele pode armazenar em cache o conteúdo. Quando o tempo definido expirar, o CDN deve revalidar o conteúdo com o servidor de origem. No cabeçalho de exemplo, estamos substituindo a configuraçãomax-age
apenas para o CDN e permitindo que o CDN armazene o conteúdo em cache por dez minutos.
Para max-age
e s-maxage
, defina seus valores para o período de tempo mais longo que você se sentir confortável com os usuários recebendo conteúdo obsoleto. Se uma página mudar a cada poucos segundos, use um valor de tempo pequeno. No entanto, outros tipos de conteúdo podem ser armazenados em cache com segurança por horas, dias ou até meses.
Você pode aprender mais sobre o cabeçalho Cache-Control
na Mozilla Developer Network e na documentação do desenvolvedor da web do Google .
Quando o conteúdo em cache é exibido?
O navegador e o CDN armazenam em cache seu conteúdo com base em:
- O nome do host
- O caminho
- A string de consulta
- O conteúdo dos cabeçalhos de solicitação especificados no cabeçalho
Vary
Variar cabeçalhos
O cabeçalho Vary
determina quais cabeçalhos de solicitação devem ser usados para fornecer uma resposta apropriada (se o conteúdo em cache é válido ou se o conteúdo deve ser revalidado com o servidor de origem).
O Firebase Hosting define automaticamente um cabeçalho Vary
apropriado em sua resposta para situações comuns. Na maioria das vezes, você não precisa se preocupar com o cabeçalho Vary
. No entanto, em alguns casos de uso avançado, você pode ter outros cabeçalhos necessários para afetar o cache. Quando for esse o caso, você pode definir o cabeçalho Vary
em sua resposta. Por exemplo:
res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');
Nesse caso, o valor do cabeçalho Vary
é:
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
Com essas configurações, duas solicitações idênticas com diferentes cabeçalhos X-My-Custom-Header
são armazenadas em cache separadamente. Observe que o Hosting adiciona Cookie
e Authorization
ao cabeçalho Vary
por padrão quando uma solicitação é feita para conteúdo dinâmico. Isso garante que qualquer sessão ou cabeçalho de autorização de cookie que você usar seja parte da chave de cache, o que evita vazamentos acidentais de conteúdo.
Observe também:
Somente solicitações
GET
eHEAD
podem ser armazenadas em cache. As solicitações HTTPS que usam outros métodos nunca são armazenadas em cache.Tenha cuidado ao adicionar configurações ao cabeçalho
Vary
. Quanto mais configurações você adicionar, menos provável será que o CDN possa servir conteúdo em cache. Lembre-se também de queVary
é baseado em cabeçalhos de solicitação , não em cabeçalhos de resposta .
Usando cookies
Ao usar o Firebase Hosting junto com Cloud Functions ou Cloud Run, os cookies geralmente são removidos das solicitações recebidas. Isso é necessário para permitir um comportamento de cache CDN eficiente. Somente o cookie __session
com nome especial tem permissão para passar para a execução de seu aplicativo.
Quando presente, o cookie __session
-se automaticamente parte da chave de cache, o que significa que é impossível para dois usuários com cookies diferentes receberem a resposta em cache do outro. Use o cookie __session
apenas se seu aplicativo oferecer conteúdo diferente, dependendo da autorização do usuário.