Queremos criar uma aplicação que seja muito performática, rápida e confiável. Imagem: Pexels

Uma visão sobre desempenho de aplicações web

O processo de desenvolvimento de software é composto por uma série de áreas, cada uma com seus profissionais e métodos de trabalho. Há o analista de negócio, de requisitos, o gerente de projetos, os desenvolvedores (que podem se dividir em front e back-end — para mais detalhes leia meu outro artigo: Back, front e full? As tribos do desenvolvimento na formação das equipes —, devOps, DBAs, etc), os testers, os designers e por aí vai.

Todos essas áreas buscam desenvolver um produto de qualidade, que agregue valor para o usuário final e atenda às necessidades levantadas. Porém um fator que às vezes é subestimado por algumas dessas áreas (ou todas elas) é a experiência do usuário (termo mais conhecido como UX — user experience). A UX de um software é muito relevante para a percepção de qualidade que o usuário final vai ter.

Na verdade a UX deveria ser uma preocupação em todas as etapas do desenvolvimento, desde o primeiro café com o cliente para saber o que ele precisa…

Tá bom, mas como eu garanto uma boa UX no meu sistema?

Aí está um assunto para outros artigos, afinal UX engloba várias disciplinas diferentes, como Arquitetura da Informação, Design, Usabilidade, Acessibilidade (para saber mais, segue o ótimo artigo da Aline Bossi, mestra no assunto: Acessibilidade web: sua importância e impacto social)… mas o que vim falar hoje tem mais relação com o desenvolvimento do software em si, que é o desempenho da aplicação, ou PERFORMANCE.

Já parou para pensar que a performance de uma aplicação influencia, e muito, a percepção do usuário sobre a qualidade?

O usuário não sabe dar um feedback do tipo: “A página de relatórios do sistema está levando muito tempo para carregar os assets de imagens e baixar o arquivo pdf do servidor”. Geralmente ele vai dizer: “O sistema está ruim” ou “demora muito pra ver as coisas”. Ele não sabe ser específico ou analisar de onde vem o problema, então ele generaliza. Se ele tiver a opção, muitas vezes ele vai fechar essa aplicação e ir para outra. Se não tiver a opção, ele pode até ficar sofrendo em silêncio.


O que é performance? Imagem: Dicio

Performance é o “modo de comportamento, desempenho”. Ou seja, performance não tem apenas a ver com velocidade, e sim o modo todo como algo se comporta, o conjunto das ações e os resultados que elas trazem.

Por exemplo, eu posso ser o jogador mais rápido em campo, mas quase nunca consigo marcar e nunca passo a bola pra ninguém. Outro jogador que é um pouco mais lento, mas trabalha em conjunto com o time e marca mais, ou ajuda a marcar, vai ter um desempenho melhor.


Tendo isso em mente, dá pra analisar um pouco como visualizar a performance das aplicações web de uma forma geral. Vamos então pra parte mais técnica.

Análise Objetiva vs. Análise Subjetiva

Como performance não é apenas velocidade, vamos ver que há vários parâmetros para definir se a aplicação é ou não performática.

A análise objetiva, por assim dizer, consiste em todos os parâmetros que podem ser mensurados. Para esses itens, quando menor esse valor, melhor. Por exemplo, se minha página é carregada em 2 segundos, seria melhor se ela carregasse em 1 segundo, e por aí vai.

Para obter essa análise objetiva há diversas ferramentas muito boas e detalhadas que permitem analisar todos os aspectos da performance de uma aplicação. Uma ótima ferramenta é o Chrome DevTools, que é o inspecionador de código do browser Chrome e tem muitos recursos (vou falar com mais detalhes sobre essa incrível ferramenta em outro artigo).

Esses valores obtidos através de uma análise objetiva podem ser todos melhorados através de algumas técnicas, que vão desde uma simples configuração do servidor até a reestruturação de todo o html, css e javascript da aplicação (técnicas que pretendo também abordar mais especificamente em outros artigos).

Visualização do Chrome DevTools em modo de inspeção da página (aba Elements). Mas há muitos outros recursos avançados! Imagem: print da edição desse artigo com o DevTools aberto.

Por outro lado, há a análise subjetiva da performance, que consiste na percepção do usuário sobre o sistema. Como não são dados tão mensuráveis, um trabalho diferente de coleta e melhoria são necessários e a abordagem de outras disciplina de UX, como usabilidade e acessibilidade.

Essa análise é bem mais ampla e de complexa interpretação dos resultados. Ela pode ser obtida através de testes de usabilidade com usuários, por exemplo, e também através dos feedbacks. Como essa análise envolve o “lado humano” do processo do desenvolvimento, certamente se trabalha com muitas variáveis. Não dá pra entrar em detalhes nesse artigo, mas a forma como um usuário enxerga uma aplicação varia de acordo com fatores como nível de escolaridade, cultura, gênero, possíveis deficiências, etc (para saber mais dê uma pesquisada em “testes de usabilidade”).

No fim das contas, os problemas encontrados através dessa análise subjetiva precisam ser analisados (possivelmente junto com um designer ou analista de UX) e solucionados cada um de uma maneira. Muitas vezes basta colocar um “loading” quando o usuário clica em um botão, para indicar que ele deve aguardar algo. Outras vezes é necessário refazer todo o fluxo de interação da aplicação.

A melhor maneira de fazer a análise subjetiva é observar a forma que o usuário interage com a aplicação. A partir disso, dá pra achar falhas e pontos de melhoria para melhorar a percepção de performance do usuário final. Imagem: Freepik

Esses dois tipos de análise são complementares e precisam ser realizadas para otimizar a performance da aplicação web.

Como eu trabalho como desenvolvedor front-end, minha área de atuação principal fica justamente no front-end da aplicação (jura?). Isso significa que trabalho no html, css, javascript e assets do projeto e posso até entrar um pouco na parte de configuração do servidor, mas não é regra. Ou seja, consigo trabalhar com os resultados obtidos através da análise objetiva da performance. E é justamente isso que quero abordar, o que posso dar o nome de otimização objetiva (inventei isso agora tá?).

Como começar e manter essa “otimização objetiva” então?

Num mundo ideal, uma equipe se preocupa com otimização desde o primeiro momento, quando a arquitetura da aplicação está nascendo.

Há várias técnicas que podem ser usadas para otimizar. Algumas delas são: minificação do html, css e js; otimização de imagens; redução de requests ao servidor; utilização de chache; compressão dos recursos; e a lista vai embora.

Essas técnicas podem ser aplicadas manualmente. Você pode ir num site e colocar o seu arquivo js e ele minifica* tudo pra você. A mesma coisa para imagens.

*minificar um arquivo é remover tudo o que não é necessário, como espaços em branco, comentários no código, reduzir nomes de variáveis e funções, etc. Isso reduz sensivelmente o tamanho do arquivo. Fica um código ilegível para um humano, mas bem legível pelo browser.

Você deve estar pensando: espera aí! Vou ter que ficar aplicando essas técnicas manualmente todas as vezes que mudar um arquivo?

Calma jovem! Não precisa fazer as coisas no braço. Felizmente outros já se preocuparam com isso e criaram automatizadores de tarefas, como o Gulp, o Grunt e o webpack. Eles tem centenas de pacotes que adicionam funcionalidades ao seu script de automatização e podem aplicar várias dessas técnicas de otimização automaticamente. Legal né? … Mas você vai precisar aprender um pouco sobre essas ferramentas também, não tem como fugir.


Portanto, um ciclo bem interessante pra se seguir quando estamos desenvolvendo com performance otimizada seria: criar uma funcionalidade > automatizar a otimização dos novos recursos > medir os novos resultados > testar a funcionalidade e analisar se o nível de otimização está se mantendo, melhorando ou piorando.

Crie > Automatize > Meça > Teste… e comece de novo!

De acordo com os resultados da fase de medição, o cara que faz a função de arquiteto vai definindo quais caminhos tomar. Por exemplo, a equipe desenvolveu uma funcionalidade de calendário e precisou usar um componente externo bem pesado (grande e demora pra carregar) e a performance caiu consideravelmente; vai ser decidido se a equipe deve procurar outro componente, criar um componente próprio ou manter o que já está implementado tentando otimizar outras partes da aplicação. Tudo depende de análises… e do prazo de entrega!

Lembrando que performance não está apenas no front-end da aplicação. A otimização de algoritmos do back-end, de buscas em banco de dados, entre outros, afeta muito a performance geral da aplicação.


Como profissionais dedicados, queremos criar uma aplicação que seja muito performática, rápida e confiável. Não é tão fácil assim chegar ao ideal, mas podemos começar com técnicas simples e rápidas e utilizar ferramentas ao nosso alcance, que nos poupam muitos segundos e recursos de carregamento. Com isso melhorando a percepção de qualidade do nosso usuário.

Performance de uma aplicação web é isso, é melhorar, refatorar, rever, medir como ela responde ao usuário, qual é a fluidez do uso e se perguntar constantemente: “eu estaria satisfeito usando essa aplicação?”. Tendo os conceitos básicos em mente como desenvolvedores, podemos criar algo fantástico e usar as técnicas para otimizar a performance com mais facilidade.


É disso que quero falar a partir de agora… Dado um pouco dessa introdução, vou começar a criar artigos mais detalhados sobre os diversos aspectos da otimização dos recursos de uma aplicação web, que vou chamar de Performance web 101 (referência àquelas classes iniciais de faculdades dos EUA), falando sobre Ferramentas e Técnicas… é uma grande jornada, pois as técnicas, as ferramentas, os métodos de medição são inúmeros. E também ainda estou no aprendizado.

Ainda não planejei todos os aspectos que vou abordar, mas já sei os próximos dois que quero falar:

  1. Performance 101 - Ferramentas: Chrome DevTools
  2. Performance 101 - Ferramentas: Gulp
  3. e muitos outros…

Espero que esse conhecimento seja útil para quem ler. Pelo menos para mim é, escrever e resumir um aprendizado é uma ótima forma de realmente aprender e praticar. Além disso, compartilhar é demais!

Até o próximo artigo!

Like what you read? Give Adriano Maringolo a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.