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