Conteúdo
Bala de prata e cegueira (clique para ver os comentários)
Qui, 29 de Julho de 2010 (atualizado em Ter, 24 de Agosto de 2010)
Tenho visto, de uns anos pra cá, uma crescente preocupação com otimização de performance para websites. Isto é muito bom, e quem ganha são os usuários.
No entanto, o que me preocupa é que, como com qualquer tecnologia ou conceito novo (neste caso não tão novo), há uma tendência de adoção cega. Guidelines (como esta) são seguidas à risca, mas sem serem analisadas a fundo, sem limites de uso.
Todos estes conceitos possuem vantagens e desvantagens, e é sempre necessário analisar onde, quando e como devemos usar. Vamos expor alguns casos, e usar bem recomendações:
Concatenação de arquivos de mídia
Já trabalhei em projetos que usavam uma série de bibliotecas de JavaScript, e também uma ferramenta que concatena estes arquivos para diminuir a quantidade de requisições ao servidor. O problema é que a ferramenta estava sendo usada para juntar, em um "arquivo" (na verdade apenas um resource que respondia como se fosse um arquivo), as bibliotecas A e B, e, em outro "arquivo", as bibliotecas A e C, e, em outro, as bibliotecas A, D e E. Cada vez que o browser reconhece uma destas chamadas, ele baixa um "arquivo" diferente; Vejam só: ele está baixando três vezes a biblioteca A, pois ela está misturada em resources diferentes, não podendo ser reconhecida pelo browser antes de ser baixada, para que seja cacheada.
Para melhorar isto, já que a lib A está sendo usada em vários lugares, separe-a do resource; Assim, ela será baixada apenas uma vez pelo browser, e os outros resources com JS concatenado ficarão também menores e mais rápidos para baixar.
Cache definido em cabeçalho de requisição
Oba! Vamos definir um cache de um ano para todas as mídias do nosso site, assim ficam guardadas no browser do usuário e o site ficará mais rápido! OK, e quando tivermos que atualizar as mídias? Ops... Fica a dica: ou você pode diminuir o tempo de cache, para que seus usuários não demorem tanto a receber as mídias, ou você pode controlar as versões dos arquivos através de uso de query-string em suas chamadas (por exemplo, "myLib.js?v=2010-07-29"). Sempre que alteramos qualquer parte da URL, mesmo query-string, o browser encara como um resource diferente, portanto baixando-o novamente. Se a equipe de desenvolvimento tiver disciplina, pode funcionar muito bem o controle manual destas versões, caso contrário pode-se criar um controle automatizado.
Compactação/otimização de mídias
Cuidado! Nem sempre um compactador/otimizador de mídias que é famoso, ou é feito por uma empresa famosa, é 100% confiável. Vejam o caso do Google Closure Compiler, por exemplo: é uma ferramenta que promete muito - até porque otimiza a própria estrutura de JavaScript através de manipulação do escopo das funções. No entanto, a equipe de desenvolvimento do jQuery teve de deixar de usá-lo, pois a otimização estava gerando bugs no código que era gerado. Agora, uma ferramenta como JSMin, por exemplo, que é relativamente antiga, amplamente testada e que pode ter uma força de atuação pequena no código, é mais confiável. (JSMin atua apenas removendo comentários e espaços em branco onde adequado.)
Conclusão
Tanto quanto com padrões de projeto, o mais importante é saber onde não usar estas tecnologias, pois elas podem trazer efeitos colaterais. Se estiver em dúvida, não use nenhuma!