Melhorando significativamente a performance de aplicações web sem gastar tanto
Performance é uma coisa complicada. Sempre tem alguma coisa para melhorar na aplicação. Banco de dados, cluster, replicação de estado, cache dos dados, load-balance, pooling de recursos, processamento assincrono, networking, I/O… São tantas coisas que podem causar problemas de performance, gargalos, instabilidade, que nós, pobres desenvolvedores, ficamos perdidos!
Como diria Donald Knuth, “a otimização prematura é a raiz de todo o mal”. Ás vezes se gasta muito tempo otimizando determinada parte da aplicação, mas com um ganho de performance muito baixo. E além do tempo gasto na otimização, gastasse muito tempo testando se a otimização não quebrou o funcionamento da aplicação (ok, testes automatizados reduzem este tempo) ou testando quanto a performance melhorou por causa da otimização feita.
Sempre que se fala em melhorar a performance, muitos desenvolvedores pensam em load-balance, cache do banco de dados, pooling de recursos, melhoria nas queries, etc. Não há nada de errado em aplicar esses conceitos nas aplicações, inclusive muitas vezes isso deve mesmo ser feito. Mas quando se trata de aplicações web, a performance da aplicação, ou a percepção da performance da aplicação pelo usuário, pode ser melhorada por otimizações no front-end da aplicação, sem grandes alterações na arquitetura ou no código da aplicação.
Li recentemente o livro High Performance Web Sites, que traz 14 dicas para melhorar a performance de aplicações web alterando pontualmente o front-end das aplicações web. Algumas dessas dicas são bem fáceis de se implementar e trazem um excelente ganho na rapidez com que as páginas web são carregadas.
O livro diz que, na grande maioria dos casos, a maior parte do tempo gasto para visualizar uma página web é gasto na renderização do HTML pelo browser, e não no processamento da requisição web pelo servidor. Então vale a pena investir tempo e esforço para criar um front-end que é renderizado mais rápido pelo browser.
As dicas do livro são:
- Fazer menos requisições HTTP
- Usar uma Content Delivery Network
- Adicionar um cabeçalho “Expires” na resposta HTTP
- Utilizar Gzip para compactar os componentes da página
- Colocar os Stylesheets no topo da página
- Colocar os Scripts no fim da página
- Evitar CSS Expressions
- Colocar os códigos JavaScript e CSS em arquivos externos
- Reduzir DNS Lookups
- Compactar os códigos JavaScript
- Evitar Redirects
- Remover Scripts duplicados
- Configurar as ETags
- Make Ajax Cacheable
- Adicionar um cabeçalho “Expires” na resposta HTTP
- Utilizar Gzip para compactar os componentes da página
9 comments so far
Leave a reply
Muita gente menosprecia o YSlow mas como voce disse, ela é de grande ajuda, tem me servido bastante.
Esses artigos sao legais, nao e todos os dias que lemos sobre performance.
Além dessas dicas, com um DOCTYPE definido, a página é renderizada mais rapidamente. Interessante também é isolar todo os estilos e rotinas Javascript em arquivos distintos, pois esses ficam em cache no browser.
Muito boas as dicas, show de bola!
Vou experimentar esse YSlow qualquer dia.
Valeu!
Legais as dicas.
Já apliquei muitas delas num projeto e o acesso ficou realmente mais rápido!
Usando isto, com a nova geração de browsers com motor de javascript melhor, será bastante interessante o resultado final.
abraço
Obviedade!
Além de medir os resultados, o YSlow também mostra uma nota-conceito para cada item listado neste post. É possível, por meio da nota-conceito, atacar os pontos mais críticos para elevar o desempenho.
excelente artigo!
Achei muito legal essas dicas de performance.
Uma coisa que incomoda bastante e é simples de revolver são as referências às tagslibs. A cada utilização é necessário adicionar no web.xml.
Tem uma dica bem legal: coloque as taglibs mais utilizadas em uma JSP e faça referência a JSP usando a diretiva include quando for utilizá-la, ex:
Eu utilizei o mod_gzip para compactar páginas web, no tempo que rodava resin com Apache em Linux no ParPerfeito. A performance melhorou, mas o bom mesmo foi a economia nos gastos com banda. Eu achei que o Tomcat por default já servia páginas compactadas. Ótimo artigo!