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!
Acelerando carregamento de mídia (clique para ver os comentários)
Dom, 16 de Agosto de 2009 (atualizado em Seg, 17 de Agosto de 2009)
Coloquei meu site no ar estes dias, e, embora já estivesse esperando isto, acabei achando-o um tanto lento para carregar e construir toda a interface - o principal motivo é todo esse lance das janelas e preparação para persistir as modificações do usuário -.
Comecei a explorar o que meu servidor de hospedagem (WebFaction) oferece, e seguir as guidelines do Yahoo! e do Google para tentar otimizar o carregamento de arquivos de mídia - leia-se CSS, JavaScript e imagens -.
Um dos passos mais importantes foi usar um servidor alternativo ao Apache, o ngynx, que é excelente para servir conteúdo estático - veja aqui a comparação entre os dois neste contexto -.
Outro passo foi usar um domínio diferente do meu original para carregar as mídias; Pelo fato de elas serem carregadas em outro domínio, os cookies não são enviados na requisição nem recebidos na resposta HTTP.
Em conjunto, estas duas medidas fizeram com que houvesse uma melhoria gritante de performance no site. Porém, ainda desejo criar uma forma de fazer compressão automática de JavaScript e CSS, usando o YUI Compressor. Quando tiver resultados, postarei aqui novamente!