Início > Desenvolvimento > Por uma web mais rápida: compressão radical de JavaScript – parte 2

Por uma web mais rápida: compressão radical de JavaScript – parte 2

No post anterior, descrevi o cenário em que um código em JS deveria ser entregue com um nível de compressão excepcional, visto que ele seria bastante requisitado. Expliquei um pouco do funcionamento do Packer para JavaScript e dei algumas dicas para otimizar o uso dele de forma que não pese no lado do cliente.

Neste ponto, um código de 36 KB (XRegExp + parte da aplicação) já está razoávelmente comprimido, mas não o suficiente para um ambiente com muitas requests: advertising.

A solução encontrada foi compressão pelo servidor com GZip. Otimização, aliás, recomendada no post do Sérgio Lopes e não só por ele!

É uma solução muito eficaz para entrega de conteúdo estático. Se utilizada com cache, então, fica lindo. Mas essa opção não se adequava ao caso, já que o JS era “eventualmente estático” e qualquer alteração das regras impactava no conteúdo do JS, seja modificando o tamanho para mais ou menos, mas, sempre modificando o arquivo. Daí a necessidade de não cachear esses arquivos e garantir que toda alteração feita pelo usuário da plataforma seria imediatamente refletida no script.

Então foi decidido: compressão máxima pelo servidor onde os arquivos JS (um para cada site, cada cliente com vários sites) seriam hospedados. Packer  + Gzip nível 9 – compressão de 36 para menos de 4 KB. Incrível! (~4 KB * clientes * sites * milhões) já parece ser um número bem melhor!

Nesse ponto, fiquei incomodado – mesmo sem ter feito qualquer benchmark – sobre como o servidor responderia tendo que efetuar tantas compressões on-the-fly, sem caching e acabei chegando a uma solução muito, mas muito simples e eficaz:

Para conteúdos estáticos e muito requisitados, não deixe o servidor comprimir durante a requisição. Entregue comprimido.

Sim, isso! Armazenar o arquivo já comprimido! O backend já era responsável por obter as regras, concatenar a XRegExp, as regras e o código que faz tudo funcionar; agora também é responsável por comprimir o JS com GZip. Gastar algum tempo de processamento comprimindo 36 KB (ou mais) em 4 KB? Nunca na requisição, só no momento em que uma regra for modificada ou em algum cron job na madrugada executado por garantia.

E o servidor?

A não ser que ele seja instruído a não fazer isso, e manter a compressão habilitada para tudo, ele vai comprimir o que já foi comprimido. Então, aqui está o maior truque disso tudo:  configurar o servidor para caso uma request peça por um arquivo armazenado em determinado diretório, deixe a compressão e envie uma header Content-Encoding: gzip.

E aquele browser que não tem suporte a gzip?

Não pode entregar como gzip. Excepcionalmente, o backend também trata de gerar os scripts somente com a compressão do Packer. Nesse caso, usar cache é importante, porque uma parcela de usuários receberá um arquivo um pouco maior que os outros e é importante não deixar a performance do servidor ser impactada por isso.

Usamos  o Lighttpd e foi muito fácil configurá-lo para agir assim. Para caching, o escolhido foi o Varnish, mas como não fui responsável pela configuração, não posso dar detalhes.

O conceito mais importante dessa parte do post não se aplica ao JS ou ao comportamento da aplicação, mas do servidor. A idéia de entregar conteúdo já comprimido ao invés de utizar compressão on-the-fly se aplica a qualquer tipo de conteúdo que não seja interessante, do ponto de vista da performance, de ser entregue através de métodos específicos de caching. E a conclusão é de que isso não é mais do que um método alternativo de caching.

Considerei a abordagem de usar caching mais forte, separando a XRegExp, com um tempo de cache maior, enquanto as regras e o código ficariam com um tempo menor de cache. Mas aí não seria tão “emocionante” e se por algum motivo a XRegExp não fosse carregada, a aplicação não funcionaria.

Concluído o projeto, me desliguei da empresa com uma proposta mais interessante, deixando uma documentação bastante forte sobre essas idéias. Preciso dar uma olhada nos sites dos clientes para ver se eles já estão utilizando tal aplicação!

Anúncios
  1. 12/09/2011 às 18:12

    Bem legal a estrategia de pre-gzipar. Ja economiza bastante processamento no servidor, ainda mais com milhoes de requests como no seu caso

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: