Performance começa antes do Lighthouse

Existe um momento comum em muitos projetos.

A feature está pronta.

A interface funciona.

Os dados aparecem.

Os testes passaram.

Então alguém abre o Lighthouse.

E começa a lista.

Imagem pesada.

JavaScript demais.

Tempo de carregamento alto.

Layout mudando enquanto a página abre.

Recursos bloqueando renderização.

A partir daí, performance vira uma tarefa.

Algo que precisamos corrigir antes de publicar.

O problema é que boa parte daqueles números não nasceu naquele momento.

Eles são consequência de decisões tomadas muito antes.

Performance pode ser medida no final.

Mas começa a ser construída no início.

O Lighthouse mostra o resultado, não a origem

Ferramentas como Lighthouse são extremamente úteis.

Elas ajudam a identificar problemas, comparar versões e enxergar comportamentos que talvez não fossem óbvios durante o desenvolvimento.

Mas existe uma diferença importante entre medir performance e construir performance.

Quando uma página demora para carregar porque enviamos uma quantidade enorme de JavaScript ao navegador, o relatório pode apontar isso.

Ele não decidiu quais dependências entraram no bundle.

Quando a imagem principal atrasa a renderização, a ferramenta consegue mostrar o impacto.

Ela não decidiu como aquela imagem seria carregada.

Quando uma tela dispara várias requisições sequenciais antes de mostrar qualquer conteúdo, conseguimos medir o tempo perdido.

Mas a origem do problema está na forma como organizamos a busca de dados.

O diagnóstico acontece depois.

A causa geralmente aconteceu antes.

Sistemas lentos raramente ficam lentos de uma vez

Performance costuma degradar de forma silenciosa.

Uma dependência parece pequena.

Depois entra outra.

Um componente faz uma requisição adicional.

Outro precisa dos dados da primeira para começar.

Uma imagem maior é adicionada porque visualmente fica melhor.

Um script externo entra para analytics.

Depois outro para suporte.

Depois outro para experimentação.

Nenhuma dessas decisões isoladamente parece suficiente para tornar o produto lento.

O problema aparece no conjunto.

É parecido com dívida técnica.

Você dificilmente acorda em uma manhã e descobre que o sistema ficou pesado sem motivo.

Ele foi ficando pesado.

Decisão por decisão.

O usuário não vê nossa arquitetura

Do ponto de vista técnico, podemos explicar perfeitamente por que uma página precisa esperar.

Primeiro buscamos a sessão.

Depois verificamos permissões.

Depois carregamos os dados principais.

Depois buscamos informações relacionadas.

Depois montamos a interface.

Tudo pode fazer sentido olhando para a implementação.

Para quem está utilizando o produto, existe apenas uma tela esperando aparecer.

O usuário não percebe que estamos aguardando três serviços.

Não sabe que determinado pacote aumentou o bundle.

Não se importa se a lentidão veio do frontend, do backend ou de uma integração externa.

Ele percebe tempo.

E tempo faz parte da experiência.

Essa é uma das razões pelas quais performance não deveria ser tratada apenas como problema técnico.

Uma interface lenta muda o comportamento do produto.

Velocidade também comunica qualidade

Imagine clicar em um botão e não receber nenhum feedback imediato.

Durante alguns segundos, nada acontece.

Talvez a operação esteja funcionando perfeitamente.

Mas existe uma pequena dúvida:

será que o clique foi registrado?

O usuário tenta novamente.

Agora temos duas requisições.

Talvez duas operações.

Talvez um problema que não existiria se a interface tivesse respondido melhor.

Performance percebida também influencia confiança.

Quando uma navegação acontece rapidamente, uma ação responde imediatamente e o conteúdo aparece de maneira previsível, o sistema parece sólido.

Quando cada interação exige espera sem contexto, existe fricção.

Mesmo que nenhum erro aconteça.

Isso conecta diretamente este artigo ao anterior da série.

Um sistema não precisa quebrar para oferecer uma experiência ruim.

Às vezes, ele apenas demora demais para responder.

JavaScript também tem custo

No frontend, existe uma característica interessante nas dependências.

Adicionar costuma ser fácil.

Remover é muito mais difícil.

Precisamos de uma biblioteca para resolver uma necessidade.

Instalamos.

Depois outra funcionalidade exige outro pacote.

Um componente de terceiros resolve rapidamente algo que levaria horas para construir.

Do ponto de vista de entrega, muitas dessas decisões são perfeitamente razoáveis.

O problema aparece quando pensamos apenas no custo de implementação.

Uma dependência também pode trazer custo de download.

Parsing.

Execução.

Atualização.

Compatibilidade.

Manutenção.

Isso não significa que devemos evitar bibliotecas.

Reimplementar tudo internamente dificilmente seria uma estratégia melhor.

A questão é reconhecer o trade-off.

A pergunta não é:

Podemos instalar esse pacote?

É:

O que estamos ganhando ao adicioná-lo e qual custo estamos aceitando?

Em muitos projetos, essa pergunta nunca acontece.

Até o bundle começar a cobrar.

Nem todo código precisa chegar imediatamente

Outro ponto importante está na forma como entregamos código ao navegador.

Imagine uma aplicação com dezenas de áreas.

Configurações.

Relatórios.

Dashboard.

Administração.

Integrações.

Onboarding.

Talvez o usuário utilize apenas uma pequena parte disso em determinada sessão.

Ainda assim, dependendo da arquitetura, podemos fazer o navegador baixar e processar muito mais do que ele realmente precisa naquele momento.

É aqui que decisões como code splitting, lazy loading e carregamento sob demanda deixam de ser apenas otimizações sofisticadas.

Elas respondem a uma pergunta simples:

quanto do sistema precisa existir antes que o usuário consiga começar?

Nem sempre a resposta é “tudo”.

Quanto menor for a quantidade de trabalho obrigatória antes da primeira interação útil, mais cedo o produto consegue entregar valor.

Dados também podem criar lentidão estrutural

Nem todo problema de performance nasce do frontend.

Mas o frontend frequentemente expõe problemas na estratégia de dados.

Uma tela precisa de quatro informações.

Fazemos quatro requisições.

Uma depende da outra.

Depois percebemos que um componente filho precisa de mais dados.

Outra chamada.

Cada decisão parece pequena.

Mas agora a página depende de uma sequência inteira de operações antes de ficar realmente pronta.

Esse padrão é especialmente perigoso porque pode funcionar muito bem durante o desenvolvimento.

Ambiente local rápido.

Poucos dados.

Baixa latência.

Conexão estável.

Em produção, a realidade muda.

A distância até o servidor muda.

A quantidade de dados cresce.

Serviços externos oscilam.

A conexão do usuário não é a nossa.

É aí que uma arquitetura que parecia perfeitamente aceitável começa a mostrar seu custo.

O ambiente de desenvolvimento mente um pouco

Nós construímos produtos em condições muito melhores do que muitas das pessoas que vão utilizá-los.

Máquinas rápidas.

Conexões estáveis.

Caches aquecidos.

Navegadores modernos.

Servidores próximos.

E, muitas vezes, dados cuidadosamente controlados.

Isso cria uma percepção distorcida.

A navegação parece instantânea.

A imagem carrega rápido.

A tabela aparece imediatamente.

Então colocamos o produto em produção e descobrimos que alguém em outro dispositivo, outra rede ou outra região está vendo uma experiência completamente diferente.

Performance precisa ser observada fora do ambiente confortável de quem constrói.

Não porque precisamos otimizar tudo para a pior condição possível.

Mas porque testar apenas no nosso cenário quase sempre favorece demais o sistema.

Imagens são decisões de produto também

Imagens são um exemplo simples de como performance atravessa disciplinas.

O design pode pedir uma imagem grande.

O frontend pode carregá-la exatamente como recebeu.

O navegador pode baixar vários megabytes para mostrar algo que ocupa uma pequena região da tela.

Todos fizeram aquilo que aparentemente deveriam fazer.

Mesmo assim, o resultado é ruim.

Resolver isso pode envolver formato.

Compressão.

Dimensões.

Responsividade.

Prioridade de carregamento.

CDN.

Placeholder.

Lazy loading.

Mas também pode envolver uma decisão anterior:

essa imagem precisa realmente ter esse peso e essa resolução?

Performance frequentemente melhora quando deixamos de procurar apenas ajustes técnicos e começamos a revisar as próprias escolhas do produto.

Carregar menos pode ser melhor do que carregar mais rápido

Existe uma diferença importante entre otimizar algo e eliminar a necessidade dele.

Podemos trabalhar bastante para tornar uma requisição mais rápida.

Ou descobrir que ela não precisa acontecer naquele momento.

Podemos otimizar um componente pesado.

Ou perceber que ele só precisa ser carregado quando o usuário abrir determinada área.

Podemos comprimir recursos.

Ou remover aqueles que deixaram de ter valor.

Esse tipo de decisão costuma produzir ganhos maiores porque ataca a origem da complexidade.

Uma das estratégias mais eficientes de performance continua sendo bastante simples:

fazer menos trabalho.

Menos bytes.

Menos chamadas.

Menos processamento.

Menos coisas competindo pela atenção do navegador.

Simplicidade também é uma estratégia de performance.

Métrica sem contexto também engana

Assim como vimos no artigo sobre analytics, números precisam de interpretação.

Uma pontuação baixa no Lighthouse merece atenção.

Mas ela não deveria se tornar objetivo isolado do produto.

É possível melhorar uma pontuação e quase não alterar a experiência percebida.

Também é possível existir um problema importante em um fluxo específico que uma auditoria genérica não representa bem.

Core Web Vitals, tempos de carregamento, tamanho de bundle e outras métricas ajudam.

Mas a pergunta continua sendo:

onde a performance está interferindo na experiência real?

Talvez a home esteja excelente.

Mas o dashboard utilizado todos os dias seja lento.

Talvez o carregamento inicial seja aceitável.

Mas cada filtro em uma tabela demore quatro segundos.

Talvez o produto tenha uma ótima pontuação técnica e uma ação crítica continue apresentando feedback tarde demais.

Performance não deveria existir apenas no laboratório.

Precisa ser observada no comportamento real do sistema.

Performance também precisa de orçamento

Uma ideia útil em produtos que crescem é parar de pensar apenas em “melhorar performance” e começar a estabelecer limites.

Quanto JavaScript estamos dispostos a enviar inicialmente?

Quanto determinada página pode crescer?

Qual tempo de resposta consideramos aceitável para uma ação crítica?

Qual regressão deveria chamar atenção durante uma entrega?

Esses limites funcionam como orçamento.

Não precisam ser perfeitos.

O valor está em tornar explícito que performance é um recurso finito.

Se uma nova funcionalidade aumenta significativamente o custo de carregamento, existe uma decisão a ser tomada.

Talvez valha a pena.

Talvez não.

Mas agora existe um trade-off visível.

Sem limite algum, cada adição parece gratuita.

Até que a soma deixa de ser.

Nem toda otimização merece existir

Também existe o extremo oposto.

Performance pode virar obsessão.

Passamos horas reduzindo milissegundos em uma tela quase nunca utilizada.

Criamos arquiteturas complexas para evitar uma quantidade mínima de trabalho.

Trocamos uma solução simples e sustentável por outra difícil de manter porque um benchmark ficou ligeiramente melhor.

Esse também é um erro.

Performance é uma característica do produto.

Não deveria se tornar uma competição técnica desconectada de impacto.

Uma otimização saudável considera custo.

Quanto esforço exige?

Quanto de complexidade adiciona?

Qual problema resolve?

Quantas pessoas são afetadas?

A diferença será perceptível?

O objetivo não é fazer todos os números chegarem ao máximo.

É entregar uma experiência suficientemente rápida para o contexto em que o produto existe.

Performance é uma responsabilidade compartilhada

Outro erro comum é colocar toda responsabilidade de performance no frontend.

O frontend tem impacto enorme.

Mas dificilmente controla tudo.

Uma query lenta pode comprometer a página.

Uma API que entrega dados demais também.

Uma decisão de design pode exigir recursos pesados.

Uma ferramenta de marketing pode adicionar scripts importantes.

Uma regra de negócio pode exigir processamento caro.

Uma imagem criada sem considerar o ambiente digital pode afetar carregamento.

Performance é resultado do sistema.

Isso significa que melhorar performance frequentemente exige conversa entre áreas.

Design.

Frontend.

Backend.

Infraestrutura.

Produto.

Às vezes, até marketing.

O problema pode aparecer no navegador.

A causa pode ter começado muito antes dele.

Indo além da criação

No começo, performance parece algo que podemos resolver depois.

Primeiro fazemos funcionar.

Depois melhoramos.

E essa estratégia pode fazer sentido em muitos momentos.

Não precisamos otimizar antecipadamente todo código que escrevemos.

Também não precisamos construir infraestrutura complexa antes de saber se existe um problema.

Mas existe uma diferença entre evitar otimização prematura e ignorar completamente o custo das decisões.

Performance não precisa dominar o desenvolvimento.

Precisa participar dele.

Ao escolher uma dependência.

Ao definir como dados serão carregados.

Ao decidir o peso de uma imagem.

Ao organizar uma página.

Ao adicionar scripts externos.

Ao escolher o que precisa estar disponível imediatamente e o que pode esperar.

O Lighthouse pode mostrar onde terminamos.

Mas não foi ele que nos trouxe até lá.

Performance não é algo que adicionamos ao produto depois.

É uma consequência da forma como escolhemos construí-lo.