LuizTiago.com - WebDeveloper

Blog

Performance em todos os contextos: Parte 01

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 porque...

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. Performance é algo que é preciso que todos os envolvidos tenham conhecimento pelo menos superficial. Do que adianta você investir tanto nisso, se seu cliente insiste em querer aquele visual carregado e com 1 milhão e meio de funcionalidades inúteis, onde todo e qualquer usuário não vai aguentar passar nem 10 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 iria aparecer um concorrente que iria fazer a mesma coisa, dando a resposta de forma bem mais rápida e iria conquistar todos 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 é, não chega nem perto, mas o intuito deles não é passar tanta informação como eles, ganhando alguns segundos de crédito no carregamento. Mas paciência tem limite. 20 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 são responsáveis pela grande maioria do tempo de carregamento, e 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 possuem etapas que perdem muito tempo e gera 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 1 arquivo, e só gera o trafego 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, no qual é mais simples (principalmente se feita em editores WYSIWYG), porém hoje é bem menos utilizada.

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.

Comentários

Dennis Cavalcanti Calazans
Belo post. Posso dizer que o projeto que você desenvolve ai na empresa influenciou o topico? =P Parabens pelo site, amigo. Abraço.
Luiz Tiago Oliveira
Com certeza. Influenciou um bocado. O tema das últimas palestras que tenho apresentado também é abordando o mesmo conceito, só que sem aprofundar muito a parte técnica. Valeu pelas palavras, amigo!

Comente