获取我们在 Firebase 峰会上发布的所有信息，了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

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 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 como public . 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 (consulte s-maxage abaixo para obter os controles específicos para o armazenamento em cache do CDN).

  • s-maxage — Substitui a diretiva max-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çã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 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 e HEAD 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 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 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.