Ativar a compactação dinâmica

A compactação dinâmica compacta automaticamente as respostas disponibilizadas pelo Cloud CDN. O tamanho dos dados enviados pela rede é reduzido de 60% para 85% nos casos típicos.

A redução de tamanho diminui o tempo necessário para baixar conteúdo. Em recursos importantes, como folhas de estilo (CSS), scripts (JavaScript) e manifestos de vídeo (HLS/DASH), é possível reduzir os tempos de carregamento de página e de inicialização de vídeo.

Saiba mais sobre os benefícios da compactação de respostas no Guia de fundamentos da Web.

É possível ativar a compactação em um serviço de back-end ou em um 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 de performance importante 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ço em branco e chaves. Armazenar em cache 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 de vídeo e a latência de entrada para 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 carregamento ou a atualização da playlist, menor será o tempo de espera do cliente para analisar e iniciar o download dos segmentos de vídeo referenciados. As playlists HLS e DASH muitas vezes têm uma redução de tamanho total de mais de 90%.

Antes de começar

Verifique se:

  • Você tem um back-end ativado para Cloud CDN configurado. Se o Cloud CDN não estiver configurado, siga um dos guias de configuração.
  • O back-end tem conteúdo compactável pronto para ser disponibilizado, como recursos da Web ou manifestos de vídeo entre 1 KiB e 10 MiB (inclusive).
  • 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 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çalhos Content-Length.
  • Você tem o papel de admin 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 de back-end 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ático na lista Modo de compactação .

Editar uma origem atual

Para editar uma origem atual do Cloud CDN, faça o seguinte:

  1. No console do Google Cloud , acesse a página Origens do Cloud CDN.

    Acesse Origens

  2. Clique no nome da origem que você quer editar e em Editar.

  3. Na seção Noções básicas sobre origem, clique em Avançar.

  4. Na seção Regras de host e caminho, clique em Avançar.

  5. Na seção Desempenho do cache, navegue até Opções avançadas.

  6. Na lista Modo de compactação, selecione Automático.

  7. Para aplicar as alterações, clique em Concluído.

gcloud

Em serviços de back-end, use o comando gcloud compute backend-services create ou o comando gcloud compute backend-services update com a sinalização --compression-mode.

Em 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.

Em um novo serviço de back-end, use o comando create:

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

Em um serviço de back-end atual, use o comando update:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --compression-mode=AUTOMATIC

Em um novo bucket de back-end, use o comando create:

gcloud compute backend-buckets create BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

Em um bucket de back-end atual, use o comando update:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME
    --compression-mode=AUTOMATIC

O compression-mode poderá ser um dos seguintes:

  • AUTOMATIC: usa automaticamente a melhor compactação com base no cabeçalho Accept-Encoding enviado pelo cliente. Na maioria dos casos, isso resulta no favorecimento da compactação Brotli.
  • 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 método backendBuckets.update.

Use um dos seguintes comandos:

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 poderá ser um dos seguintes:

  • AUTOMATIC (recomendado): usa automaticamente a melhor compactação com base no cabeçalho Accept-Encoding enviado pelo cliente. Na maioria dos casos, isso resulta no favorecimento da compactação Brotli.
  • DISABLED (padrão): desativa a compactação.

Em alguns minutos, sua configuração se propaga para todos os locais de borda. O conteúdo que pode ser compactado que é disponibilizado pelo back-end é compactado antes de ser enviado 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-o de uma forma geral mais rápido ao considerar o tempo de download e a 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 o desempenho, especialmente em dispositivos móveis com menor consumo de energia.

Quando o Cloud CDN inicialmente compacta o conteúdo, ele remove o cabeçalho Content-Length da resposta. Isso é necessário para permitir que a resposta seja disponibilizada 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 tiver sido 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 o suporte aos algoritmos gzip ou Brotli, as respostas descompactadas disponibilizadas do back-end (origem) com um cabeçalho Content-Type que corresponder aos tipos de conteúdo compactáveis serão compactadas com gzip ou Brotli adequadamente. Se uma solicitação não tiver um cabeçalho Accept-Encoding ou se tiver 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 da seguinte tabela:

Cabeçalho da solicitação Accept-Encoding Codificação da resposta
gzip, compress, br Brotli (br)
deflate Não compactada
deflate, gzip gzip
identity Não compactada
* Não compactada

Tipos de conteúdo compactável

A compactação dinâmica se aplica aos tipos MIME a seguir, com base no cabeçalho de resposta HTTP Content-Type. 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 os tipos MIME incluem:

  • Conteúdo HTML: text/html
  • Folhas de estilo: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • Playlists de HLS: application/x-mpegURL ou application/vnd.apple.mpegURL
  • Manifestos DASH: application/dash+xml

A tabela a seguir resume como o tipo MIME afeta a capacidade de compactação.

  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 os compacta. 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 muitas vezes compensa quaisquer benefícios. Há também menos conteúdo para compactar, o que pode reduzir a eficácia da compactação e ocasionar uma proporção de compactação mais baixa.

  • É maior que 10 MiB.

  • Ela tem um cabeçalho Cache-Control: no-transform.

  • Ela 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. As ocorrências em cache dessas respostas ignoram os cabeçalhos Range.

Isso impede a disponibilizaçã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 da norma RFC 7232. Por exemplo, ETag: "xyzzy" é substituído por ETag: W/"xyzzy".

Cabeçalho Vary

Ao disponibilizar uma resposta com potencial de ser compactada, dependendo da solicitação, o Cloud CDN adiciona o cabeçalho Vary: Accept-Encoding à resposta.

Resumo das alterações 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 enfraquecida, indicada pelo prefixo W/.
Accept-Ranges Defina como o valor none.
Content-Length Pode ser removido por completo 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 Content-Length, ele adicionará este cabeçalho, com o valor definido como em blocos e divide o corpo da resposta em blocos.

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 relevante de dados de saída do cache ou da Internet (respectivamente) é medida com relação aos bytes compactados finais enviados para o cliente.

Se estiver sendo disponibilizada 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 e no aumento do desempenho para os usuários finais.

Métricas

Quando a compactação está ativada, a métrica https/response_bytes_count de loadbalancing.googleapis.com informa o tamanho da resposta compactada.

Haverá uma queda no total de bytes de resposta (e na capacidade de processamento da transferência de dados de saída).

Se estiver sendo disponibilizada uma grande quantidade de conteúdo baseado em texto fácil de compactar, como HTML, CSS, JavaScript ou JSON, talvez haja uma grande queda nos bytes de resposta.

Para mais informações, consulte Monitoring.

A seguir