Gerenciar o comportamento do cache

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 da 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 como public. 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. Consulte s-maxage abaixo para receber controles específicos para o armazenamento em cache do CDN.

  • s-maxage: modifica a diretiva max-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 de max-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 da 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 e HEAD 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 que Vary é 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.