Web Sites de Alta Performance, Parte 1: A Regra do 80-20 da uma Página Web

Este post é o primeiro de uma série que irei denominar de Web Sites de Alta Performance. Esta série é inspirada e baseada no livro High Performance Web Sites de Steve Souders, na posição de Chief Performance Yahoo!. O livro é fino, leve e bastante objetivo. Esta série tem o objetivo de resumir as técnicas apontadas por Souders.


Assim como diversos engenheiros de software que conheço, eu já me dediquei bastante a otimizações no lado do servidor, como melhorias no uso de memória e índices de bancos de dados, etc. Porém, para a maioria de páginas web, menos de 20% do tempo de resposta para o usuário final é gasto levando o HTML de resposta do servidor para o browser. Portanto, ao otimizar algo no lado do servidor, você estará otimizando algo que consome menos de 20% do tempo total de resposta.

Para conseguir resultados visíveis para seus usuários, é preciso atacar a causa dos 80% restantes do tempo de resposta. Esta série mostra conceitos que explicam o funcionamento de páginas web e algumas técnicas capazes de tornar suas páginas mais rápidas.

Analisando a performance de uma página

Para você conseguir ver como uma página qualquer é carregada e o tempo que ela gasta para ser carregada, vou sugerir o uso do browser Chrome do Google. Ele possui uma ferramenta de análise recursos carregados pelo browser (resources). Ao abrir o Chrome, acesse o site que deseja. Vá ao menu cujo ícone é uma folhinha (ao lado direito da barra de endereço do Chrome), selecione Desenvolvedor e em seguida Console Javascript. O Console possui dois itens principais: Elements e Resources. Clique em Resources. Agora, vá para a janela do browser e e dê um Refresh. Após carregar a página novamente, volte para a janela do Console e veja o resultado.
É possível ver muito claramente quais são todos os recursos carregados pelo browser para que a página final seja apresentada corretamente para o usuário: Html da página em si, imagens, arquivos CSS, arquivos Javascript. Cada recurso desse é um request feito ao servidor para que ele seja encontrado e baixado. Uma ferramenta de análise desses recursos sendo baixados é muito importante para podermos ver como nossa página está hoje e como ela estará depois de aplicadas as técnicas que serão expostas nesta série de posts do meu blog. Acho que o Firefox também deve ter algum plugin que fornece este tipo de informação.

O que essas ferramentas irão fornecer é uma visão como a da figura abaixo (que é a análise do carregamento da home do www.yahoo.com):


Afinal, porque uma página demora para ser apresentada?

Ao analisar o carregamento de uma página (com uma dessas ferramentas citadas acima), é possível ver que uma página comum (como por ex.: www.yahoo.com), ao ser carregada pela primeira vez no browser (sem nada no cache), gasta pelo menos 80% do tempo de carregamento total com os componentes da página (imagens, arquivos css e javascript, etc). Quando eu digo carregamento total, quero dizer:
  • Request de cada componente;
  • Requests que não ocorrem em paralelo (scripts não são baixados em paralelo);
  • Parse de Html, CSS e Javascript;
  • Renderização final
Ver onde que o tempo é gasto é desafiador. Mas ver onde que ele não é gasto é fácil: o tempo de carregamento de uma página não é gasto em sua maioria no download do documento HTML que é gerado pelo processamento do servidor, incluindo lógica de programação no servidor, acesso a banco de dados, etc.

Portanto, a regra para se manter em mente aqui é: APENAS DE 10% - 20% DO TEMPO DE CARREGAMENTO DE UMA PÁGINA É GASTO COM A GERAÇÃO DO HTML QUE VAI PARA O BROWSER. OS OUTROS 80% - 90% SÃO GASTOS CARREGANDO OS DEMAIS COMPONENTES DA PÁGINA.


6 comentários:

Roberto Furutani 24 de fevereiro de 2009 às 20:46

Olá!
Parabéns por esses artigos.
Uma coisa que me chamou atenção foi o gráfico.
Esse gráfico de requests você conseguiu ele com qual programa?

Felipe Nascimento 24 de fevereiro de 2009 às 21:51

Opa,
esse gráfico em particular, é apenas uma imagem que eu consegui na web. Mas é possível ter um parecido (na verdade mais bonito) com as ferramentas de developer do browser Google Chrome. Também é possível usar uma extensão do Firebug chamada YSlow, do pessoal do Yahoo!: http://developer.yahoo.com/yslow .

Anônimo 28 de fevereiro de 2009 às 19:10

Ótimos posts Felipe! Mas fiquei com uma dúvida. Li uma vez (não lembro aonde) que o http conseguia fazer 2 downloads paralelos de scripts. Vc citou que isso não ocorre. Não é possível?

Felipe Nascimento 2 de março de 2009 às 01:40

Olá

segundo a especificação de HTTP/1.1, sugere que os browsers devem fazer dois downloads em paralelo por host name. Tanto o IE quando o Firefox seguem esta sugestão do protocolo. Porém, para scripts, o download paralelo é inabilitado no browser. Uma razão para isso é que o script sendo baixado pode usar o document.write para alterar o conteúdo da página. E o browser espera o fim do download do script para poder renderizar a página corretamente. Outro motivo é para garantir que o browser execute os scripts na ordem correta.
Apesar disso tudo, você pode tentar algo deste tipo aqui (por sua conta e risco):
http://blogs.msdn.com/kristoffer/archive/2006/12/22/loading-javascript-files-in-parallel.aspx

Anônimo 14 de março de 2009 às 20:28

Entendi. Serão dicas valiosas!
Obrigado.

Unknown 15 de abril de 2009 às 16:54

Parabéns pelos artigos Felipe. Ultimamente tenho me interessado muito por esse assunto, e seus posts, assim como a dica do livro, serão valiosos.
Abraço!