A compactação dinâmica compacta automaticamente as respostas exibidas pelo Cloud CDN. O tamanho dos dados enviados pela rede é reduzido de 60% para 85% nos casos típicos.
A redução de tamanho reduz o tempo necessário para fazer o download de conteúdo. Para recursos importantes, como folhas de estilo (CSS), scripts (JavaScript) e manifestos de vídeo (HLS/DASH), é possível reduzir os tempos de carregamento da página e de início do vídeo.
Saiba mais sobre os benefícios da compactação de respostas no Guia de princípios básicos da Web.
É possível ativar a compactação em um serviço ou bucket de back-end.
Exemplos de casos de uso
A compactação dinâmica reduz diretamente o tamanho dos dados enviados da borda do Cloud CDN para o cliente. Isso pode fazer diretamente o seguinte:
- Reduzir o tamanho do CSS e do JavaScript, ajudando as páginas da Web a renderizar mais rapidamente e reduzindo o tempo de First Contentful Paint, uma métrica importante de desempenho da Web.
Ter um impacto grande e positivo ao armazenar em cache as respostas da API REST, como payloads JSON. Esses payloads são compactados corretamente devido a chaves repetidas, espaços em branco e chaves. O armazenamento em cache de APIs públicas por 5 a 10 segundos é uma abordagem conhecida para reduzir a carga de origem e manter os dados atualizados.
Mesmo sem armazenamento em cache, a compactação dessas respostas pode reduzir o total de bytes enviados em até 90%.
Melhore o horário de início da reprodução da exibição do vídeo e a latência de entrada para a transmissão ao vivo. Playlists ao vivo grandes (manifestos) têm uma quantidade significativa de dados repetidos, incluindo o host e o prefixo de caminho de cada segmento, bem como os metadados de playlist HLS ou DASH. Quanto mais rápido o download ou a atualização da playlist forem feitos, menor será o tempo de espera do cliente para a análise e o início do download dos segmentos de vídeo referenciados. As playlists HLS e DASH geralmente têm uma redução de tamanho total de mais de 90%.
Antes de começar
Verifique se você tem os recursos a seguir:
- Um back-end ativado para o Cloud CDN configurado. Se você não tiver o Cloud CDN configurado, siga um dos guias de configuração.
- Seu back-end tem conteúdo compactável pronto para ser exibido, como recursos da Web ou manifestos de vídeo entre 1 KiB e 10 MiB (incluindo esses dois valores).
- Os clientes não dependem da busca de conteúdo parcial com solicitações de intervalo ou ETags fortes. Eles são incompatíveis com a compactação dinâmica.
- Os clientes podem processar respostas sem cabeçalhos
Content-Length
. Por exemplo, as ausências no cache compactadas do Cloud CDN não têm cabeçalhosContent-Length
. - O papel de administrador do balanceador de carga do Compute (
roles/compute.loadBalancerAdmin
) do IAM, necessário para fazer alterações na configuração do back-end.
Ativar a compactação em um serviço ou bucket de back-end
Para ativar a compactação, siga estas etapas.
Console
Adicionar uma nova origem
Para adicionar e configurar uma nova origem, siga as instruções em Visão geral da configuração para o tipo apropriado de back-end. Ao criar a origem, use a seção Opções avançadas para configurar a compactação dinâmica, selecionando Automática na lista Modo de compactação.
Editar uma origem atual
Para editar uma origem atual do Cloud CDN, faça o seguinte:
No console do Google Cloud, acesse a página Origens do Cloud CDN.
Clique no nome da origem que você quer editar e em Editar.
Na seção Noções básicas sobre a origem, clique em Próxima.
Na seção Regras de host e caminho, clique em Próxima.
Na seção Desempenho do cache, navegue até Opções avançadas.
Na lista Modo de compactação, selecione Automático.
Para aplicar as alterações, clique em Concluído.
gcloud
Para serviços de back-end, use o comando gcloud compute backend-services
create
ou gcloud compute backend-services
update
com a sinalização --compression-mode
.
Para buckets de back-end, use o comando gcloud compute backend-buckets create
ou o comando gcloud compute backend-buckets update
com a sinalização --compression-mode
.
Para um novo serviço de back-end, use o comando create
:
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --compression-mode=AUTOMATIC
Para um serviço de back-end existente, use o comando update
:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --compression-mode=AUTOMATIC
Para um novo bucket de back-end, use o comando create
:
gcloud compute backend-buckets create BACKEND_BUCKET_NAME --compression-mode=AUTOMATIC
Para um bucket de back-end existente, use o comando update
:
gcloud compute backend-buckets update BACKEND_BUCKET_NAME --compression-mode=AUTOMATIC
O compression-mode
pode ser um dos seguintes:
AUTOMATIC
: usa automaticamente a melhor compactação com base no cabeçalhoAccept-Encoding
enviado pelo cliente. Na maioria dos casos, isso resulta na compressão do Brotli sendo favorecida.DISABLED
(padrão): desativa a compactação.
API
Para serviços de back-end, use o
método backendServices.insert
ou o
método backendServices.update
.
Para buckets de back-end, use o
método backendBuckets.insert
ou o
backendBuckets.update
.
Use um dos comandos a seguir:
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
Adicione o seguinte snippet ao corpo da solicitação JSON:
"compressionMode": AUTOMATIC
O compression-mode
pode ser um dos seguintes:
AUTOMATIC
(recomendado): usa automaticamente a melhor compactação com base no cabeçalhoAccept-Encoding
enviado pelo cliente. Na maioria dos casos, isso resulta na compressão do Brotli sendo favorecida.DISABLED
(padrão): desativa a compactação.
Em alguns minutos, sua configuração é propagada para todos os locais de borda. O conteúdo que pode ser compactado do back-end é compactado antes de ser entregue ao cliente.
Modos de compactação
O modo de compactação padrão é DISABLED
.
O modo AUTOMATIC
permite que o Cloud CDN escolha o melhor método de compactação com base no seguinte:
- A codificação aceita do cliente
- Proporção de compactação esperada da resposta
- Velocidade de compactação (capacidade de processamento) do Cloud CDN
O Brotli pode ter uma redução adicional de 10% a 20% no tamanho do download para a maioria dos tipos de conteúdo em relação ao gzip, com desempenho de descompactação semelhante, tornando mais rápido ao considerar o tempo de download e velocidade de descompactação no cliente.
O Cloud CDN indica o método de compactação escolhido como
gzip
ou brotli
no cabeçalho Content-Encoding
na resposta.
O Cloud CDN determina o nível de compactação para equilibrar o tamanho total do download e o custo da CPU no cliente. Níveis de compactação mais altos nem sempre beneficiam a performance, especialmente em dispositivos móveis com menor consumo de energia.
Quando o Cloud CDN compacta o conteúdo inicialmente, ele remove o
cabeçalho Content-Length
da resposta. Isso é necessário para permitir que a resposta seja veiculada o mais rápido possível, porque a duração total do conteúdo é desconhecida até que toda a resposta tenha sido compactada.
Depois que uma resposta for compactada e armazenada em cache, o Cloud CDN poderá
incluir o cabeçalho Content-Length
nas respostas subsequentes.
Para HTTP/1.1 e anteriores, o Cloud CDN usa Transfer-Encoding:
chunked
na resposta quando não usa Content-Length
.
Quando uma resposta é compactada?
Se uma solicitação tiver um cabeçalho Accept-Encoding
que liste explicitamente a compatibilidade com os algoritmos gzip ou Brotli, as respostas descompactadas exibidas do back-end (origem) com um cabeçalho Content-Type
que corresponda aos tipos de conteúdo compactáveis são compactados com gzip ou
Brotli. Se uma solicitação não tiver um cabeçalho Accept-Encoding
ou Accept-Encoding: *
, a resposta não será compactada.
Por exemplo, considerando um cabeçalho Accept-Encoding
em uma solicitação do cliente, a resposta é compactada (ou não) de acordo com as informações na tabela a seguir:
Cabeçalho da solicitação Accept-Encoding | Codificação de respostas |
---|---|
gzip, compress, br |
Brotli (br) |
deflate |
Não compactado |
deflate, gzip |
gzip |
identity |
Não compactado |
* |
Não compactado |
Tipos de conteúdo compactável
A compactação dinâmica se aplica aos seguintes tipos MIME, com base no cabeçalho de resposta HTTP Content-Type
. As respostas que não têm um cabeçalho de resposta Content-Type
não são compactadas.
Os tipos de conteúdo comuns e MIME incluem:
- Conteúdo HTML:
text/html
- Folhas de estilo:
text/css
- JavaScript:
application/javascript
- JSON:
application/json
- Playlists de HLS:
application/x-mpegURL
ouapplication/vnd.apple.mpegURL
- Manifestos DASH:
application/dash+xml
A tabela a seguir resume como o tipo MIME afeta a compressibilidade.
Tipos MIME compactáveis | |
---|---|
Correspondência exata | application/x-javascript application/x-sdch-dictionary application/javascript application/xml application/csv application/json application/json+protobuf application/signed-exchange application/vnd.apple.mpegurl application/wasm application/x-plist application/x-protobuffer application/x-protobuf application/x-nacl application/x-pnacl font/ttf font/otf font/eot image/svg+xml image/pwg-raster image/x-icon image/vnd.microsoft.icon video/vnd.mpeg.dash.mpd audio/mpegURL application/dash+xml application/vnd.ms-sstr+xml |
Correspondência de padrão | application/*+json application/*+xml application/*mpegURL text/* |
Os formatos de imagem e vídeo (como image/jpeg
, image/png
e video/mpeg4
)
já são quase sempre compactados. Portanto, o Cloud CDN não
compacta
eles. A recompactação de uma resposta já compactada raramente reduz o tamanho do arquivo,
e os clientes podem apresentar um comportamento inesperado ao receber uma resposta desse
tipo.
Quando uma resposta não é compactada?
A compactação dinâmica não compacta uma resposta que tenha uma ou mais destas características:
- A resposta não tem um cabeçalho
Content-Type
que corresponda a um tipo de conteúdo compactável. - Não tem um cabeçalho
Content-Length
. - Ele tem um cabeçalho
Content-Encoding
. É menor que 1 KiB.
O tempo gasto na compactação e descompactação geralmente compensa quaisquer benefícios. Há também menos conteúdo para compactar, o que pode reduzir a eficácia da compactação e levar a uma proporção de compactação mais baixa.
É maior que 10 MiB.
Ele tem um cabeçalho
Cache-Control: no-transform
.Ele tem um cabeçalho
Vary: Accept-Encoding
.
Solicitações de intervalo
Quando o Cloud CDN compacta uma resposta, ele
adiciona um cabeçalho Accept-Ranges: none
e substitui todos os cabeçalhos Accept-Ranges
existentes. As ocorrências em cache dessas respostas ignoram os cabeçalhos Range
.
Isso impede a exibição de conteúdo parcial incorreto aos clientes, porque não há como ter certeza de que um cliente espera um intervalo de bytes na forma compactada ou descompactada de um recurso.
ETags
Quando a compactação dinâmica compacta uma resposta, qualquer cabeçalho ETag forte é enfraquecido, conforme exigido pela seção 2.3 do RFC 7232.
Por exemplo, ETag: "xyzzy"
é substituído por ETag: W/"xyzzy"
.
Variar cabeçalho
Ao exibir uma resposta que pode ser compactada, dependendo da
solicitação, o Cloud CDN adiciona o cabeçalho Vary: Accept-Encoding
à
resposta.
Resumo das mudanças de resposta
A tabela a seguir resume as alterações que o Cloud CDN faz nos cabeçalhos de uma resposta quando ocorreu a compactação:
Cabeçalho de resposta | Valor do cabeçalho após a compactação |
---|---|
Content-Encoding | Defina como gzip ou brotli. |
ETag | Qualquer tag de entidade forte é substituída por uma versão fraca, indicada pelo prefixo W/. |
Accept-Ranges (em inglês) | Defina como o valor none. |
Content-Length | Pode ser removido completamente ou, se presente, definido de acordo com o comprimento do conteúdo do corpo compactado. |
Transfer-Encoding | Para protocolos HTTP/1.1 e mais antigos, se o Cloud CDN remover o Content-Length, ele adicionará esse cabeçalho, com o valor definido como dividido, e em blocos. o corpo da resposta. |
Geração de registros
Os registros do Cloud CDN incluem um campo compressionStatus
no
jsonPayload
que indica se a resposta foi compactada pelo balanceador de carga,
assim como o tipo de compactação.
{ insertId: "1c02hw9g3gjay67" jsonPayload: { @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" statusDetails: "response_sent_by_backend" cacheId: "IAD-862d661f" compressionStatus: "br" } }
Faturamento
Quando uma resposta é compactada pelo Cloud CDN ou pelo Cloud Load Balancing, a transferência de dados de saída do cache ou da Internet (respectivamente) é medida em relação aos bytes compactados finais enviados para o cliente.
Se você estiver veiculando uma grande quantidade de respostas compactáveis, isso pode resultar em uma redução nas taxas mensais de transferência de dados de saída, assim como no aumento do desempenho para os usuários finais.
Métricas
Quando a compactação está ativada, a métrica https/response_bytes_count
existente em loadbalancing.googleapis.com
informa o tamanho da resposta compactada.
Haverá uma queda no total de bytes de resposta (e na capacidade de transferência de dados de saída).
Se você estiver exibindo uma grande quantidade de conteúdo baseado em texto que se compacta bem, como HTML, CSS, JavaScript ou JSON, talvez haja uma grande queda nos bytes de resposta.
Para mais informações, consulte Monitoramento.
A seguir
- Para entender como os modos de cache facilitam o armazenamento em cache do conteúdo, consulte Mudar os modos de cache.
- Para ativar o Cloud CDN para instâncias HTTP(S) com carga balanceada e buckets de armazenamento, consulte Informações gerais da configuração.
- Para saber mais sobre a invalidação de caches, consulte Visão geral da invalidação de caches.
- Para encontrar pontos de presença do GFE, consulte Locais de cache.