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.

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.2

Gráfico de pizza da tabela de dados da Figura 15.1.

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.3

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

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.4

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)

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.5

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.6

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.

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.7

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.8

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.

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.

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.10

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.

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.

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.11

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.

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!

Explore os resultados

• Ver imagem

Mostrar descrição da figura 15.12

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.

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.