Ativar a compactação dinâmica

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çalhos Content-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:

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

    Acessar as origens do Cloud CDN

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

  3. Na seção Noções básicas sobre a origem, clique em Próxima.

  4. Na seção Regras de host e caminho, clique em Próxima.

  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

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çalho Accept-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çalho Accept-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 o desempenho, 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 ou application/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/xmp-protobuffer
application/x-xprotobuf-protobuf application/x-xwgnapapp/xmlvh
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.

  • É 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, bem como pelo 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 cache de saída relevante ou a transferência de dados de saída da Internet (respectivamente) é medida em relação aos bytes compactados finais enviados ao cliente.

Se você estiver exibindo uma grande quantidade de respostas compactáveis, isso poderá reduzir as taxas mensais de transferência de dados de saída, além de melhorar o 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.

Espera-se que você veja 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