👨🏻‍🏭 🛌🏾 🔤 Eficiência Brotli no mundo real 🧘 🧓🏾 🙍🏽

Uma das regras mais fundamentais para o desenvolvimento de sites rápidos é otimizar seus recursos. Se estamos falando sobre recursos de texto - sobre código escrito em HTML, CSS e JavaScript, isso significa que estamos falando sobre compactação de dados. O padrão de fato para compactar recursos de texto na Web é o método Gzip. Ou seja, cerca de 80% dos recursos compactados obtidos durante os downloads do site são compactados usando o Gzip. Para comprimir os 20% restantes dos recursos, um algoritmo muito mais novo é usado - o Brotli.

Obviamente, esses 100% dos recursos compactados que entram nos navegadores quando recebem respostas às solicitações de sites não incluem absolutamente todos os recursos. Ainda existem muitos recursos que podem ser compactados ou que podem ser compactados. Mas esses recursos permanecem descomprimidos. Métricas mais detalhadas sobre compactação podem ser encontradas na seção Compactação do recurso Web Almanac.

O método de compressão gzip é incrivelmente eficiente. Todo o trabalho de Shakespeare em texto simples leva 5,3 MB. E após a compactação Gzip (nível de compactação 6), eles ocupam apenas 1,9 MB. Isso significa que o tamanho do arquivo no qual esses dados são armazenados diminuiu 2,8 vezes. Ao mesmo tempo, os dados não são perdidos durante a compactação. Ótimo!

Melhor ainda, o grau de compactação do Gzip é afetado pela presença de linhas duplicadas nos arquivos. Quanto mais repetições no texto, mais eficiente é a compactação. Isso é muito bom para a web, pois o código escrito em HTML, CSS e JS tem uma sintaxe uniforme e contém muitas repetições.

Mas, embora o Gzip seja um método de compactação muito eficiente, ele também é bastante antigo. Apareceu em 1992 (o que, é claro, ajuda a explicar sua ampla prevalência). Após 21 anos, em 2013, o Google lançou o Brotli, um novo algoritmo que promete níveis de compressão ainda mais altos do que aqueles que o método Gzip é capaz. Os mesmos trabalhos de Shakespeare, com 5,2 MB de tamanho, são compactados usando Brotli para um tamanho de 1,7 MB (com um nível de compactação de 6). E isso já significa uma redução de 3,1 vezes no tamanho do arquivo. Isso é ainda melhor do que usar o Gzip.

Usando uma ferramenta para avaliar o nível de compactação de dados usando Gzip e Brotli, é provável que você descubra que, ao compactar alguns dados, Brotli é muito mais eficiente que o Gzip. Por exemplo, os dados do ReactDOM são 27% menores quando compactados usando Brotli com um nível máximo de compactação (11) do que quando se usa Gzip com um nível máximo de compactação (9).

Aqui está uma comparação da compactação de Brotli com a compactação Gzip ao processar o ReactDOM.

Nível de compressão	Tamanho (em bytes)	Eficiência de compactação (em comparação com dados não compactados)	% De melhoria em relação ao Gzip
1 1	43456	2,73	3%
2	39898	2,97	onze%
3	39416	3.08	quinze%
4	38488	3.08	quinze%
5	36323	3,27	dezenove%
6	36048	3,29	vinte%
7	35804	3,31	vinte%
8	35709	3,32	21%
9	35659	3,33	21%
10	33590	3.53	25%
onze	33036	3.59	27%

Como você pode ver, em todos os níveis de compressão, Brotli ignora o Gzip. No nível máximo de compactação disponível com o Brotli, é 27% mais eficiente que o Gzip.

E, com base na observação pessoal, observo que a transição de um de meus clientes de Gzip para Brotli levou a uma redução média de 31% no tamanho dos arquivos.

Como resultado, nos últimos anos, eu e outros especialistas em desempenho incentivamos os clientes a mudarem de Gzip para Brotli.

Vou dizer algumas palavras sobre o suporte ao navegador para Gzip e Brotli. O Gzip é tão difundido que o CanIUse nem exibe uma tabela com informações de suporte. Diz o seguinte: "Este cabeçalho HTTP é suportado em quase todos os navegadores (começando com IE6 +, Firefox 2+, Chrome 1+ e assim por diante)." E Brotli, ao escrever este material, desfruta de um nível muito agradável de apoio.em 93,17%. E isso é muito, muito mesmo! Portanto, se o seu site tiver pelo menos algum tamanho significativo, talvez você não goste do retorno de recursos não compactados para mais de 6% dos usuários. Mas, usando Brotli, você não perde nada. Os clientes usam um modelo progressivo de suporte para novos algoritmos, para que os usuários que não podem aceitar os recursos Brotli simplesmente usem a opção de fallback na forma de Gzip. Falaremos mais sobre isso abaixo.

Em geral, especialmente se você usar a CDN, ativar o Brotli é uma questão de segundos. Pelo menos é o caso do Cloudflare, o serviço que eu uso para o site CSS Wizardry. No entanto, muitos dos meus clientes, se falamos sobre os últimos dois anos, não são tão bem-sucedidos. Alguns deles suportam sua própria infraestrutura, e a prática mostra que instalar e implantar o Brotli não é tão simples. Alguns usam serviços CDN que não diferem em recursos facilmente acessíveis para dar suporte ao novo algoritmo.

Nos casos em que não podíamos mudar para Brotli, sempre tínhamos uma pergunta sem resposta: "E se ...". Como resultado, finalmente decidi me armar com números e responder à pergunta sobre o que dá ao site a transição para Brotli.

Menos não é necessariamente mais rápido.

Normalmente "menos", no entanto, significa "mais rápido". Como regra, se você reduzir o tamanho do arquivo, ele será transferido mais rapidamente do servidor para o cliente. Mas se você criar um arquivo, digamos, 20% menor, isso não significa que ele chegará 20% mais rápido. O ponto aqui é que o tamanho do arquivo é apenas um aspecto do desempenho da web. E qualquer que seja o tamanho do arquivo, o recurso entregue ao navegador está associado a muitos outros fatores e a muitas limitações do sistema - atrasos na rede, perda de pacotes e similares. Em outras palavras, economizar no tamanho do arquivo ajuda a transferir os mesmos dados de antes, enviando menos pacotes, mas a transferência de dados entre o servidor e o cliente é limitada por atrasos na rede, como resultado, a velocidade com que os pacotes que chegam ao cliente serão menores não será alterada.

TCP, pacotes, atraso de ida e volta

Se for muito simplista considerar a transferência de arquivos do servidor para o cliente, teremos que dar uma olhada no protocolo TCP. Quando recebemos um arquivo do servidor, ele não chega até nós de uma só vez. O protocolo TCP, sobre o qual o HTTP funciona, divide os arquivos em segmentos chamados pacotes. Esses pacotes são enviados ao cliente em ordem, em sequência. O cliente confirma o recebimento de cada pacote da série antes de iniciar a transferência da próxima série. Isso acontece até que o cliente colete todos os pacotes necessários, até que não haja pacotes não enviados no servidor e até que o cliente possa coletar os pacotes em algo que possa ser reconhecido como um arquivo. Para que a sessão de transferência de sequência de pacotes seja concluída com êxito, o servidor deve enviá-las ao cliente e o cliente deve confirmar seu recebimento. Tempo,A quantidade de dados necessária para receber e confirmar a recepção é denominada RTT (Round Trip Time).

Cada nova conexão TCP não pode saber qual é a largura de banda disponível e qual a confiabilidade da conexão (ou seja, qual é o nível de perda de pacotes). Se o servidor tentar enviar megabytes de dados por uma conexão que suporte uma taxa de transferência de dados de um megabit por segundo, essa transferência sobrecarregará a conexão e causará uma sobrecarga no canal de comunicação. E vice-versa - se o servidor tentar transferir uma pequena quantidade de dados através de uma conexão muito rápida, a conexão será usada ineficientemente, ficará inativa.

Para resolver esse quebra-cabeça, o TCP usa um mecanismo chamado início lento. Isso faz parte da estratégia de gerenciamento da janela de sobrecarga. Cada nova conexão TCP é limitada pela capacidade de enviar apenas 10 pacotes de dados na primeira sequência de pacotes (10 pacotes - o tamanho da janela inicial de congestionamento). Dez segmentos TCP são aproximadamente 14 KB de dados. Se esses pacotes forem recebidos com êxito pelo cliente, a segunda série já conterá 20 pacotes, haverá 40, 80, 160 e assim por diante. O crescimento exponencial de pacotes em seqüências continuará até que um dos seguintes eventos ocorra:

O sistema enfrentará a perda de pacotes. Nesse momento, o servidor reduzirá o número de pacotes na sequência a seguir, dividindo o número anterior de pacotes por 2 e tentará transferir os dados novamente.
Atingimos o limite de largura de banda disponível e podemos usá-lo com capacidade total.

Essa estratégia simples e elegante permite que você se equilibre à beira da cautela e do otimismo. Aplica-se a todas as novas conexões TCP estabelecidas pelo aplicativo da web.

Em palavras simples, o tamanho inicial da janela de congestionamento da nova conexão TCP é de apenas 14 Kb. Ou cerca de 11,8% dos dados não compactados do ReactDOM. 36,94% dos dados compactados usando Gzip ou 42,38% dos dados compactados usando Brotli (no nível máximo de compactação).

E então vamos desacelerar. A transição de 11,8% para 36,94% já é uma melhoria muito perceptível! Mas a transição de 36,94% para 42,38% - isso está longe de ser tão impressionante. O que está acontecendo?

Número da sessão de dados	A quantidade de dados transferidos em uma sessão, Kb	Quantidade acumulada de dados transferidos, Kb	A sequência na qual os dados do ReactDOM são transferidos
1 1	14	14
2	28.	42.	Gzip (37.904 Kb), Brotli (33.036 Kb)
3	56.	98
4	112	210.	Opção não compactada (118.656 Kb)
5	224	434

Acontece que os dados compactados com Gzip e os dados compactados com Brotli são transmitidos na mesma série de pacotes. A transferência de um arquivo leva duas seqüências. Se o RTT for bastante uniforme ao transmitir todas as seqüências, isso significa que leva o mesmo tempo para transmitir dados compactados usando Gzip e Brotli. Por outro lado, a transferência de uma versão não compactada dos dados requer quatro séries de pacotes, não duas. E isso, especialmente em conexões com altas latências de rede, pode resultar em um tempo bastante perceptível necessário para a transferência de dados.

Costumo aqui ao fato de que a velocidade de transferência de dados depende não apenas do tamanho dos arquivos. É influenciado pelos recursos do funcionamento do protocolo TCP. Não precisamos apenas tornar os arquivos menores. Precisamos torná-los muito menores, levando-os a um tamanho que permita que sejam transmitidos em menos sequências de pacotes.

Isso significa, em teoria, que, para que o algoritmo de Brotli seja notavelmente mais eficiente que o Gzip, ele deve poder compactar os dados com muito mais agressividade. Isso é necessário para que os dados possam ser transmitidos em menos seqüências de pacotes do que quando se usa o Gzip. E não sei como esse algoritmo se desenvolverá ...

Vale ressaltar que o modelo acima é bastante simplificado. Existem muitos outros fatores a serem considerados. Por exemplo - é uma conexão TCP nova ou já aberta? A conexão está sendo usada para outra coisa? Os mecanismos de priorização de tráfego do servidor estão parando e iniciando a transferência de dados? Os fluxos H / 2 têm acesso exclusivo à largura de banda? Esta seção é um estudo mais sério. Deve ser considerado como um bom ponto de partida para sua própria pesquisa. Mas considere analisar minuciosamente os dados usando algo como o Wireshark e leia este material, que fornece uma descrição mais profunda dos primeiros 14 Kb "mágicos".

O acima se aplica somente a novas conexões TCP. Os arquivos transferidos por uma conexão existente não passarão pelo procedimento de inicialização lenta. Isso nos leva a duas conclusões importantes:

Acho que não vale a pena repetir, mas vou repetir: os recursos estáticos precisam ser hospedados. Essa é uma ótima maneira de evitar atrasos de inicialização lenta, já que usar o seu próprio servidor já "aquecido" significa que os pacotes que saem desse servidor têm acesso a uma largura de banda maior. Essa conclusão me leva à segunda conclusão.
, , . , . .

	, ,	,
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1778
8	1792	3570
9	3584	7154
10	7168	14322
…	…	…
20	7340032	14680050

No final da 10ª sessão de transferência de dados, a quantidade de dados transferidos em uma sessão é de 7168 Kb, enquanto, no total, 14322 Kb de dados já foram transferidos. Isso é mais do que suficiente para o trabalho comum na Internet (ou seja, não para ver o Game of Thrones). De fato, geralmente acontece que carregamos a página da Web inteira e todos os seus recursos sem atingir o limite de nossa largura de banda. Em outras palavras, o uso de um canal de comunicação de fibra óptica de 1 Gbit / s (ou seja, 0,125 GB / s) não fará com que a navegação normal pareça muito mais rápida do que usar uma conexão mais lenta, pois a maioria desse canal nem sequer será usado.

E até a 20ª sessão de transferência de dados, teoricamente transferimos 7,34 GB de dados em uma sequência de pacotes.

E o mundo real?

Até agora, estivemos envolvidos em considerações teóricas. E comecei a trabalhar neste material devido ao fato de que gostaria de saber sobre o impacto que Brotli pode ter em sites reais.

Até agora, os números apresentados aqui apontam para a enorme diferença entre a falta de compactação e o uso do Gzip, e o fato de que o ganho do uso do Brotli, em comparação com o Gzip, é bastante modesto. Isso nos diz que a transição da falta de compactação para o uso do Gzip proporcionará uma melhoria notável, enquanto a transição do Gzip para Brotli provavelmente pode parecer muito menos impressionante.

Selecionei, como exemplos, vários sites, guiados pelas seguintes considerações:

O site deve ser relativamente conhecido (é melhor usar sites que possam ser comparados a algo).
O site deve ser adequado para o teste. Ou seja, ele deve ter um tamanho adequado (portanto, será mais interessante analisar seus materiais para compressão) e, ao mesmo tempo, não deve conter principalmente materiais que não são compactados usando Gzip / Brotli - por exemplo, YouTube.
Nem todos os sites da coleção devem pertencer a grandes corporações (vale a pena analisar alguns, digamos, sites "regulares").

Considerando esses requisitos, selecionei os sites listados abaixo e comecei a testar. Aqui estão os sites que selecionei:

Como não queria complicar os testes, decidi pelos seguintes indicadores:

A quantidade de dados transferidos.
Primeira vez de pintura com conteúdo (FCP).

Eles foram analisados nas seguintes situações:

Falta de compressão.
Usando gzip.
Usando brotli.

A métrica FCP parece próxima do mundo real e universal o suficiente para sua aplicação em qualquer site, pois permite avaliar o que as pessoas precisam de sites - ou seja, o conteúdo desses sites. Além disso, escolhi essa métrica porque Paul Calvano , uma pessoa inteligente, disse o seguinte: “A experiência me diz que o uso do Brotli leva ao FCP aprimorado, especialmente quando os recursos críticos de CSS / JS são grandes” .

Teste

Vou lhe contar um segredo sujo. Muitos estudos de desempenho da Web (não todos, mas muitos) não são baseados em pesquisas sobre melhorias de desempenho, mas em tirar conclusões do oposto - da degradação do desempenho. Por exemplo, a BBC é muito mais fácil afirmar que "eles perdem 10% dos usuários por cada segundo extra que precisam para carregar seu site" do que descobrir o que está acontecendo graças a uma melhoria de um segundo. É muito mais fácil desacelerar o site do que acelerá-lo, e você sente que é por isso que muitas pessoas fazem esse trabalho tão bem.

Diante disso, não tentei primeiro baixar sites que usem o Gzip e, offline, de alguma forma compactar seu conteúdo usando o Brotli. Em vez disso, encontrei sites que usam o Brotli e desliguei a compactação. Eu fui de Brotli para Gzip e depois de Gzip para não-compressão, medindo como isso funciona no site.

Embora eu não possa, por exemplo, conectar-me ao servidor Linkedin e desconectar o Brotli, posso simplesmente acessar este site a partir de um navegador que não é compatível com o Brotli. Embora não seja possível desativar o suporte ao Brotli no Chrome, posso ocultar do servidor o fato de o meu navegador suportar o Brotli. Os navegadores informam aos servidores quais algoritmos de compactação são compatíveis usando o cabeçalho da solicitaçãocontent-encoding. Usando o Webpagetest, posso personalizar os cabeçalhos. Então, tudo é muito simples!

Os recursos avançados do WebPageTest nos permitem definir cabeçalhos de solicitação personalizados.Aqui

está como eu configuro o campo Cabeçalhos personalizados:

Desligamento completo de compressão: accept-encoding: randomstring.
Incapacitante Brotli, mas o apoio Gzip: accept-encoding: gzip.
Para usar o Brotli se esse método de compactação for suportado pelo site (e contanto que ele seja suportado pelo navegador): o campo permanece vazio.

Você pode descobrir se isso funciona como planejado, verificando a presença (ou ausência) do cabeçalho content-encodingna resposta do servidor.

resultados

Como esperado, a transição da falta de compactação para o Gzip significou uma melhoria significativa, mas a transição do Gzip para Brotli não parece tão impressionante. Os dados brutos de minhas experiências podem ser encontrados aqui . A seguir, as descobertas que mais me interessam:

Gzip : 73%.
FCP Gzip : 23.305%.
Brotli Gzip: 5.767%.
FCP Brotli Gzip: 3.462%.

Todos esses são valores medianos. Falando em "tamanhos de material", quero dizer apenas HTML, CSS e JavaScript.

Graças ao uso do Gzip, o tamanho dos arquivos foi reduzido em 73% em comparação com as versões descompactadas. E o uso do Brotli permitiu reduzir o tamanho dos arquivos apenas em 5,7% adicionais. Se falamos de FCP, graças ao Gzip, esse indicador melhorou 23% em comparação com a falta de compactação, e Brotli adicionou apenas mais 3,5% a isso.

Embora pareça que esses resultados reforcem a teoria, existem várias maneiras de melhorar esses resultados. O primeiro é testar um número muito maior de sites, gostaria de discutir mais dois com mais detalhes.

Dados de recursos próprios e dados de fontes externas

Nos meus testes, desliguei o Brotli em todos os lugares, e não apenas nos servidores que armazenam dados do site. Isso significa que avaliei não apenas os benefícios que os sites obtêm com o Brotli, mas, em termos de potencial, os benefícios que Brotli obtém das fontes externas usadas por esses sites. Isso se enquadra no escopo de nossos interesses somente se recursos de terceiros forem usados nas formas críticas dos sites sob investigação, mas vale a pena lembrar.

Níveis de compressão

Falando em compactação, discutimos frequentemente os resultados obtidos com o melhor cenário de aplicativo de compactação. Ou seja - ao usar o Gzip, temos em mente o 9º nível de compactação e ao usar o Brotli - 11º nível. No entanto, é improvável que o servidor sob investigação seja configurado da melhor maneira possível. Por exemplo, o Apache usa compactação gzip no nível 6, enquanto o NGINX usa apenas o primeiro.

Desativar o Brotli significa que estamos mudando para a opção de fallback, para o Gzip, e dada a maneira como eu testei os sites, não pude alterar uma configuração de fallback ou agir de alguma forma. Digo isso porque os materiais dos dois locais no teste aumentaram de tamanho quando Brotli foi ligado. Isso indica para mim que o nível de compactação Gzip era tal que fornecia uma compactação mais forte que o nível de compactação de Brotli.

Escolher um nível de compactação é um compromisso. Todos gostariam de pedir o nível mais alto de compactação e, com isso, considerar o problema resolvido. Mas essa abordagem é impraticável. O fato é que o tempo extra que o servidor precisará para executar dinamicamente essa compactação provavelmente negará os benefícios de um nível de compactação mais alto. Para lidar com esse problema, você pode recorrer ao seguinte:

Você pode usar um nível pragmático de compactação que forneça o equilíbrio certo de velocidade e eficiência durante a compactação dinâmica de dados.
Você pode fazer upload de recursos estáticos pré-compactados para o servidor, cujo nível de compactação é maior que o usado para compactação dinâmica. Nesse caso, para selecionar o nível de compactação dinâmica, você pode usar a ideia descrita no primeiro parágrafo.

Sumário

Ficamos com a impressão de que, racionalmente, podemos reconhecer a insignificância das vantagens de Brotli sobre o Gzip.

Se ativar o suporte ao Brotli é uma questão de alguns movimentos do mouse no painel de controle da sua CDN, você deve pegar o Brotli e ligá-lo agora. O suporte para esse algoritmo de compactação é amplo o suficiente, os navegadores que não oferecem suporte ao Brotli mudam facilmente para mecanismos de reserva, e mesmo uma pequena melhoria é melhor que nada.

Se possível, faça o upload dos recursos estáticos pré-compactados no nível máximo de compactação para os servidores. E para compactação dinâmica, use não os níveis de compactação mais altos, mas não os mais baixos. Se você usa o NGINX, verifique se não está usando o primeiro nível padrão de compactação do NGINX.

No entanto, se, para usar o Brotli, você pode precisar de semanas de desenvolvimento, teste e implantação, não entre em pânico - apenas certifique-se de usar a compactação Gzip para tudo o que pode ser compactado (isso inclui, além de recursos de texto, arquivos .ico e .ttf - se eles são, é claro, usados em seu projeto).

Suponho que uma versão curta deste artigo possa ser assim: se você não deve ou não pode ativar o Brotli, não está perdendo muito.

Queridos leitores! Você planeja usar o Brotli?

Eficiência Brotli no mundo real