Compressão de JavaScript: Nem tudo é positivo

Tenho partilhado várias dicas aqui no blog sobre como tornar um site mais rápido. Algumas incluem a compressão de ficheiros quer através de redução como de compressão gzip.

Mas nem todos os compressores fazem um bom trabalho, e o conhecido /packer/ é um deles.

Carruagem de metro cheia

O /packer/ anuncia maravilhas, afinal de contas com um algoritmo complexo que consegue codificar o código JavaScript com Base62, reduzir o nome das variáveis e consegue resultados em tamanho de ficheiro muito parecidos ao de um ficheiro Gzip.

O problema é que um ficheiro Gzip é descarregado uma vez, descomprimido uma vez e fica em cache no browser. O utilizador poupa largura de banda e deixa de fazer pedidos ao servidor.

“Mas Eduardo, com um ficheiro .js do /packer/ acontece o mesmo”, devem pensar vocês. Certo, o ficheiro fica em cache mas comprimido com o algoritmo usado, e cada vez que se acede a uma página com este JavaScript existe um trabalho desnecessário de descodificação do ficheiro e posterior colocação dos dados em memória no browser.

Se em computadores com boa capacidade de processamento isto equivale a alguns milissegundos, num computador mais fraco como um Netbook ou num telemóvel estamos a falar de o uso de recursos para processamento e memória que se poderiam evitar.

Para mim o /packer/ é uma alternativa para os preguiçosos. O meu conselho é não usar o seu Base62 encode e optar antes pela compressão dos ficheiros no servidor.

 
Copyright © 1985 - 2017 Eduardo Maio. Alguns direitos reservados.
eduardomaio.net - Às vezes mais valia ser Agricultor do que Programador
Ao navegar no blog eduardomaio.net está a concordar com os termos legais e de privacidade.