funmachine

Por uma web melhor

1 Comentário

Á muito que construir websites se tornou mais do que bater um HTML e programar umas funcionalidade básicas crud em php. Com a migração de tanto serviços para a web, com recursos cada vez mais acessíveis que permitem virtualmente qualquer pessoa de construir um website preparado para receber milhares de visitas usando tecnologias actuais e disponíveis a preço baixos, o foco tem sido construir aplicações mais apelativas, com funcionalidades e UI mais fáceis e eficazes, e no fundo o santo graal é produzir a melhor experiência possível as pessoas que usam o nosso site, pois isso sim, pode ser um factor que diferencia o nosso trabalho do resto da concorrência. A Yahoo tem feito um trabalho notável no que toca a melhorar a usabilidade e experiência dos seus serviços web. Á uns meses atrás comecei a usar a ferramenta YSlow, que permite analizar problemas de performance e indica soluções para os resolver. A seguir seguem “algumas regras” que surgiram nos labs da Yahoo e que tive oportunidade de comprovar e estudar melhor enquanto usava a YSlow. Curioso é que em grande parte das regras a conclusão que cheguei é que não à regras! Tudo depende da aplicação, dos requisitos, do público, etc.

Páginas mais rápidas

Existe um “truque” simples para servir páginas web mais rapidamente: minimizar os pedidos HTTP. A maior parte do tempo que uma pessoa passa num website, está a navegar e consequentemente a fazer pedidos ao servidor por recursos (html, css, javascript, media). Além disso, li por aí que 40-60% dos acessos a um website são novos utilizadores, e isso implica que têm que carregar todos o website e seus recursos. Também não podemos esquecer a natureza do protocolo HTTP 1.1 que não permite mais que dois pedidos por recursos, o que faz com que os pedidos HTTP sejam quase consequentes, uns a seguir aos outros.

Vejam um pequeno exemplo do que acontece em background quando acesso a um website pela primeira vez:

HTTP requests

HTTP requests

Como podem ver, uma série de pedidos são feitos ao servidor, primeiro a página html, e depois o browser tem que carregar todos os recursos (html, js, css) a seguir.

Uma forma simples de minimizar os pedidos é combinar ficheiros, isto é, colocar CSS num só ficheiros, os JS num só ficheiro, etc. Pela minha experiência, o melhor a fazer é usar este método como parte da versão release, e não na fase de produção. Existem alguma ferramentas para o fazer de forma automatizada, que simplificam o processo.

Claro que combinar ficheiro pode ser uma tarefa desafiante, até porque podemos acabar com um único ficheiro monstruoso! Imaginem que um website tem vários javascript, alguns são necessários o mais rápido possível (por exemplo: uma galeria de imagens js que tem que ser renderizada na página inicial); outros, não são necessários com tanto urgência (um uploader de ficheiros, ou js que só são utilizados depois de algumas interacção com o site). Neste caso convém servir o mais rápido possível os ficheiros mais urgentes (geralmente aqueles necessário para construir as interfaces visuais). No fundo, é tudo uma questão de engenharia ;), o importante é conhecer as técnicas, e ter uma boa capacidade de análise e decisão sobre a melhor forma de as usar!

Usar CSS Sprites! Quem já teve a oportunidade de programar um jogo 2D, por exemplo em J2ME ao algo estilo 8bits, sabe com certeza o que são Sprites. A ideia é colocar as imagens de background do website numa única imagem e depois usar as propriedades background-image e background-position para posicionar a parte da imagem correctamente! Nice and easy! Podem ler mais sobre CSS Sprites neste artigo

Comprimir os ficheiros, uma forma fácil de tornar as páginas mais rápidas é enviar como ficheiros zipados (gzip). Todos os ficheiros de texto valem a penas ser comprimidos (html, css, js), já imagens e pdfs não faz sentido nenhum porque já são comprimidas de qualquer forma. O truque aqui é que o browser tem que dizer no header que aceita gzip ao servidor (accept-encoding: gzip) e o servidor tem que responder que o conteúdo está comprimido (content-encoding: gzip). Existe alguns problemas com versão de museu do IE, mas vivemos no século XXI.

Distribuir media com uma CDN, a ideia ao usar uma CDN é que os medias ficam alojados em servidores espalhados pelo mundo, quando um utilizador aceder ao website os serviços da CDN encarregam-se de servir os medias a partir do servidor da sua rede que esteja mais perto da localização física do utilizador. A amazon s3 é um bom exemplo e serviço que podem usar, mas tenham em atenção que usar uma CDN trás obviamente mais custos e só faz sentido em relação a aplicações web que têm ambição de ser usada a nível internacional. Uma pequena técnica que também podes utilizar é incluir componentes que existem em serviços como o google. Por exemplo, se fazes uso de bibliotecas Javascript como JQuery, podes incluir os ficheiros a partir dos servidores da google.

Usa Expires ou Cache Control Header nos teus componentes, a ideia aqui é simples, se definires o Expire Header para virtualmente “Never Expire”, o browser terá que fazer menos pedidos HTTP pois o conteúdo está disponível em cache, aumentando assim a performance do website. Atenção que implementando esta técnica, um utilizador que já visitou o site pode não receber actualizações que tenhas feito nos componentes. Imagina que actualizas-te uns ficheiros javascript ou css; se um utilizador já visitou o teu site no passado, e definis-te Never Expire para esses ficheiros…bem, possivelmente ele nunca vai receber os ficheiros actualizados, a não ser que a cache seja limpa. Uma técnica simples é nomear os teus ficheiros com número de versão, e alterar o nome sempre que actualizares um ficheiro.

Minify JavaScript e CSS, uma técnica muito simples, remover os espaços desnecessários nos ficheiros de texto js e css, dessa forma diminui o tamanho dos ficheiros e torna o download desses mais rápido. Claro que só podemos fazer depois do código estar completo, e existem uma série de ferramenta que nos ajudam nessa tarefa como o JSMin ou YUI Compressor.

Evitar Redirecionamentos, o problema é que degrada a experiência do utilizador ao navegar no website. Podem existir muitas causas para usar redirecionamentos desde URLs sem “/” no fim que pode fazer ocorrer um redirecionamento para o mesmo URL com “/” no final, até questões programáticas, com determinadas condições redirecionar o utilizador para aqui ao para ali! Na Framework CakePhp usar redirecionamento é quase um must, estando mesmo disseminada pela documentação, livros e tutoriais sobre a framework. A razão é simples, a verdade é que usar esta técnica facilita a vida dos programadores, mas, degrada a navegação e experiência dos utilizadores. Mais uma vez é uma questão de compromisso e engenharia, estudar e decidir quando faz sentido ou não usar redirecionamentos.

Cookies, são usadas e tornam a vida simples por uma variedade de razões, tais como persistir autenticação e personalização (guardar dados sobre utilizadores para fornecer uma experiência mais rica no website). Apesar de simples, a filosofia por trás das cookies pode esconder alguns problemas de performance. Uma cookie está constantemente a ser trocada entre o servidor e o cliente. O cliente fica com a cookie, o que é um bom princípio pois assim facilmente podemos personalizar experiências para aquele cliente em concreto ao longo de várias sessões no website. O servidor lê informações da cookie para… bem, para fazer o que entender, tal como personalizar a experiência do utilizador. No entanto esta troca constante de cookie implica uma resposta mais lenta. Para minimizar este aspecto devemos manter o tamanho das cookies o mínimo possível, e ter atenção ao Expire da cookie, quanto mais baixo mais depressa a cookie é apagada, aumentando a performance da aplicação. Mas, mais uma vez, isto depende sempre dos requisitos da aplicação.

Reduzir o número de nodos DOM, uma pequena nota sobre o DOM, é lento, lento, lento. Apesar de ser fácil de percorrer e manipular o DOM e actualmente ser fundamental para darmos animação e construir UIs mais eficazes para os utilizadores, a contrapartida é que é uma estrutura de dados muito ineficiente, na práctica lenta! Eliminar nodos DOM desnecessários é a regra de ouro. Uma outra técnica é evitar criar nodos directamente com JS quando podemos inserir logo como parte do HTML.

Uma ferramenta espectacular que podem utilizar para verificar a performance das vossas aplicações web é o YSlow, esta ferramenta da yahoo resulta de anos de experiência e investigação em tornar as aplicações web mais eficientes. Muitas das regras que escrevi resultam de leituras que fiz tanto no site do YSlow como em blogs da yahoo, estes tipos têm feito um trabalho muito bom em tornar a web um local um bocadinho melhor. Lá podem encontrar muitas mais regras, teorias e experiências com vista a aumentar a performance das aplicações web.

O truque está na capacidade de analizar, é um trabalho em vão compilar estas regras todas e aplicar escrupulosamente em todos os projectos web. A forma correcta e conhecer estas prácticas, e caso a caso analizar as consequências de aplicar esta ou aquela técnica, só assim conseguimos construir aplicações melhores, mais eficazes e melhores as experiencias de quem navega nos nossos websites.

Anúncios

One thought on “Por uma web melhor

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s