Ultimamente venho conversado bastante sobre o uso de linguagens de programação baseadas em MVC, e particularmente em dois frameworks bastante conhecidos (Ruby on Rails e o Zend).
Além da agilidade no processo de desenvolvimento e manutenção, ambos também procuram focar também em questões de performance.
Sou amplamente a favor de melhorias gerais, principalmente quando a questão é esta: performance. Esta palavra soa nos meus ouvidos como algo genial e de extrema importância e vou explicar o porquê.
Antes de se pensar em performance, é preciso que o desenvolvedor mergulhe de cabeça no projeto que está desenvolvendo e entenda qual o seu objetivo. É um assunto no qual todos os envolvidos devem ter um conhecimento pelo menos superficial.
Do que adianta você investir tanto nisso, se seu cliente insiste em querer aquele visual carregado e com um milhão e meio de funcionalidades inúteis, onde todo e qualquer usuário não vai aguentar passar nem dez segundos em seu site?
Sempre que eu tento fazer alguma explicação, tento apresentar universos bem distintos para facilitar o entendimento. Será que o Google faria tanto sucesso se sua página de pesquisa fosse carregada em “intermináveis” 20 segundos? Creio que não.
Rapidamente vai aparecer um concorrente para fazer a mesma coisa, dar a resposta de forma bem mais rápida e conquistar os seus usuários. Porém, existem situações em que o conteúdo não é tão importante. Quando pesquisam e entram em seu site, o que vale mesmo é o apelo visual.
Já imaginou se o site de sua cerveja favorita tivesse o visual do Google? Pois é, o intuito não é passar tanta informação, ganhando alguns segundos de crédito no carregamento. Mas paciência tem limite. Vinte segundos para quem está na frente de um computador esperando uma página carregar parece uma eternidade.
Mas onde eu quero chegar com isso? Em primeiro lugar, é preciso colocar na cabeça em qual situação você se encontra para se encaixar e fazer o que tiver que fazer bem feito.
Consultas ao banco e montagem do html são coisas que normalmente não passam de 10% do carregamento normal de um website. Para se investir em performance, é preciso estar focado principalmente na camada do cliente. Esta sim normalmente é responsável pela grande maioria do tempo de carregamento.
Estudar bastante as técnicas para melhoramento são pontos bastante positivos para quem quer se destacar no mercado de trabalho. Para ajudar, iniciarei algumas dicas por etapas que lhe ajudarão a melhorar esta camada em seus projetos.
Em primeiro lugar, uma das regras mais claras e objetivas é: menos requisições HTTP.
O objetivo é reduzir isto ao máximo, pois cada requisição, independente do tamanho do arquivo, possui etapas que perdem muito tempo e geram tráfego desnecessário no servidor. Para diminuir estas requisições, existem algumas regrinhas básicas:
Arquivos externos devem ser agrupados
Para ajudar no desenvolvimento, existem algumas formas que são as mais utilizadas para organização dos arquivos externos (CSS/JS):
A primeira, os arquivos CSS e JS são quebrados em várias blocos e cada bloco só é chamado de acordo com a necessidade daquela página. Ou seja, uma página pode precisar do script1, script2 e script3 enquanto outra página só precisará do script2 e script4.
Porém, independente de quais scripts serão necessários, quanto mais scripts forem utilizados, maior será a quantidade de requisição feita no servidor. Em suma, reprovada.
Em segundo lugar, alguns desenvolvedores agrupam todos os arquivos CSS/JS de determinado site em apenas um arquivo, e independente de qual seção for carregada, todos os scripts serão requisitados, gerando menor quantidade de requisições do que a primeira forma, porém com tráfego desnecessário. Reprovada também!
A terceira e última forma parece ser a mais inteligente: a solução é seguir o modelo das linguagens compiladas e manter os arquivos modulares, criando também um mecanismo que gere os arquivos com os módulos necessários e especificados de cada página. Com isso reduz a quantidade de solicitações para apenas um arquivo e só gera o tráfego no servidor necessário. Desvantagem? O não uso do precioso conceito: cache. Mesmo assim, todos os especialistas defendem que é a melhor opção.
CSS Sprite / Image Map
Se pensamos tanto em redução de requisições HTTP, por que utilizar tantas imagens para aplicar efeitos e montar simples interfaces como menus?
Em primeiro lugar, é preciso analisar se é realmente importante ter um menu, títulos ou qualquer outra coisa utilizando imagens. Caso isto seja positivo, não é preciso gerar uma imagem para cada botão, nem para cada situação, seja um hover, active, visited, focus etc.
Para quem não conhece, o CSS Sprite permite que com apenas uma imagem, você trabalhe com vários botões, ícones, situações distintas utilizando apenas o posicionamento do background. Além disso, existe outra técnica (esta um pouco ultrapassada) do Image Map, mais simples (principalmente se feita em editores WYSIWYG), porém bem menos utilizada hoje.
Bom pessoal, por enquanto é isso. Irei escrever mais algumas técnicas e postarei em breve para vocês. Não esqueçam: comentem sobre o que acharam, suas experiências e se isto já serviu para melhorar algum trabalho que você está alocado. [Webinsider]
…………………………
Conheça os serviços de conteúdo da Rock Content..
Acompanhe o Webinsider no Twitter.
Luiz Tiago Oliveira
Luiz Tiago Oliveira (luiztiago@luiztiago.com) é sócio e gerente de Front-End da MGR Tecnologia, graduado em Webdesign e pós-graduando em Desenvolvimento Mobile.
13 respostas
Essas técnicas são bem antigas, mas ainda hoje funciona bem. Uma coisa que percebi que até hoje o google não dá relevância nenhuma para sites rápidos. Tem sites lentos e ainda estão no topo.
Interessante esse assunto
Primeiro tem que ver qual é a deficiencia do seu site para depois ver se Sprittte vai resolver. Não adianta ficar enchendo de plugins. Pode ser pior.
Tentando entender mais desse assunto. Vou aplicar essas dicas, e ver como fica, meu site com problemas nesse sentido.
Oi pessoal.
Adorei o artigo sob o aspecto de se iniciar essa discussão, porém não acho tão interessante o uso das técnicas mencionadas.
Já testei e não gostei. Ficou mais lento, pois os arquivos já eram grandes e agrupados ficaram maiores ainda!
O image map cria um código enorme também.
Acredito que o feijão com arroz é extremamente mais valioso:
– linhas de códigos bem estruturadas, com utilização da semântica;
– CSS leves e montadas de forma a agrupar várias linhas numa só, com eliminação de espaços também;
– imagens leves e otimizadas;
– uso do flash de maneira “racionalizada”;
– pasmen, a utilização de iframes!!!!!!!!!! Ainda uso iframes para puxar arquivos externos que não sejam conteúdos e deixam a página mais leve. Por exemplo, puxo no iframe um banner que usa jquery ou forms, assim não carrego na página principal nenhum java. É obsoleto? Sim, mas dá certo….
– Utilização do Ajax;
Tem que prevalecer o bom senso e fazer testes e mais testes!!!!
Vamos continuar com a discussão que tá boa.
E pra terminar, concordo com o Ney, vale um artigo de frameworks.
André M.
Só para complementar o artigo, deixo aqui um post do yahoo explicando detalhadamente esses 2 e outros conceitos bem interessantes http://developer.yahoo.com/performance/rules.html
Luiz, já ouvi falar sobre frameworks css como yui que auxiliam os designers a padronizar os htmls/css, se puder e achar interessante fica a dica para um futuro post.
Muito bem colocado, a otimização do número de requisições é muito mais importante do que o peso de fazer um Sprite ou agrupar os JS.
O Sprite ou o JS mais pesado compensa porque o intervalo entre uma requisição e outra pode ser bem grande caso a conexão do usuário for instável, o que não tem nada a ver com transferência.
Opa. Parabéns pelo artigo. Achei bacana!
Mas, ainda acredito que o uso de imagem e arquivos não otimizadas, ainda são os grandes vilões de um maior tempo de resposta.
Como já dito, cada caso é um caso. Utilizar ferramentas como Firebug, junto ao seu “mapeamento das requisições”, pode ajudar a visualizar os gargalos de seu site.
Bom artigo, em boa hora, já que o Google vai rankear melhor os sites que carregarem mais rápido.
Vale uma lida em http://viniciusban.blogspot.com/2010/04/rapido-eh-melhor-mesmo.html
Daniel Filho,
Como você falou, é preciso analisar o tamanho do projeto e ver o que realmente é interessante investir.
Além do que, sabemos que hoje até mesmo os sites de pesquisa estão utilizando o tempo de carregamento da página como mais um ponto para rankeamento. Com isso, fica cada vez mais importante o estudo destes conceitos.
Um abraço.
Manuel,
O uso de sprite e agregação do CSS deve ser utilizado de forma inteligente. Não adianta criar uma imagem para ser usada como sprite do título de diversas páginas internas, quando só me interessa abrir o conteúdo da página inicial. O mesmo serve para o uso de CSS. É preciso diminuir a quantidade de requisições, mas não exagerar no tamanho dos arquivos. Tem que usar o bom senso em tudo.
Quanto ao trabalho, isso exige qualidade em todo profissional. Se um projeto está utilizando técnicas comprovadamente ultrapassadas, deve ser estudado o melhor tempo para investir em novos conceitos. A quantidade de trabalho deve ser mensurada e colocada na balança para ver se o esforço é realmente necessário para aquele momento.
Cache é uma coisa bastante interessante quando bem utilizado (que em poucos projetos é bem configurado), mas não resolve tudo.
Existem várias técnicas e formas que ajudam o indivíduo a melhorar os seus projetos. E para atingir um ponto cada vez melhor de qualidade, é preciso usar bom senso e não apenas se concentrar em uma técnica. Estou preparando mais alguns ítens para publicar no próximo artigo. Fico aguardando a sua visita e caso se interesse, outros belos comentários! 🙂
Um abraço.
Realmente a discussão é necessária e deve adequar-se ao contexto do site/portal em questão. Características tais como número de visitantes diários, infraestrutura existente devem ser consideradas.
A visão do Manuel Lemos é de ser bastante considerada.
Evitar requisições ao máximo que se puder é uma boa ideia, mas não me parece que o uso sprites ou agregação de CSS e Javascript seja a solução mais viável ou sequer a mais eficiente.
Se você agrega todas as imagens de ícones em sprites, todos os scripts de Javascript ou todos os CSS em um só, quando os usuários chegam ao site vai obriga-los a esperar que carreguem arquivos maiores com todas ícones, Javascript e CSS para a primeira a página possa aparecer.
Fora quem quem já tem um site pronto com arquivos de ícones, Javascript e CSS separados vai ter um retrabalho muito grande alterar o código do site para ter um benefício duvidoso.
Uma alternativa mais eficiente que requer poucas mudanças é fazer com os arquivos estáticos (imagens, CSS e Javascript) é configurar o servidor Web para por a data de validade do cache desses arquivos para daqui a várias semanas ou meses. Isso faz com que o browser só peça esses arquivos uma vez no primeiro acesso e depois use a cópia que tem no cache durante o tempo de validade.