Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Gerenciar o comportamento do cache

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Firebase Hosting usa um poderoso CDN global para tornar seu site o mais rápido possível.

Qualquer conteúdo estático solicitado é armazenado em cache automaticamente na CDN . Se você reimplantar o conteúdo do seu site, o Firebase Hosting limpará automaticamente todo o conteúdo estático armazenado em cache na CDN até a próxima solicitação.

No entanto, como os serviços do Cloud Functions e do Cloud Run geram conteúdo dinamicamente, o conteúdo de um determinado URL pode variar com base em informações do usuário ou na 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.

Você pode, no entanto, configurar o comportamento de cache para conteúdo dinâmico . Por exemplo, se uma função gerar novo conteúdo apenas periodicamente, você poderá 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 é veiculado a partir da CDN em vez de 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 à 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 o conteúdo em cache.

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

  • s-maxage — Substitui a diretiva max-age somente para o armazenamento em cache da CDN; informa ao CDN quantos segundos ele pode armazenar em cache o conteúdo. Quando o tempo definido expirar, o CDN deverá revalidar o conteúdo com o servidor de origem. No cabeçalho de exemplo, estamos substituindo a configuração de 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 sente 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 saber 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 é veiculado?

O navegador e a CDN armazenam seu conteúdo em cache 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 na 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');

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 cabeçalho de autorização de sessão ou cookie usado faça parte da chave de cache, o que evita vazamentos acidentais de conteúdo.

Observe também:

  • Apenas solicitações GET e HEAD podem ser armazenadas em cache. As 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 a CDN veicular conteúdo em cache. Lembre-se também de que o Vary é baseado em cabeçalhos de solicitação , não em cabeçalhos de resposta .

Usando cookies

Ao usar o Firebase Hosting junto com o Cloud Functions ou o Cloud Run, os cookies geralmente são removidos das solicitações recebidas. Isso é necessário para permitir um comportamento de cache CDN eficiente. Apenas o cookie __session com nome especial tem permissão para passar para a execução do 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 veicular conteúdo diferente dependendo da autorização do usuário.