diogobaeder - Antigos

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!

Embora o CSS seja uma linguagem de estilização de fácil compreensão, sempre tem algum truque interessante para aprender e que vá ajudar na hora de montar layouts de páginas Web, principalmente quando você quer chegar num resultado visual e com as propriedades normais da linguagem não é possível. (Alerta: evitem hacks, exceto quando se fazem realmente necessários!)

Um desses resultados desejados é margem superior de um elemento de exibição em bloco ("display: block"), mas tendo como referência a parte inferior do último elemento acima dele. O que acontece quando elementos dentro deste elemento de cima são postos a flutuar, com, digamos, um "float: left"? PAM! (Som de mensagem de erro do Ruindows) O elemento de cima pára de considerar a altura real dos elementos flutuantes e deixa de ser referência efetiva para a margem superior do elemento de baixo. Isto às vezes é um efeito muito indesejado, pois a caixa blocada é sobreposta pelos elementos flutuantes.

Existe uma primeira alternativa que funciona muito bem: é o famoso clearfix. Ele se apresenta de diversas maneiras, e o que costumo usar é um elemento blocado vazio com um mero "clear: both", pois, assim, este elemento não-flutuante é empurrado pelos flutuantes, e a caixa envoltória volta a considerar a altura composta por seus elementos internos. Esta solução é simples e fácil de entender quando encontrada, mas apresenta um problema: é preciso inserir um elemento extra na marcação, o que quebra a semântica do código de marcação.

No entanto, durante um papo após uma apresentação de produto que fiz na reunião de webmasters do UOL, recebi uma dica muito bacana de um amigo de lá, o Renato Rodrigues (salve, Ambi!): "overflow: auto". Só. Simples, funcional. Sem quebra de semântica. ;-)

Como funciona: você aplica esse par propriedade-valor no elemento contêiner dos flutuantes, e ele volta a considerar a altura composta por eles. Problema de margem superior do elemento abaixo resolvido.

Só que, ainda assim, é importante considerar uma coisa: você deve ter precaução usar este truque em conjunto com uma altura definida e fixa da caixa-contêiner, caso contrário ela passará a ter barras de rolagem - neste caso, é melhor se ater ao clearfix, mesmo... -.

Acabo de resolver um bug que estava me incomodando neste site. Toda vez que a interface é manipulada, aqui, as configurações de janelas são persistidas em cookies; Acontece que, cada vez que os dados eram persistidos por mim mesmo, eu não conseguia mais acessar o módulo administrativo, e, aparentemente, as configurações deste site estavam afetando outros sites quando usando o Google Chrome. Bizarro.

A solução exata eu não sei qual foi, mas tomei duas medidas para tentar chegar nela: reduzir o tamanho da string construída para cada config de janela, e remover caracteres estranhos dos nomes dos cookies (estava usando ":" e "-" dentro deles). Não sei qual dos dois foi decisivo para a solução, mas foram duas boas práticas que já deram um ótimo resultado. Além de reduzir o tráfego de rede - pois a cada requisição para páginas eles são enviados no cabeçalho HTTP -. ;-)

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!

Este website foi feito em Django. Confesso que estou apaixonado tanto pela linguagem Python quanto pelo framework; Nunca tive tanta facilidade de criar uma aplicação web, e tão rápido! :-) Enfim, recomendo a todos que desenvolvem nesta área... muito bom mesmo!