Gerenciar o comportamento do cache

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 na CDN . Se você reimplantar o conteúdo do seu site, o Firebase Hosting limpará automaticamente todo o conteúdo armazenado 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 dados como entrada ou identidade do usuário. Para compensar isso, as solicitações tratadas pelo código de back-end não são armazenadas em cache na CDN por padrão.

No entanto, você pode configurar o comportamento de armazenamento em 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.

Da mesma forma, você pode configurar o comportamento de armazenamento em cache para reduzir potencialmente os custos de execução da função, porque o conteúdo é servido a partir do CDN e não 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 .

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 uma URL inexistente por 10 minutos, para que as solicitações subsequentes para essa URL sejam atendidas fora da CDN. Se você alterar seu serviço para que o conteúdo agora exista neste URL, o CDN continuará servindo quaisquer 404s armazenados em cache por 10 minutos (no máximo) e depois servirá o conteúdo desse URL normalmente.

Se uma resposta 404 já contiver cabeçalhos de armazenamento em cache definidos pelo serviço Cloud Functions ou Cloud Run, eles substituirão o padrão de 10 minutos e determinarão totalmente o comportamento de armazenamento em cache do CDN.

Saiba mais sobre o comportamento do cache na documentação para desenvolvedores da Web do Google.

Definir controle de cache

A principal ferramenta usada para gerenciar o cache de conteúdo dinâmico é o cabeçalho Cache-Control . Ao configurar este cabeçalho, você pode comunicar ao navegador e ao CDN por quanto tempo seu conteúdo pode ser armazenado em cache. Na 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 como public . Isso significa que tanto o navegador quanto os servidores intermediários (ou seja, o CDN para Firebase Hosting) podem armazenar o conteúdo em cache.

  • max-age — Informa ao navegador e ao CDN quantos segundos eles podem armazenar o conteúdo em cache. Quando o tempo definido expirar, o navegador e o CDN deverão revalidar o conteúdo com o servidor de origem. No cabeçalho do exemplo, permitimos que o navegador e o CDN armazenem o conteúdo em cache por cinco minutos (consulte s-maxage abaixo para obter controles específicos para cache do CDN).

  • s-maxage — Substitui a diretiva max-age apenas para cache CDN; informa ao CDN por quantos segundos ele pode armazenar o conteúdo em cache. Quando o tempo definido expirar, o CDN deverá revalidar o conteúdo com o servidor de origem. No cabeçalho do exemplo, estamos substituindo a configuração max-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 maior período de tempo em que você se sinta confortável com os usuários recebendo conteúdo desatualizado. 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 web do Google.

Quando o conteúdo em cache é veiculado?

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 armazenado 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çados, 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');

Neste 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 cabeçalhos X-My-Custom-Header diferentes 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 usado faça parte da chave de cache, o que evita vazamentos acidentais de conteúdo.

Observe também:

  • Somente solicitações GET e HEAD podem ser armazenadas em cache. Solicitações HTTPS usando 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 de o CDN servir conteúdo em cache. Lembre-se também de que Vary é 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 eficiente do cache CDN. Somente o cookie __session com nome especial pode passar para a execução do seu aplicativo.

Quando presente, o cookie __session torna-se automaticamente parte da chave de cache, o que significa que é impossível para dois usuários com cookies diferentes receberem a resposta armazenada em cache do outro. Use o cookie __session apenas se seu aplicativo exibir conteúdo diferente, dependendo da autorização do usuário.