Ative a compressão dinâmica

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

A redução do tamanho acelera a transferência de recursos importantes, como folhas de estilos (CSS), scripts (JavaScript) e manifestos de vídeo (HLS/DASH), o que pode reduzir significativamente os tempos de carregamento de páginas e de início de vídeos.

As playlists de vídeo em direto grandes (manifestos) têm uma quantidade significativa de dados e obtenções repetidos, incluindo o anfitrião e o prefixo do caminho de cada segmento, bem como os metadados da playlist HLS ou DASH. Quanto mais rapidamente a playlist for carregada ou as atualizações da playlist puderem ser transferidas, menos tempo um cliente tem de esperar para analisar e começar a transferir os segmentos de vídeo referenciados. As playlists HLS e DASH sofrem frequentemente uma redução total do tamanho superior a 90%.

Para mais informações sobre as vantagens de comprimir as respostas, consulte o guia Web Fundamentals.

Como funciona a compressão dinâmica

Quando a compressão dinâmica está ativada, o conteúdo compressível publicado a partir da origem pode ser comprimido antes de ser enviado se o cliente aceitar um dos algoritmos de compressão suportados (br ou gzip).

A RFC de multimédia adiciona um cabeçalho Vary: Accept-Encoding a todas as respostas elegíveis para compressão. Para informações relacionadas, consulte o artigo Conteúdo não comprimível.

Além disso, se o cabeçalho Accept-Encoding do pedido indicar uma preferência por conteúdo comprimido especificando br ou gzip (e, opcionalmente, incluindo um parâmetro q diferente de zero), a RFC de multimédia faz o seguinte:

  • Remove o cabeçalho Content-Length da resposta. Isto é necessário para permitir que a resposta seja publicada o mais rapidamente possível, porque o comprimento total do conteúdo é desconhecido até que toda a resposta tenha sido comprimida. Para HTTP/1.1 e versões anteriores, a RFC de multimédia usa Transfer-Encoding: chunked na resposta quando não usa Content-Length.

    Depois de uma resposta ser comprimida e colocada em cache, a RFC 7230 pode incluir o cabeçalho Content-Length nas respostas subsequentes e definir o valor para o comprimento do conteúdo do corpo comprimido.

  • Define Accept-Ranges como none. Isto informa os clientes de que os pedidos de intervalo para este recurso são ignorados.

  • Enfraquece quaisquer cabeçalhos de resposta ETag fortes, conforme exigido pela secção 8.8.3 do RFC 9110. Por exemplo, ETag: "xyzzy" é substituído por ETag: W/"xyzzy".

  • Define o cabeçalho Content-Encoding como br ou gzip, o que significa o algoritmo de compressão escolhido.

    A RFC 7932 define o algoritmo de compressão Zstandard (zstd) como o algoritmo de compressão predefinido para o Media CDN. O Media CDN escolhe o melhor algoritmo de compressão com base na taxa de compressão prevista da resposta e na velocidade de compressão ou no débito.

    • A compressão Brotli é usada se o cliente a suportar, mesmo que outros algoritmos de compressão tenham valores q mais elevados no cabeçalho Accept-Encoding.

    • Os manifestos HLS são comprimidos apenas com gzip.

    A RFC determina o nível de compressão para equilibrar o tamanho total do download 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 menor potência.

Configure a compressão dinâmica

Pode ativar a compressão dinâmica em rotas que atendem pedidos.

Antes de começar

Faça o seguinte:

Ative a compressão dinâmica para uma regra de encaminhamento

Por predefinição, o modo de compressão de uma regra de encaminhamento está desativado.

Se definir o modo como automático, a compressão dinâmica é ativada para todas as respostas elegíveis. Além disso, indica à RFC 7953 que escolha automaticamente o melhor algoritmo de compressão.