O Cloud CDN é uma parte essencial do suporte do App Hosting ao seu app da Web. Cada solicitação para o back-end passa primeiro pelo Cloud CDN. O conteúdo que já está em cache no CDN é enviado imediatamente ao usuário, sem precisar acessar o serviço do Cloud Run que executa o código do servidor do seu app da Web. Saiba mais sobre os benefícios gerais dos CDNs em web.dev.
Embora a configuração básica do Cloud CDN seja definida por App Hosting e não possa ser modificada, há várias coisas que você pode fazer para otimizar o armazenamento em cache para aumentar a velocidade de carregamento da página, reduzir o conteúdo não armazenado em cache e minimizar o tráfego para o Cloud Run.
Conteúdo armazenável em cache
O Cloud CDN armazenará as respostas em cache se TODAS as condições a seguir forem verdadeiras:
A solicitação é GET
A resposta tem um código de status de
200
,203
,204
,206
,300
,301
,302
,307
,308
,404
,405
,410
,421
,451
ou501
.A resposta tem um cabeçalho
Cache-Control
com uma diretivamax-age
ous-maxage
ou um cabeçalhoExpires
com um carimbo de data/hora no futuro.A resposta tem um cabeçalho
Age
ouCache-Control
com uma diretivapublic
explícita.A resposta tem tamanho menor ou igual a 10 MiB.
e NENHUM dos itens a seguir é verdadeiro:
A resposta tem um cabeçalho
Set-Cookie
A resposta tem um cabeçalho
Vary
com um valor diferente deAccept
,Accept-Encoding
,Access-Control-Request-Headers
,Access-Control-Request-Method
,Origin
,Sec-Fetch-Dest
,Sec-Fetch-Mode
,Sec-Fetch-Site
,X-Goog-Allowed-Resources
,X-Origin
,RSC
,Next-Router-State-Tree
,Next-Router-Prefetch
ouNext-Router-Segment-Prefetch
.A resposta tem um cabeçalho
Cache-Control
com a diretivano-store
ouprivate
.A solicitação tem um cabeçalho
Cache-Control
com uma diretivano-store
.A solicitação tem um cabeçalho
Authorization
, a menos que a resposta tenha uma diretiva de controle de cache explícita.
Personalizar o comportamento com diretivas de controle de cache
Next.js
O Next.js define diretivas de controle de cache implicitamente com base em vários
fatores. No entanto, é possível
substituí-los definindo o cabeçalho manualmente no
arquivo next.config.js
. Por exemplo, para garantir que uma página não seja
armazenada em cache no Cloud CDN:
/** @type {import('next').NextConfig} */
const nextConfig = {
headers: async () => [{
source: "/YOUR_PRIVATE_PAGE",
headers: [{
key: "Cache-Control",
value: "private"
}],
}],
};
Angular
O SSR do Angular não define diretivas explícitas de controle de cache. Você pode adicionar o seu próprio especificando cabeçalhos de controle de cache nas rotas do servidor. Por exemplo, para permitir que o Cloud CDN armazene em cache todas as páginas por uma hora:
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
path: '**',
renderMode: RenderMode.Prerender,
headers: {
'Cache-Control': 'public, max-age=3600',
}
}
];
Ou para garantir que uma página específica não seja armazenada em cache:
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
// ... other routes
{
path: 'YOUR_PRIVATE_PAGE',
renderMode: RenderMode.Server,
headers: {
'Cache-Control': 'private',
}
}
];
Diretivas respeitadas
A instância do Cloud CDN do Firebase App Hosting respeita as seguintes diretivas de controle de cache:
Diretiva | Solicitação | Resposta |
---|---|---|
no-store |
Quando presente em uma solicitação, a resposta não será armazenada em cache. | Uma resposta com no-store não é armazenada em cache. |
no-cache |
A diretiva de solicitação no-cache é ignorada para evitar que os clientes iniciem ou forcem a revalidação para a origem. |
Uma resposta com no-cache é armazenada em cache, mas precisa ser revalidada com a origem antes de ser veiculada. |
public |
N/A | Essa diretiva não é necessária para armazenamento em cache, mas é uma prática recomendada incluí-la para conteúdo que precisa ser armazenado em cache por proxies. |
private |
N/A | Uma resposta com a diretiva private não é armazenada em cache pelo Cloud CDN, mesmo que a resposta seja considerada armazenável em cache. Os clientes (como navegadores) ainda podem armazenar o resultado em cache. Use no-store para evitar todo o armazenamento em cache das respostas. |
max-age=SECONDS |
A diretiva de solicitação max-age é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação. |
Uma resposta com a diretiva max-age é armazenada em cache até o SECONDS definido. |
s-maxage=SECONDS |
N/A | Uma resposta com a diretiva s-maxage é armazenada em cache até o SECONDS definido. Se max-age e s-maxage estiverem presentes, o s‑maxage será usado pelo Cloud CDN. As respostas com essa diretiva não são exibidas. s-max-age (dois hifens) não é válido para fins de armazenamento em cache. |
max-stale=SECONDS |
A diretiva de solicitação max-stale determina a inatividade máxima (em segundos) que o cliente está disposto a aceitar. O Cloud CDN respeita isso e retorna uma resposta em cache desatualizada somente se a inatividade da resposta for menor que a diretiva max-stale . Caso contrário, ele será revalidado antes de atender à solicitação. |
N/A |
stale-while-revalidate=SECONDS |
N/A | Uma resposta com stale-while-revalidate é enviada a um cliente por até SEGUNDOS, enquanto a revalidação ocorre de forma assíncrona. |
must-revalidate |
N/A | Uma resposta com must-revalidate é revalidada com o servidor de origem após a expiração. As respostas com essa diretiva não são exibidas. |
proxy-revalidate |
Uma resposta com proxy-revalidate é revalidada com o servidor de origem após a expiração. As respostas com essa diretiva não são exibidas. |
|
no-transform |
N/A | Nenhuma transformação é aplicada pelo Cloud CDN. |
Medir o tráfego armazenado em cache e sem cache
O gráfico "Largura de banda de saída da Cloud CDN" na guia Usage do console App Hosting mostra os bytes armazenados em cache e não armazenados em cache que foram servidos e tem uma marca para cada lançamento. Use esse gráfico para medir a eficácia dos seus esforços de otimização do cache.