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 estático em cache no CDN até a próxima solicitação.

No entanto, como os serviços Cloud Functions e Cloud Run geram conteúdo de maneira dinâmica, o conteúdo de um determinado URL pode variar com base em itens como entrada ou identidade do usuário. Por conta disso, as solicitações gerenciadas 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 o cache automaticamente.

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.

Outra possibilidade é a de reduzir potencialmente os custos de execução das funções, porque o conteúdo é fornecido pelo CDN e não por 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.

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.