Ative a compressão dinâmica

A compressão dinâmica comprime automaticamente as respostas publicadas pela CDN da Google Cloud. O tamanho dos dados enviados através da rede é reduzido entre 60% e 85% nos casos típicos.

A redução do tamanho diminui o tempo necessário para transferir conteúdo. Para recursos importantes, como folhas de estilos (CSS), scripts (JavaScript) e manifestos de vídeo (HLS/DASH), isto pode reduzir os tempos de carregamento de páginas e de início de vídeos.

Pode saber mais sobre as vantagens de comprimir respostas no guia Web Fundamentals.

Pode ativar a compressão num serviço de back-end ou num contentor de back-end.

Exemplos de utilização

A compressão dinâmica reduz diretamente o tamanho dos dados enviados da extremidade da CDN na nuvem para o cliente. Isto pode fazer diretamente o seguinte:

  • Reduzir o tamanho do CSS e do JavaScript, o que ajuda a renderizar as páginas Web mais rapidamente e reduz o tempo para o First Contentful Paint, uma métrica de desempenho Web importante.

  • Ter um impacto grande e positivo quando coloca em cache respostas da API REST, como payloads JSON. Estes payloads são bem comprimidos devido às chaves repetidas, aos espaços e às chavetas. A colocação em cache de APIs públicas durante 5 a 10 segundos é uma abordagem popular para reduzir o carregamento de origem, mantendo a atualidade dos dados.

    Mesmo sem o armazenamento em cache, a compressão destas respostas pode reduzir o total de bytes enviados até 90%.

  • Melhorar o tempo de início da reprodução para a entrega de vídeo e a latência de participação para a transmissão em direto. As playlists (manifestos) grandes de streams em direto têm uma quantidade significativa de dados repetidos, incluindo o prefixo de anfitrião + caminho de cada segmento, bem como os metadados da playlist HLS ou DASH. Quanto mais rápido for o carregamento da playlist ou a transferência das atualizações da playlist, menos tempo um cliente espera para analisar e começar a transferir os segmentos de vídeo referenciados. As playlists HLS e DASH registam frequentemente uma redução do tamanho total superior a 90%.

Antes de começar

Certifique-se de que tem o seguinte:

  • Um back-end ativado para o Cloud CDN configurado. Se não tiver o RFC da Google Cloud configurado, pode seguir um dos guias de configuração.
  • O seu back-end tem conteúdo comprimível pronto a ser publicado, como recursos Web ou manifestos de vídeo entre 1 KiB e 10 MiB (inclusive).
  • Os clientes não confiam na obtenção de conteúdo parcial com pedidos de intervalo ou com ETags fortes. Não são compatíveis com a compressão dinâmica.
  • Os clientes podem processar respostas sem cabeçalhos Content-Length Por exemplo, as falhas de cache que o Cloud CDN comprime não têm cabeçalhos Content-Length.
  • O IAM função de administrador do equilibrador de carga do Compute (roles/compute.loadBalancerAdmin), que é necessária para fazer alterações à configuração do back-end.

Ative a compressão num serviço de back-end ou num contentor de back-end

Para ativar a compressão, siga estes passos.

Consola

Adicione uma nova origem

Para adicionar e configurar uma nova origem, siga as instruções no artigo Vista geral da configuração para o tipo adequado de back-end. Quando criar a origem, use a secção Opções avançadas para configurar a compressão dinâmica selecionando Automático na lista Modo de compressão.

Edite uma origem existente

Para editar uma origem do Cloud CDN existente:

  1. Na Google Cloud consola, aceda à página Origens do Cloud CDN.

    Aceda a Origens

  2. Clique no nome da origem que quer editar e, de seguida, clique em Editar.

  3. Na secção Bases de origem, clique em Seguinte.

  4. Na secção Regras de anfitrião e caminho, clique em Seguinte.

  5. Na secção Desempenho da cache, navegue para Opções avançadas.

  6. Na lista Modo de compressã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 o comando gcloud compute backend-services update com a flag --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 flag --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 do 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 compressão com base no cabeçalho Accept-Encoding enviado pelo cliente. Na maioria dos casos, isto resulta na preferência da compressão Brotli.
  • DISABLED (predefinição): desativa a compressã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 fragmento ao corpo do pedido JSON:

"compressionMode": AUTOMATIC

O compression-mode pode ser um dos seguintes:

  • AUTOMATIC (recomendado): usa automaticamente a melhor compressão com base no cabeçalho Accept-Encoding enviado pelo cliente. Na maioria dos casos, isto resulta na preferência da compressão Brotli.
  • DISABLED (predefinição): desativa a compressão.

Em poucos minutos, a configuração é propagada a todas as localizações periféricas. O conteúdo compressível publicado a partir do back-end é comprimido antes de ser enviado para o cliente.

Modos de compressão

O modo de compressão predefinido é DISABLED.

O modo AUTOMATIC permite que a RFC de multimédia na nuvem escolha o melhor método de compressão com base no seguinte:

  • A codificação aceite pelo cliente
  • A taxa de compressão prevista da resposta
  • Velocidade de compressão (débito) do Cloud CDN

O Brotli pode gerar uma redução adicional de 10% a 20% no tamanho da transferência para a maioria dos tipos de conteúdo em comparação com o gzip, com um desempenho de descompressão semelhante, o que o torna mais rápido no geral quando se considera o tempo de transferência e a velocidade de descompressão no cliente.

A CDN na nuvem indica o método de compressão escolhido como gzip ou brotli no cabeçalho Content-Encoding na resposta.

A CDN da Cloud determina o nível de compressão para equilibrar o tamanho total da transferência e o custo da CPU no cliente. Os níveis de compressão mais elevados nem sempre beneficiam o desempenho, especialmente em dispositivos móveis com menos potência.

Quando o Cloud CDN comprime inicialmente o conteúdo, remove o cabeçalho Content-Length da resposta. Isto é necessário para permitir que a resposta seja publicada o mais rapidamente possível, uma vez que o comprimento total do conteúdo é desconhecido até que toda a resposta seja comprimida. Depois de uma resposta ser comprimida e colocada em cache, a CDN da Google Cloud pode incluir o cabeçalho Content-Length em respostas subsequentes. (Para HTTP/1.1 e versões anteriores, o Cloud CDN usa Transfer-Encoding: chunked na resposta quando não usa Content-Length.)

Quando é que uma resposta é comprimida?

Se um pedido tiver um cabeçalho Accept-Encoding que liste explicitamente o suporte para algoritmos gzip ou Brotli, as respostas não comprimidas publicadas a partir do back-end (origem) com um cabeçalho Content-Type que corresponda aos tipos de conteúdo comprimíveis são comprimidas com gzip ou Brotli, respetivamente. Se um pedido não tiver um cabeçalho Accept-Encoding ou tiver Accept-Encoding: *, a resposta não é comprimida.

Por exemplo, dado um cabeçalho Accept-Encoding num pedido do cliente, a resposta é comprimida (ou não) de acordo com as informações na tabela seguinte:

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

Tipos de conteúdo compressíveis

A compressão dinâmica aplica-se 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 comprimidas.

Os tipos de conteúdo comuns e os respetivos tipos MIME incluem o seguinte:

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

A tabela seguinte resume a forma como o tipo MIME afeta a compressibilidade.

  Tipos MIME compressí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ões application/*+json
application/*+xml
application/*mpegURL
text/*

Os formatos de imagem e vídeo (como image/jpeg, image/png e video/mpeg4) estão quase sempre comprimidos, pelo que o Cloud CDN não os comprime. A recompressão de uma resposta já comprimida raramente reduz o tamanho do ficheiro e os clientes podem apresentar um comportamento inesperado quando recebem uma resposta deste tipo.

Quando é que uma resposta não é comprimida?

A compressão dinâmica não comprime uma resposta que tenha uma ou mais das seguintes características:

  • A resposta não tem um cabeçalho Content-Type que corresponda a um tipo de conteúdo comprimível.
  • Não tem um cabeçalho Content-Length.
  • Tem um cabeçalho Content-Encoding.

  • Tem menos de 1 KiB.

    O tempo gasto na compressão e descompressão compensa frequentemente quaisquer vantagens. Também existe menos conteúdo para comprimir, o que pode reduzir a eficácia da compressão e originar uma taxa de compressão mais baixa.

  • Tem mais de 10 MiB.

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

  • Tem um cabeçalho Vary: Accept-Encoding.

Pedidos de intervalo

Quando o Cloud CDN comprime uma resposta, o Cloud CDN adiciona um cabeçalho Accept-Ranges: none e substitui todos os cabeçalhos Accept-Ranges existentes. Os resultados da cache para essas respostas ignoram os cabeçalhos Range.

Isto impede a publicação de conteúdo parcial incorreto para os clientes, porque não há forma de ter a certeza se um cliente espera um intervalo de bytes da forma comprimida ou não comprimida de um recurso.

ETags

Quando a compressão dinâmica comprime uma resposta, todos os cabeçalhos ETag fortes são enfraquecidos, conforme exigido pela secção 2.3 da RFC 7232. Por exemplo, ETag: "xyzzy" é substituído por ETag: W/"xyzzy".

Cabeçalho Vary

Quando publica uma resposta que tem o potencial de ser comprimida (dependendo do pedido), o Cloud CDN adiciona o cabeçalho Vary: Accept-Encoding à resposta.

Resumo das alterações às respostas

A tabela seguinte resume as alterações que o Cloud CDN faz aos cabeçalhos de uma resposta quando ocorreu a compressão:

Cabeçalho da resposta Valor do cabeçalho após a compressão
Content-Encoding Defina como gzip ou brotli.
ETag Qualquer etiqueta de entidade forte é substituída por uma versão enfraquecida, indicada pelo prefixo W/.
Accept-Ranges Definido para o valor none.
Content-Length Pode ser removido na totalidade ou, se estiver presente, definido para o comprimento do conteúdo do corpo comprimido.
Transfer-Encoding Para HTTP/1.1 e protocolos mais antigos, se o Cloud CDN remover o cabeçalho Content-Length, adiciona este cabeçalho com o valor definido como chunked e divide o corpo da resposta em blocos.

Registo

Os registos do CDN da nuvem incluem um campo compressionStatus no jsonPayload que indica se a resposta foi comprimida pelo equilibrador de carga, bem como o tipo de compressão.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    statusDetails: "response_sent_by_backend"
    cacheId: "IAD-862d661f"
    compressionStatus: "br"
  }
}

Faturação

Quando uma resposta é comprimida pelo Cloud CDN ou pelo Cloud Load Balancing, a transferência de dados da cache de saída ou a transferência de dados da Internet de saída relevantes (respetivamente) é medida em função dos bytes comprimidos finais enviados para o cliente.

Se estiver a publicar uma grande quantidade de respostas comprimíveis, isto pode resultar numa redução nas taxas de transferência de dados de saída mensais, bem como num aumento do desempenho para os utilizadores finais.

Métrica

Quando a compressão está ativada, a métrica https/response_bytes_count existente em loadbalancing.googleapis.com indica o tamanho da resposta comprimida.

Pode esperar ver uma diminuição no total de bytes de resposta (e na taxa de transferência de dados de saída).

Se estiver a publicar uma grande quantidade de conteúdo baseado em texto que é bem comprimido, como HTML, CSS, JavaScript ou JSON, pode observar uma grande diminuição nos bytes de resposta.

Para mais informações, consulte a secção Monitorização.

O que se segue?