O Firebase Hosting usa uma rede global de fornecimento de conteúdo (CDN) avançada para tornar seu site o mais rápido possível.
Qualquer conteúdo estático solicitado é automaticamente armazenado em cache no CDN. Se você implantar novamente o conteúdo do site, o Firebase Hosting limpará automaticamente todo conteúdo em cache no 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 entrada ou identidade do usuário. Para compensar isso, as solicitações tratadas pelo código de back-end não fazem armazenamento em cache no CDN, por padrão.
No entanto, é possível configurar o comportamento de cache para conteúdo dinâmico. Por exemplo, se uma função gerar um novo conteúdo apenas periodicamente, é possível acelerar o aplicativo, basta armazenar em cache o conteúdo gerado por um curto período de tempo, no mínimo.
Da mesma forma, é possível configurar o comportamento de armazenamento em cache para reduzir os custos de execução da função porque o conteúdo é veiculado a partir da CDN em vez de uma função acionada. Saiba mais sobre como otimizar a execução de funções e serviços na documentação do Cloud Functions e do Cloud Run.
A exceção são as solicitações que retornam erros 404. A CDN armazena em cache a resposta 404 do seu serviço para um URL inexistente por 10 minutos. Assim, as solicitações subsequentes para esse URL são exibidas fora da CDN. Se você alterar seu serviço para que o conteúdo agora exista nesse URL, a CDN continuará veiculando os erros 404s armazenados em cache por no máximo 10 minutos e depois exibirá o conteúdo desse URL normalmente.
Se uma resposta 404 já contiver cabeçalhos de armazenamento em cache definidos pelo serviço do Cloud Functions ou do Cloud Run, eles vão substituir o padrão de 10 minutos e determinar totalmente o comportamento do armazenamento em cache da CDN.
Saiba mais sobre o comportamento de armazenamento em cache na documentação do desenvolvedor Web do Google.
Definir o Cache-Control
A principal ferramenta usada para gerenciar o cache de conteúdo dinâmico é o cabeçalho Cache-Control
. Ao configurar esse cabeçalho, é possível se comunicar
com o navegador e com o CDN por quanto tempo seu conteúdo poder ser armazenado em cache. Na sua função,
você define Cache-Control
da seguinte maneira:
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 o navegador e os servidores intermediários, ou seja, o CDN para Firebase Hosting, podem armazenar em cache o conteúdo.max-age
: informa ao navegador e à CDN por quantos segundos eles podem armazenar o conteúdo em cache. Quando o tempo definido expirar, o navegador e o CDN devem revalidar o conteúdo com o servidor de origem. No cabeçalho do exemplo, permitimos que o navegador e o CDN armazenem em cache o conteúdo por cinco minutos. Consultes-maxage
abaixo para receber controles específicos para o armazenamento em cache do CDN.s-maxage
: modifica a diretivamax-age
apenas para o armazenamento em cache da CDN, além de informar à CDN por quantos segundos ela 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 do exemplo, estamos substituindo a configuração demax-age
apenas para a CDN e permitindo que a CDN armazene em cache por dez minutos o conteúdo.
Para max-age
e s-maxage
, defina os valores para o período mais longo
que você quer que os usuários recebam conteúdo desatualizado. Se uma página mudar
a cada poucos segundos, use um valor de tempo menor. No entanto, outros tipos de conteúdo podem
ser armazenados em cache por horas, dias ou até mesmo meses.
Saiba mais sobre o cabeçalho Cache-Control
no
Mozilla Developer Network
e na
documentação do desenvolvedor Web do Google.
Quando o conteúdo em cache é entregue?
O navegador e o CDN armazenam em cache seu conteúdo com base nos seguintes itens:
- nome do host;
- no caminho;
- na string de consulta;
- o conteúdo dos cabeçalhos de solicitação especificados no cabeçalho
Vary
Cabeçalhos Vary
O
cabeçalho Vary
determina quais cabeçalhos de solicitação têm ser usados para fornecer uma resposta
apropriada, isto é, se o conteúdo armazenado em cache é válido ou se o conteúdo precisa ser
revalidado com o servidor de origem.
O Firebase Hosting define automaticamente um cabeçalho Vary
apropriado na sua
resposta para situações comuns. Na maioria das vezes, você não precisa se preocupar com o cabeçalho Vary
. Em alguns casos de uso avançado, talvez você precise de outros cabeçalhos para afetar
o cache. Quando esse for o caso, defina o cabeçalho Vary
na sua
resposta. 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
Nessas configurações, duas solicitações idênticas com cabeçalhos X-My-Custom-Header
diferentes são armazenadas em cache separadamente. 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 cabeçalho de autorização de sessão
ou cookie que você use seja parte da chave de cache, o que evita vazamentos acidentais
de conteúdo.
Outras observações:
Apenas solicitações
GET
eHEAD
podem ser armazenadas em cache. 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, menor será a probabilidade do CDN exibir conteúdo armazenado em cache. Lembre-se também de queVary
é baseado em cabeçalhos de solicitação, não em cabeçalhos de resposta.
Como usar cookies
Ao usar o Firebase Hosting com o Cloud Functions,
os cookies geralmente são removidos das solicitações recebidas. Isso
é necessário para que o comportamento de cache da CDN seja eficiente.
Somente o cookie __session
com nome especial tem permissão para passar chegar à
execução do app.
Quando presente, o cookie __session
se torna automaticamente parte da chave
de cache. Isso significa que é impossível que dois usuários com cookies diferentes
recebam a resposta em cache do outro. Use o cookie __session
somente se o
app exibir conteúdo diferente, dependendo da autorização do usuário.