Pular navegação
Parte IV Capítulo 15

Compressão

Introdução

A compressão HTTP é uma técnica que permite codificar informação usando menos bits que a representação original. Quando é usado para entrega de conteúdo web, isso permite a servidores web reduzir a quantidade de dados transmitidos aos clientes. Isto aumenta a eficiência da largura de banda disponível do cliente, reduz o peso da página e melhora o seu desempenho.

Algoritmos de compressão são muitas vezes categorizados como podendo ter ou não perdas:

  • Quando um algoritmo de compressão com perdas é usado, o processo é irreversível e o arquivo original não pode ser restaurado através de descompressão. É uma prática comum para comprimir recursos mídia, tais como imagens e vídeos onde perder alguns dados não irá materialmente afetar o recurso.
  • A compressão sem perdas é um processo totalmente reversível sendo, tipicamente, usado em recursos do tipo texto, como HTML, JavaScript, CSS, etc.

Neste capítulo, vamos explorar como conteúdo de texto é comprimido na web. Análise de conteúdo não baseado em texto faz parte do capítulo Mídia

Como a compressão HTTP funciona

Quando um cliente faz um pedido HTTP, frequentemente, inclui um cabeçalho Accept-Encoding para comunicar os algoritmos de compressão que é capaz de descodificar. O servidor pode depois selecionar um dos algoritmos comunicados que suporte e servir uma resposta comprimida. A resposta comprimida iria por sua vez incluir o cabeçalho Content-Encoding para que o cliente perceba que tipo de compressão foi usada. Adicionalmente, um cabeçalho Content-Type é, frequentemente, usado para indicar o MIME type do resurso a ser servido.

No exemplo seguinte, o cliente comunica que tem suporte para compressão Gzip, Brotli e Deflate. O servidor decidiu retornar uma resposta comprimida com Gzip que contém um documento text/html.

    > GET / HTTP/1.1
    > Host: httparchive.org
    > Accept-Encoding: gzip, deflate, br

    < HTTP/1.1 200
    < Content-type: text/html; charset=utf-8
    < Content-encoding: gzip

O HTTP Archive contém leituras de 5.3 milhões de sites e cada site carregou pelo menos 1 recurso de texto comprimido na sua página de início. Adicionalmente, 81% dos sites reportaram ter recursos comprimidos no seu domínio primário.

Algoritmos de compressão

A organização IANA mantém uma lista de codificação de conteúdos HTTP válidos que podem ser usados com os cabeçalhos Accept-Encoding e Content-Encoding. Alguns destes incluem gzip, deflate, br (Brotli) entre outros. Uma breve descrição destes algoritmos é apresentada a seguir:

  • Gzip usa as técnicas de compressão LZ77 e Huffman coding e é mais antigo que a própria web. Foi originalmente desenvolvido para o programa gzip do Unix em 1992. Uma implementação para servir conteúdos na web existe desde o HTTP/1.1 e a grande maioria dos browsers e clientes suportam este algoritmo de compressão.
  • Deflate usa o mesmo algoritmo que o Gzip mas com um recipiente diferente. Não foi tão amplamente usado na web devido a problemas de compatibilidade com alguns servidores e browsers.
  • Brotli é um novo algoritmo de compressão criado pela Google. Combina a variante moderna da técnica de compressão LZ77 e Huffman e uma modelação de contexto de segunda ordem. A compressão via Brotli é computacionalmente mais exigente que o Gzip mas o algoritmo é capaz de reduzir o tamanho dos arquivos em 15-25% em relação à compressão Gzip. O Brotli foi inicialmente usado para compressão de conteúdos web em 2015 e é suportado em todos os browsers modernos.

Aproximadamente 38% das respostas HTTP são servidas com compressão baseada em texto. Pode parecer uma estatística surpreendente mas deve-se levar em conta que é baseado em todos os pedidos HTTP no dataset. Algum conteúdo, como imagens, não irá beneficiar destes algoritmos de compressão. A tabela abaixo resume a porcentagem de pedidos servidos para cada tipo de codificação de contéudo.

Porcentagem de Pedidos Pedidos
Tipo de codificação de conteúdo Desktop Celular Desktop Celular
Sem Compressão de Texto 62.87% 61.47% 260,245,106 285,158,644
gzip 29.66% 30.95% 122,789,094 143,549,122
br 7.43% 7.55% 30,750,681 35,012,368
deflate 0.02% 0.02% 68,802 70,679
Outro / Inválido 0.02% 0.01% 67,527 68,352
identity 0.000709% 0.000563% 2,935 2,611
x-gzip 0.000193% 0.000179% 800 829
compress 0.000008% 0.000007% 33 32
x-compress 0.000002% 0.000006% 8 29
Figura 15.1. Adoção de algoritmos de compressão.

De todos os recursos servidos com compressão, a maioria usa Gzip (80%) ou Brotli (20%). Os algoritmos restantes de compressão raramente são usados.

Adoção de algoritmos de compressão em páginas desktop.
Gráfico de pizza da tabela de dados da Figura 15.1.
Figura 15.2. Adoção de algoritmos de compressão em páginas desktop.

Adicionalmente, existem 67k pedidos que retornam um Content-Encoding inválido, como “none”, “UTF-8”, “base64”, “text”, etc. Estes recursos muito provavelmente são servidos sem compressão.

Não conseguimos determinar os níveis de compressão dos diagnósticos obtidos do HTTP Archive mas a melhor prática para comprimir conteúdo é:

  • No mínimo, ativar o nível 6 de compressão Gzip para recursos do tipo texto. Este nível representa um bom balanço entre o custo computacional e taxa de compressão sendo a opção padrão para muitos servidores web apesar do Nginx ainda recorrer a um nível 1, normalmente muito baixo.
  • Se conseguir suportar Brotli e pre-comprimir esses recursos, então use o nível 11. Este nível é computacionalmente mais exigente que o Gzip - portanto uma pre-compressão é essencial para evitar atrasos.
  • Se conseguir suportar Brotli mas pre-compressão não é uma opção, então comprima com Brotli nível 5. Este nível irá produzir recursos mais pequenos quando comparados com Gzip, com uma exigência computacional semelhante.

Que tipos de conteúdos estamos comprimindo?

A maior parte dos recursos baseados em texto (como HTML, CSS e Javascript) podem se beneficiar de compressão Gzip e Brotli. No entanto, normalmente não é necessário usar estas técnicas de compressão em recursos binários, como imagens, videos e algumas fontes web porque os seus formatos de arquivo já estão comprimidos.

No gráfico abaixo, podemos ver o top 25 de tipos de conteúdo em caixas cujo tamanho representa o número relativo de pedidos. A cor de cada caixa representa a quantidade de recursos servidos com compressão. A maior parte do conteúdo mídia é mostrado com uma sombra laranja uma vez que, tal como esperado, Gzip e Brotli trariam pouco ou nenhum benefício para os mesmos. A maior parte do conteúdo baseado em texto é sombreado a azul indicando que foram comprimidos. No entanto, o sombreado azul claro para alguns tipos de conteúdo indica que não são comprimidos tão consistentemente como os outros.

Top 25 tipos de conteúdo comprimidos.
Gráfico de árvore mostrando image/jpeg (167,912,373 pedidos - 3.23% comprimidos), application/javascript (121,058,259 pedidos - 81.29% comprimidos), image/png (113,530,400 pedidos - 3.81% comprimidos), text/css (86,634,570 pedidos - 81.81% comprimidos), text/html (81,975,252 pedidos - 43.44% comprimidos), image/gif (70,838,761 pedidos - 3.87% comprimidos), text/javascript (60,645,767 pedidos - 89.52% comprimidos), application/x-javascript (38,816,387 pedidos - 91.02% comprimidos), font/woff2 (22,622,918 pedidos - 3.87% comprimidos), application/json (16,501,326 pedidos - 59.02% comprimidos), image/webp (12,911,688 pedidos - 1.66% comprimidos), image/svg+xml (9,862,643 pedidos - 64.42% comprimidos), text/plain (6,622,361 pedidos - 24.72% comprimidos), application/octet-stream (3,884,287 pedidos - 6.01% comprimidos), image/x-icon (3,737,030 pedidos - 37.60% comprimidos), application/font-woff2 (3,061,857 pedidos - 5.90% comprimidos), application/font-woff (2,117,999 pedidos - 23.61% comprimidos), image/vnd.microsoft.icon (1,774,995 pedidos - 15.55% comprimidos), video/mp4 (1,472,880 pedidos - 0.03% comprimidos), font/woff (1,255,093 pedidos - 24.33% comprimidos), font/ttf (1,062,747 pedidos - 84.27% comprimidos), application/x-font-woff (1,048,398 pedidos - 30.77% comprimidos), image/jpg (951,610 pedidos - 6.66% comprimidos), application/ocsp-response (883,603 pedidos - 0.00% comprimidos).
Figura 15.3. Top 25 tipos de conteúdo comprimidos.

Excluindo os 8 tipos de conteúdo mais populares permite-nos ver as estatísticas de compressão dos restantes tipos de conteúdo com mais clareza.

Tipos de conteúdo comprimidos, excluindo o top 8.
Gráfico de árvore mostrando font/woff2 (22,622,918 pedidos - 3.87% comprimidos), application/json (16,501,326 pedidos - 59.02% comprimidos), image/webp (12,911,688 pedidos - 1.66% comprimidos), image/svg+xml (9,862,643 pedidos - 64.42% comprimidos), text/plain (6,622,361 pedidos - 24.72% comprimidos), application/octet-stream (3,884,287 pedidos - 6.01% comprimidos), image/x-icon (3,737,030 pedidos - 37.60% comprimidos), application/font-woff2 (3,061,857 pedidos - 5.90% comprimidos), application/font-woff (2,117,999 pedidos - 23.61% comprimidos), image/vnd.microsoft.icon (1,774,995 pedidos - 15.55% comprimidos), video/mp4 (1,472,880 pedidos - 0.03% comprimidos), font/woff (1,255,093 pedidos - 24.33% comprimidos), font/ttf (1,062,747 pedidos - 84.27% comprimidos), application/x-font-woff (1,048,398 pedidos - 30.77% comprimidos), image/jpg (951,610 pedidos - 6.66% comprimidos), application/ocsp-response (883,603 pedidos - 0.00% comprimidos)
Figura 15.4. Tipos de conteúdo comprimidos, excluindo o top 8.

Os tipos de conteúdo application/json e image/svg+xml são comprimidos menos de 65% das vezes.

A maior parte das fontes web customizadas são servidas sem compressão uma vez que já são um formato comprimido. No entanto, a fonte font/ttf é comprimível apesar de só 84% dos pedidos a fontes TTF serem servidos com compressão, mostrando que ainda existe espaço para melhoria.

Os gráficos abaixo ilustram a distribuição de cada técnica de compressão para cada tipo de conteúdo. Olhando os 3 tipos de conteúdo com mais compressão, conseguimos ver que tanto em dekstop como em celular existem grandes diferenças na compressão em alguns dos tipos de conteúdo mais frequentemente requisitados. 56% dos recursos text/html bem como 18% do tipo application/javascript e text/css não são comprimidos. Isto representa uma oportunidade significativa para melhoria de desempenho.

Compressão por tipo de conteúdo para desktop.
Gráfico de barras que mostra o tipo de conteúdo application/javascript com 36.18 Milhões/8.97 Milhões/10.47 Milhões por tipo de compressão (Gzip/Brotli/None), text/css com 24.29 M/8.31 M/7.20 M, text/html com 11.37 M/4.89 M/20.57 M, text/javascript com 23.21 M/1.72 M/3.03 M, application/x-javascript com 11.86 M/4.97 M/1.66 M, application/json com 4.06 M/0.50 M/3.23 M, image/svg+xml com 2.54 M/0.46 M/1.74 M, text/plain com 0.71 M/0.06 M/2.42 M, e image/x-icon com 0.58 M/0.10 M/1.11 M. Deflate raramente é usado e como tal não entra no gráfico.
Figura 15.5. Compressão por tipo de conteúdo para desktop.
Compressão por tipo de conteúdo para celular.
Gráfico de barras que mostra o tipo de conteúdo application/javascript com 43.07 Milhões/10.17 Milhões/12.19 Milhões por tipo de compressão (Gzip/Brotli/None), text/css com 28.3 M/9.91 M/8.56 M, text/html com 13.86 M/5.48 M/25.79 M, text/javascript com 27.41 M/1.94 M/3.33 M, application/x-javascript com 12.77 M/5.70 M/1.82 M, application/json com 4.67 M/0.50 M/3.53 M, image/svg+xml com 2.91 M/ 0.44 M/1.77 M, text/plain com 0.80 M/0.06 M/1.77 M, e image/x-icon com 0.62 M/0.11 M/1.22M. Deflate raramente é usado e como tal não entra no gráfico.
Figura 15.6. Compressão por tipo de conteúdo para celular.

Os tipos de conteúdo com a taxa de compressão mais baixa incluem application/json, text/xml, e text/plain. Estes recursos são normalmente usados em pedidos XHR para fornecer dados que aplicações web podem usar para criar as melhores experiências. Comprimir esses recursos irá, muito provavelmente, melhorar a experiência do usuário. Gráficos de vetores, como image/svg+xml e image/x-icon não são muitas vezes encarados como baseados em texto, mas na realidade são e sites que os usam iriam se beneficiar da compressão.

Compressão por tipo de conteúdo como porcentagem para desktop.
Gráfico de barras que mostra application/javascript com 65.1%/16.1%/18.8% por tipo de compressão (Gzip/Brotli/None), text/css com 61.0%/20.9%/18.1%, text/html com 30.9%/13.3%/55.8%, text/javascript com 83.0%/6.1%/10.8%, application/x-javascript com 64.1%/26.9%/9.0%, application/json com 52.1%/6.4%/41.4%, image/svg+xml com 53.5%/9.8%/36.7%, text/plain com 22.2%/2.0%/75.8%, e image/x-icon com 32.6%/5.3%/62.1%. Deflate raramente é usado e como tal não entra no gráfico.
Figura 15.7. Compressão por tipo de conteúdo como porcentagem para desktop.
Compressão por tipo de conteúdo como porcentagem para celular.
Gráfico de barras com application/javascript com 65.8%/15.5%/18.6% por tipo de compressão (Gzip/Brotli/None), text/css com 60.5%/21.2%/18.3%, text/html com 30.7%/12.1%/57.1%, text/javascript com 83.9%/5.9%/10.2%, application/x-javascript com 62.9%/28.1%/9.0%, application/json com 53.6%/8.6%/34.6%, image/svg+xml com 23.4%/1.8%/74.8%, text/plain com 23.4%/1.8%/74.8%, com image/x-icon com 31.8%/5.5%/62.7%. Deflate raramente é usado e como tal não entra no gráfico.
Figura 15.8. Compressão por tipo de conteúdo como porcentagem para celular.

No universo de tipos de conteúdo, Gzip é o algoritmo de compressão mais popular. A compressão Brotli mais recente é usado com menos frequência e os tipos de conteúdo onde aparece mais são application/javascript, text/css e application/x-javascript. Isto deve-se, provavelmente, à existência de CDNs que aplicam compressão Brotli automaticamente ao tráfego que as atravessa.

Compressão em conteúdo próprio vs terceiros

No capítulo de Terceiros, aprendemos sobre terceiros e o seu impacto no desempenho. Quando comparamos técnicas de compressão entre conteúdo próprio e terceiro, podemos ver que conteúdo de terceiros tende a ser mais comprimido que o conteúdo próprio.

Adicionalmente, a porcentagem de compressão Brotli é mais alta para conteúdo de terceiros. Isto deve-se, provavelmente, ao número de recursos servidos por grandes empresas de terceiros que suportam Brotli, tal como a Google e o Facebook.

Desktop Celular
Codificação de conteúdo Próprio Terceiros Próprio Terceiros
Sem compressão de texto 66.23% 59.28% 64.54% 58.26%
gzip 29.33% 30.20% 30.87% 31.22%
br 4.41% 10.49% 4.56% 10.49%
deflate 0.02% 0.01% 0.02% 0.01%
Outro / Inválido 0.01% 0.02% 0.01% 0.02%
Figura 15.9. Compressão de conteúdo próprio versus terceiros por tipo de dispositivo.

Como identificar oportunidades para compressão

A ferramenta Lighthouse da Google permite aos usuários executarem uma série de auditorias para páginas web. A auditoria de compressão de texto avalia se o site pode beneficiar de compressão baseada em texto adicional. Isso é feito através de uma tentativa de compressão dos recursos avaliando se o tamanho dos objetos pode ser reduzido pelo menos 10% e 1400 bytes. Dependendo da pontuação, é possível ver uma recomendação para compressão nos resultados, com uma lista dos recursos específicos que podem ser comprimidos.

Sugestões de compressão do Lighthouse.
A captura de um relatório do Lighthouse que mostra a lista de recursos (com respectivos nomes) e o tamanho do potencial ganho. Para o primeiro elemento há um ganho potencial significativo de 91 KB para 73 KB, enquanto que para outros arquivos mais pequenos de 6 KB ou menos, encontram-se ganhos menores de 4 KB para 1 KB.
Figura 15.10. Sugestões de compressão do Lighthouse.

Devido ao fato do HTTP Archive executar auditorias Lighthouse para cada página celular, podemos agregar as pontuações para todos os sites para entender que mais oportunidade existem para comprimir mais conteúdo. No total, 62% dos sites passam esta auditoria e quase 23% têm uma pontuação abaixo de 40. Isto significa que mais de 1.2 milhões de sites poderiam beneficiar com uma compressão baseada em texto adicional.

Pontuações da auditoria de “ativar compressão de texto” do Lighthouse.
Gráfico de barras que mostra 7.6% a pontuar menos de 10%, 13.2% dos sites estão a pontuar entre 10-39%, 13.7% dos sites estão a pontuar entre 40-79%, 2.9% dos sites estão a pontuar entre 80-99%, e 62.5% dos sites passam a auditoria com 100% dos recursos de texto comprimidos.
Figura 15.11. Pontuações da auditoria de “ativar compressão de texto” do Lighthouse.

O Lighthouse também indica quantos bytes podem ser poupados por ligar a compressão baseada em texto. Dos sites que podem beneficiar de compressão de texto, 82% podem reduzir o peso das suas páginas até 1 MB!

Auditoria de “compressão de texto” do Lighthouse com a potencial poupança de bytes.
Gráfico de barras que mostra 82.11% dos sites poderiam poupar menos de 1 MB, 15.88% dos sites poderiam poupar 1 - 2 MB e 2% dos sites poderiam poupar > 3 MB.
Figura 15.12. Auditoria de “compressão de texto” do Lighthouse com a potencial poupança de bytes.

Conclusão

Compressão HTTP é extensivamente usada e uma funcionalidade com muito valor para reduzir o tamanho de conteúdo web. Tanto Gzip e Brotli são os algoritmos dominantes e a quantidade de conteúdo comprimido varia por tipo de conteúdo. Ferramentas como o Lighthouse podem ajudar a revelar oportunidades para comprimir conteúdo.

Enquanto muitos sites estão fazendo um bom uso da compressão HTTP, ainda existe margem para melhoria, particularmente para o formato text/html que é o formato em que a web é construída! De forma similar, outros formatos menos compreendidos como font/ttf, application/json, text/xml, text/plain, image/svg+xml, e image/x-icon podem exigir configurações extra que muitos sites falham.

No mínimo, os sites deviam usar compressão Gzip para todos os recursos baseados em texto, uma vez que é largamente suportado, facilmente implementado, e tem um baixo custo de processamento. Ganhos adicionais podem ser encontrados com compressão Brotli, ainda que os níveis de compressão devam ser escolhidos com cuidado dependendo dos recursos poderem ser pré comprimidos.

Autor(a)