Como otimizar a performance no front-end

O desenvolvimento de aplicações web que, até pouco tempo, focava em medições de performance apenas na arquitetura servidor e excluía toda a parte gráfica (principalmente por se tratar de GUIs desktop e estas serem deveras performáticas), se vê hoje forçado a entender como funciona a web, seus diversos protocolos, navegadores e, mais importante, as linguagens de programação que fazem tudo funcionar.

Por muito tempo os testes de stress, famosos por definir até quanto a capacidade de um sistema aguenta uma quantidade expressiva de usuários gerando requisições e peso para o mesmo, eram uma das únicas formas de medir performance em aplicações web.

O seu maior problema é que a medição focava tão-somente na carga de requisições HTTP geradas e no overhead de memória no servidor. Consequentemente, isso mascarou por muito tempo a ideia de que precisamos também focar na otimização da forma como desenvolvemos nosso front-end, pois é a partir dele que saem as requisições e é ele o responsável por lidar diretamente com o cliente navegador.

Desenvolver aplicações rápidas, elegantes, que funcionem bem e sejam fáceis de criar é uma premissa, e tais exigências atacam desde um cliente mais exigente (todos) à necessidade de um SEO satisfatório. Ninguém gosta de um site lento e, por mais que você saiba que o seu sistema tem muitos usuários em horários de pico, ou o servidor que a empresa disponibilizou não é tão robusto, ou ainda que os programadores não sabem usar boas práticas para criar código leve; ninguém ligará para isso. No mundo da TI, performance, medida pelo usuário, é tecnicamente definida como o medidor de resposta da sua aplicação e, a partir dela, podemos saber se é aceitável ou não.

Talvez o maior problema dessa questão esteja relacionado à inclusão de componentes e bibliotecas nas páginas web. Por exemplo, o site antigo da sua empresa era bem simples, tudo era estático, poucas imagens, nenhum vídeo, feio; porém performático.

E aí o seu chefe vem até você e solicita vários novos recursos, como menus dinâmicos no topo da página, controle de navegação com breadcrumbs, um slideshow no início com várias fotos em “alta resolução”, muitos ícones espalhados pela página, etc.

Para cada necessidade, você vai precisar de uma (ou várias) bibliotecas JavaScript diferentes, mas você não entende a diferença entre a versão minificada e normal, sai criando cada ícone como um arquivo de imagem separado (e gera novas requisições para cada imagem importada = mais overhead), carrega as imagens do slideshow com tamanho enorme e sai ajustando largura e altura diretamente nos atributos da tag HTML, etc.

Resultado disso? Uma sobrecarga exponencial para a sua aplicação que, agora tem vários recursos interessantes, mas falha em tempo de carregamento, em SEO, e, principalmente, em experiência com o usuário.

E aí você se pergunta: mas não podemos ter sites com vários recursos sob o risco de perder em performance? Negativo. A grande sacada é entender como tudo funciona e, sobretudo, como tudo funciona de forma integrada. Os frameworks se comunicam muitas vezes, existem arquivos que não precisam estar ali, código minificado é mais rápido, dentre várias outras coisas que podem ser considerados em uma otimização desse tipo.

O assunto é levado tão a sério pela comunidade web que a editora O’Reilly, responsável pela publicação de inúmeras bibliografias sobre o assunto, organiza anualmente o evento Velocity, que se dedica a reunir profissionais da área de otimização e escalabilidade web para debater os últimos lançamentos e técnicas do mercado.

Em sua sétima edição, 2015, que acontece em quatro cidades do globo, o evento traz trends variadas sobre o monitoramento de performance, cloud computing, otimização de UX, design responsivo, etc. focadas em redes, internet, mobile, gerência e métricas.

Veremos neste artigo uma série de conceitos e exemplos práticos de como aplicar as principais técnicas de otimização de aplicações web do merc ...