Princípio de pareto: A teoria 80/20 aplicada ao desenvolvimento de web

Sou fã do Yahoo. Isso é uma coisa que não se ouve muito por ai, geralmente o bam bam bam é sempre o Google. Mas o Yahoo tem umas sacadas para desenvolvedores que o Google não tem, como Hack Day e o Yahoo User Interface Blog. No YUI você encontra muita coisa interessante pouco divulgada por ai. Vi um dias desses um artigo chamado Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests relacionando a teoria de pareto com ganhos de performance nos sites. A idéia em si não é nova e nem sua aplicação, ainda assim achei muito pertinente.

Vilfredo Pareto econonista italiano, observou que 80% da riqueza da Itália provinha de 20% da população. O princípio de pareto (também conhecida como regra 80/20) diz que para cada fenômeno, 80% das consequencias vem de 20% das causas. Esta é uma suposição que prega que a maioria dos resultados em qualquer situação é determinado por um pequeno número de causas e este princípio é aplicado em estudos relativos a economia, produtividade, política, desenvolvimento etc e onde mais este “padrão” for observado.

O texto do Yahoo diz que em desenvolvimento de software ou aplicações web, 80% do tempo gasto em um projeto, somente 20% é dedicado a código. Os caras fizeram uma pesquisa de performance no site do Yahoo para descobrir qual o tempo de resposta do browser para requisitar a página no servidor, e fazer o download dela renderizando no cliente como mostra o gráfico abaixo.

grafico

Comparando estes dados com outrs requisições e com outros sites, eles viram que do tempo total até um site ser acessado e ser completamente renderizado no browser, de 5% a 38% é gasto em requisitar o HTML e os outros 80% a 90% são gastos em requisitar coisas que estão linkadas no HTML, como imagens, scripts, folhas de etilos etc. Os browsers baixam em paralelo somente 2 ou componentes até solicitar o download dos próximos em alguns casos. E a conclusão lógica é que boa parte dos ganhos de permormance pode estar em reduzir o número de requisições ao servidor. O próximo texto deles vai falar de cache.

Para muitos isso é muito muito óbvio, mas eu só escrevi este texto porque eu acredito que é uma grande defesa aos padrões web se bem explicada e um grande argumento de venda. Quando você desenvolve em camadas separando o conteúdo da apresentação, você tem menos código a ser baixado e parte dele será cacheado. Principalmente os e-commerce que possuem um fluxo de navegação interno maior, e várias páginas são requisitadas ao servidor neste fluxo, boa parte do que for requisitado já foi cacheado como estilos e scripts. Mas muitos ainda são fãs de utilizar scripts dentro da propria página e estilos inline.

Imagine se você consegue reduzir 15kb nas principais páginas de um site com 20 mil acessos por dia. Qual seria a economia de banda no servidor e em quantos segundos no total seria possível melhorar a experiência do usuário no site tornando-o mais rápido? ROI pra você. Isso não justifica você investir nos 20% que corresponde a 80% do resultado de um site leve e otimizado para uma boa experiência com o usuário?

12 Responses to “Princípio de pareto: A teoria 80/20 aplicada ao desenvolvimento de web”

  1. Carlos André

    Concordo plenamente com a ideia, outra pratica muito legal é o CSS modular, onde só é requisitado os arquivos CSS necessários em um determinado lugar, o que eh comum fica em cash.

    tenho um site aqui, que tem suporte a skins, e tem cerca de 40 arquivos CSS. (8 skins)

    no primeiro acesso demora um pouco porque baixa os CSS comuns junto com o skin, mas depois a troca de skin eh instantanea pois no arquivo soh tem as deficicoes de imagem, cores e posicionamento.

    E isso é um ótimo motivo para se justificar o uso de ajax e explica o pq as aplicações com essa tecnologia são tão mais agradaveis de se usar.

    []'s

  2. Artigo muito pertinente!

    Com certeza os Web Standards fazem a diferença, principalmente no caso de sites de grande porte pois, separando-se o conteúdo da informação, o tráfego diminui consideravelmente.

    Como afirmado anteriormente, grande parte das consequencias vem de poucas causas… Aí já podemos ter uma idéia do que podemos fazer quando eliminamos ou praticamente extinguimos essas "causas".

  3. Rafael Dourado

    Os desenvolvedores de plugins para WordPress deveriam se tocar disso e parar de fazer plugins ajax com javascript e css inline.

  4. Muito interessante mesmo o estudo do Yahoo, vou repassar pra minha equipe.

    Um cara que foi dar palestra ontem na faculdade sobre padrões web falou que a ESPN remodulou o site para os padrões e passou a economizar coisa de terabytes de banda. Bastante, não?!

  5. Um estagiário de Ciência da Computação que tive (hoje ele está na http://www.cumplice.net) me contou esta história em 2000. Estávamos discutindo sobre o recorte de imagens – se seria melhor picar uma imagem grande em várias outras menores, separadas por áreas ou cores, ou manter as imagens maiores para diminuir as requisições no servidor…

  6. Rangel

    Muito bom o post, mostrando de uma maneira bem prática um bom motivo para seguir os web standards!!

    Parabéns!

    Abs

  7. Muito bom o post.

    Mas muitos sites são lentos por causa do monte de imagens de alta qualidade.

  8. Leandro

    Realmente… para sites com milhões de acessos 15kb fazem diferença na banda, porém estes sites são excessões.

    Acho que Padrões Web estão longe de serem comercialmente viáveis. Além de exigir mais tempo para desenvolvimento de uma página, a redução do tamanho de um arquivo (15kb) é irrelevante para os tamanho de bandas utilizados atualmente.

    A diferença de tempo entre uma página de 90kb e uma de 75kb é imperceptível. Já passou o tempo da linha discada. E isto só tende a melhorar.

    Se a redução de arquivo fosse algo em torno de 100Kb seria relevante.

  9. Erik Marques

    Muito show o texto, relamente se aplicado de forma certa, a experiência em navegar nos sites será muito melhor. Agora basta aplicar tudo isso 100% na prática.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>