Comecei a trabalhar com desempenho web por volta de 2003. Minha primeira descoberta importante foi a Regra de Ouro do Desempenho:

80-90% do tempo de resposta do usuário final são gastos no frontend. Comece por aí.

Até aquele momento, toda a minha experiência em desenvolvimento web tinha sido no backend – Apache , MySQL, Perl, Java, C e C++. Quando eu vi quanto tempo foi gasto no frontend, eu sabia que a minha pesquisa de desempenho teria de se concentrar lá.

Minha primeira discussão sobre desempenho web foi com Nate Koechley quando ambos trabalhamos no Yahoo! (agora nós dois estamos no Google!). Eu não conhecia Nate antes, mas alguém me disse que ele era a pessoa certa para falar sobre desenvolvimento no lado do cliente. Eu não acho que YUI existia ainda, mas Nate e outros futuros membros da equipe YUI estavam presentes, levando bolsões de desenvolvimento web para toda a empresa.

Deus abençoe o Nate e essas outras pessoas que me ajudaram. Eu era tão ignorante. Eu era bom em encontrar ineficiências de desempenho, mas não tinha feito muito desenvolvimento frontend. Eles me ajudaram a traduzir essas ineficiências em melhores práticas. Isso era o início do desenvolvimento frontend. Na verdade, quando eu estava escrevendo meu primeiro livro, não sabia que palavras usar para me referir a meu leitor-alvo. Perguntei Nate e ele disse “F2E – frontend engineer” (engenheiro frontend).

Hoje pode parecer engraçado fazer essa pergunta, mas a engenharia frontend era uma nova disciplina na época. Isso foi antes da YUI, antes do Firebug, do jQuery – há muito tempo! Naquela época, a maioria das empresas pedia a seus desenvolvedores backend (Java e C) que tirassem uma casquinha do código frontend (Provavelmente, você teve um bom começo se você conhecia Java, porque o JavaScript era provavelmente muito similar).

Voltando para os dias atuais, quando a maioria das empresas web de médio a grande porte tem engenheiros frontend dedicados, e muitos têm equipes de engenharia frontend dedicadas. Engenharia frontend já percorreu um longo caminho. É uma disciplina reconhecida e respeitada, tida como fundamental por qualquer pessoa com uma presença significativa na web.

Eu gosto de pensar que o desempenho web ajudou a engenharia frontend a crescer para o papel que ela tem hoje. Quantificar e evangelizar como o desempenho na web é fundamental para criar uma boa experiência de usuário e melhorar a métrica do negócio exigem atenção no frontend. Pessoas que conhecem a Web sabem que a qualidade não para quando os bytes deixam o servidor web. O código executado no browser é altamente otimizado. Alcançar esse objetivo requer engenheiros qualificados com as melhores práticas estabelecidas, e a vontade e a curiosidade de se adaptarem a uma plataforma em constante mutação. Graças a Deus por engenheiros frontend!

Esse é o resultado da minha reflexão sobre o estado do desempenho web e como ele precisa crescer. Eu recentemente falei e escrevi sobre o estado geral da Web em termos de desempenho. Embora os tempos de carregamento da página tenham se tornado mais rápido no geral, isso acontece principalmente devido às velocidades de conexão mais rápidas e a navegadores mais velozes. A qualidade de desempenho dos sites parece estar ficando pior: as páginas são mais pesadas, menos recursos são armazenados em cache, o tamanho do DOM está crescendo etc.

Como podemos melhorar o desempenho web daqui pra frente?

O estado do desempenho web hoje me faz lembrar a engenharia frontend em seus primeiros dias. A maioria das empresas não tem engenheiros de desempenho dedicados, deixando equipes de desempenho sozinhas. Em vez disso, o trabalho de melhorar o desempenho é designado para equipes existentes. E como o desempenho web abrange frontend, backend, ops e QA (Quality Assurance), não está claro qual equipe deve “montar o rebanho”. Eu concordei cada vez que uma nova e melhor prática de desempenho foi encontrada. Muito já se sabe, e o corpo de conhecimento está crescendo.

Pedir para desenvolvedores backend fazerem engenharia frontend é um erro. Engenharia frontend é uma disciplina estabelecida. Da mesma forma, pedir para engenheiros fronted|backend|ops|QA assumirem engenharia de desempenho é um erro. Engenharia de desempenho é a sua própria disciplina. O problema é que muitas pessoas não perceberam isso ainda. Nossa qualidade de desempenho se degrada à medida que pedimos equipes para focarem no desempenho “apenas por este trimestre” ou por “25% do seu tempo”. Progresso é feito e, em seguida, se desgasta quando a atenção é focada em outro lugar. Melhores práticas são adotadas, mas mesmo as melhores práticas se perderão, se não levar o desempenho em consideração.

O que é necessário são engenheiros de desempenho web dedicados e equipes de desempenho dedicadas. Assim como engenharia frontend, essas equipes vão começar pequenas – apenas uma pessoa inicialmente. Mas todo mundo vai ver rapidamente como os benefícios são maiores, são alcançados mais cedo, e não vão regredir. As melhores práticas tornam-se mais amplamente conhecidas. E a qualidade do desempenho Web vai crescer firmemente.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.stevesouders.com/blog/2013/08/27/web-performance-for-the-future/