Orçamentos de desempenho que funcionam: limites práticos para apps web rápidos

Por que desempenho precisa de orçamentos, não só boas intenções

Um orçamento de desempenho é um conjunto de limites acordados antes de construir. Pode ser um limite de tempo (quão rápida a página parece), um limite de tamanho (quanto código você envia) ou um teto simples (requisições, imagens, scripts de terceiros). Se você ultrapassar o limite, trata-se como um requisito quebrado, não como uma tarefa “boa de consertar depois”.

A velocidade normalmente piora porque o envio é aditivo. Cada novo widget adiciona JavaScript, CSS, fontes, imagens, chamadas de API e mais trabalho para o navegador. Mesmo mudanças pequenas se acumulam até o app ficar pesado, especialmente em celulares de gama média e redes mais lentas — onde está a maioria dos usuários reais.

Opiniões não protegem você aqui. Uma pessoa diz “está ok no meu laptop”, outra diz “está lento”, e o time debate. Um orçamento encerra o debate ao transformar desempenho em uma restrição de produto que você pode medir e aplicar.

É aqui que o pensamento do Addy Osmani se encaixa: trate desempenho como restrições de design e regras de segurança. Você não “tenta” manter a segurança ou “espera” que o layout pareça bom. Você define padrões, verifica continuamente e bloqueia mudanças que os quebram.

Orçamentos resolvem vários problemas práticos ao mesmo tempo. Tornam trade-offs explícitos (adicionar uma feature significa pagar por isso em outro lugar), pegam regressões cedo (quando corrigir é mais barato) e dão a todos a mesma definição de “rápido o suficiente”. Também reduzem o pânico de última hora que tende a aparecer antes de um lançamento.

Aqui está o tipo de cenário para o qual orçamentos são feitos: você adiciona uma biblioteca rica de gráficos para uma visualização de dashboard. Ela é enviada para todos, aumenta o bundle principal e atrasa a primeira tela significativa. Sem um orçamento, isso passa porque a feature “funciona”. Com um orçamento, o time precisa escolher: lazy-load do gráfico, trocar a biblioteca ou simplificar a visualização.

Isso importa ainda mais quando times conseguem gerar e iterar apps rapidamente, inclusive com fluxos de build orientados por chat como o Koder.ai. Velocidade é ótima, mas também facilita enviar dependências extras e floreios de UI sem perceber. Orçamentos impedem que iterações rápidas se transformem em produtos lentos.

Comece com um alvo simples: página, dispositivo e rede

O trabalho de desempenho falha quando você mede tudo e não é responsável por nada. Escolha uma jornada de página que importe para usuários reais e trate-a como âncora para seus orçamentos.

Um bom ponto de partida é uma jornada principal onde velocidade afeta conversão ou trabalho diário, como “home até cadastro”, “primeiro carregamento do dashboard após login” ou “checkout e confirmação de pagamento”. Escolha algo representativo e frequente, não um caso de borda.

Escolha um alvo que combine com seus usuários

Seu app não roda no seu laptop. Um orçamento que parece bom numa máquina rápida pode ser lento num celular de gama média.

Decida uma classe de dispositivo alvo e um perfil de rede para começar. Mantenha simples e escreva como uma frase que todo mundo possa repetir.

Por exemplo: um celular Android de gama média dos últimos 2–3 anos, em 4G em movimento (não Wi‑Fi do escritório), medindo uma carga fria e depois uma navegação chave, na mesma região onde está a maioria dos usuários.

Isso não é escolher o pior caso. É escolher um caso comum que você realmente possa otimizar.

Trave um setup de teste base

Números só importam se forem comparáveis. Se uma execução é “Chrome com extensões num MacBook” e a próxima é “mobile com throttling”, sua linha de tendência vira ruído.

Escolha um ambiente base e mantenha-o para as checagens do orçamento: mesma versão do navegador, mesmas configurações de throttling, mesmo caminho de teste e mesmo estado de cache (frio ou quente). Se usar dispositivos reais, use o mesmo modelo.

Agora defina o que “rápido o suficiente” significa em termos de comportamento, não de demos perfeitas. Por exemplo: “os usuários conseguem começar a ler o conteúdo rapidamente” ou “o dashboard parece responsivo após o login”. Traduza isso em uma ou duas métricas para essa jornada e então defina orçamentos ao redor delas.

Tipos de orçamento: tempo, tamanho, requisições e runtime

Orçamentos funcionam melhor quando cobrem tanto o que os usuários sentem quanto o que os times podem controlar. Um bom conjunto mistura métricas de experiência (a parte “pareceu rápido?”) com limites de recurso e CPU (o “por que ficou lento?”).

Orçamentos de tempo (experiência do usuário)

Eles rastreiam como a página se comporta para pessoas reais. Os mais úteis mapeiam diretamente para os Core Web Vitals:

• LCP (Largest Contentful Paint): quão rápido o conteúdo principal aparece.
• INP (Interaction to Next Paint): quão responsiva a página é quando alguém toca, clica ou digita.
• CLS (Cumulative Layout Shift): quanto o layout se desloca.

Orçamentos de tempo são sua estrela guia porque correspondem à frustração do usuário. Mas eles nem sempre dizem o que consertar, então você também precisa dos tipos de orçamento abaixo.

Orçamentos de tamanho, requisições e runtime (o que causa lentidão)

Esses são mais fáceis de aplicar em builds e revisões porque são concretos.

Orçamentos de peso limitam coisas como total de JavaScript, total de CSS, peso de imagens e fontes. Orçamentos de requisição limitam contagem total de requisições e scripts de terceiros, reduzindo overhead de rede e trabalho “surpresa” de tags, widgets e trackers. Orçamentos de runtime limitam long tasks, tempo na main-thread e tempo de hidratação (especialmente em React), que muitas vezes explica por que uma página “parece” lenta em celulares de gama média.

Um exemplo prático em React: o tamanho do bundle pode parecer ok, mas um novo carrossel adiciona render pesado no cliente. A página carrega, ainda assim tocar em filtros fica travado porque a hidratação bloqueia a main thread. Um orçamento de runtime como “não ter long tasks acima de X ms durante o startup” ou “hidratação completa em até Y segundos em um dispositivo de médio desempenho” pode detectar isso mesmo quando os orçamentos de peso não o fazem.

A abordagem mais forte trata tudo como um sistema: orçamentos de experiência definem sucesso, e orçamentos de tamanho, requisição e runtime mantêm releases honestos e facilitam responder “o que mudou?”.

Orçamentos concretos iniciais que você pode realmente aplicar

Se você definir limites demais, as pessoas param de prestar atenção. Escolha 3 a 5 orçamentos que correspondam ao que os usuários mais sentem e que você possa medir em cada pull request ou release.

Um conjunto prático inicial (ajuste os números depois):

• LCP: aviso em 2.5s, falha em 3.0s (mobile, carga fria).
• INP: aviso em 200ms, falha em 300ms (interações comuns como abrir um menu ou enviar um formulário).
• CLS: aviso em 0.10, falha em 0.15.
• Tamanho do bundle JavaScript (rota inicial): aviso em 170KB gzip, falha em 220KB gzip (somente código do app).
• Imagens (visão inicial): aviso em 800KB, falha em 1.2MB (total de bytes transferidos para imagens carregadas na primeira tela).

Dois limiares mantêm as coisas sensatas. “Aviso” indica que você está se afastando. “Falha” bloqueia uma release ou exige aprovação explícita. Isso torna o limite real sem criar incêndios constantes.

Escreva o orçamento em um lugar compartilhado para que ninguém debata durante uma release corrida. Seja curto e específico: quais páginas ou fluxos estão cobertos, onde as medições rodam (auditoria local, CI, build staged), qual dispositivo e perfil de rede você usa e exatamente como as métricas são definidas (campo vs lab, gzip vs bruto, por rota vs app inteiro).

Passo a passo: defina orçamentos a partir do seu app atual

Comece com um baseline que você possa repetir. Escolha uma ou duas páginas chave e teste-as no mesmo perfil de dispositivo e rede a cada vez. Rode o teste pelo menos três vezes e registre a mediana para que uma execução estranha não guie sua direção.

Use uma planilha de baseline simples que inclua tanto uma métrica de usuário quanto uma métrica de build. Por exemplo: LCP e INP para a página, mais total de JavaScript e total de bytes de imagem para o build. Isso torna orçamentos reais porque você vê o que o app enviou, não só o que um teste de laboratório estimou.

Defina orçamentos um pouco melhores que hoje, não números de fantasia. Uma regra sólida é melhorar 5–10% a partir da mediana atual para cada métrica que importa. Se seu LCP é 3.2s no setup base, não pule direto para 2.0s. Comece com 3.0s e aperte conforme provar que consegue manter.

Adicione uma checagem rápida a cada release antes dos usuários verem. Mantenha-a rápida para que as pessoas não a ignorem. Uma versão simples: rode uma auditoria de página única na página acordada, falhe o build se JS ou imagens excederem o orçamento, armazene resultados por commit para ver quando algo mudou e sempre teste o mesmo padrão de URL (sem dados aleatórios).

Revise violações semanalmente, não só quando alguém reclamar. Trate uma violação como um bug: identifique a mudança que a causou, decida o que consertar agora e o que agendar. Aperte devagar, só depois de manter a linha por algumas releases.

Quando o escopo do produto mudar, atualize orçamentos deliberadamente. Se você adicionar uma nova ferramenta de analytics ou uma feature pesada, documente o que cresceu (tamanho, requisições, runtime), o que vocês farão para compensar depois e quando o orçamento deve voltar ao normal.

Auditorias rápidas: um jeito rápido de ver o que mudou

Um orçamento só ajuda se você puder checá-lo rapidamente. O objetivo de uma auditoria de 10 minutos não é provar um número perfeito. É identificar o que mudou desde o último bom build e decidir o que consertar primeiro.

Fluxo de auditoria de 10 minutos

Comece com uma página que represente uso real. Então rode as mesmas checagens rápidas sempre:

• Identifique o elemento LCP (imagem hero, bloco de título, galeria de produto). Se o elemento LCP mudou, os resultados vão variar.
• Verifique peso de JavaScript e os maiores chunks. Procure por uma dependência nova, biblioteca duplicada ou grande feature enviada para todo mundo.
• Escaneie imagens acima da dobra por erros comuns (ativos não comprimidos, dimensões erradas, falta de fontes responsivas).
• Revise tags de terceiros (analytics, chat, testes A/B). Uma nova tag pode adicionar long tasks e bloquear a main thread.
• Observe rede e CPU juntos: está lento porque aumentaram os bytes, ou porque a página está fazendo muito trabalho?

Como identificar os maiores problemas rápido

Duas visões costumam dar respostas em minutos: o waterfall de rede e a timeline da main-thread.

No waterfall, procure por uma requisição que domine o caminho crítico: um script gigante, uma fonte bloqueante ou uma imagem que começa tarde. Se o recurso do LCP não for solicitado cedo, a página não bate o orçamento de LCP não importa quão rápido o servidor seja.

Na timeline, procure long tasks (50 ms ou mais). Um aglomerado de long tasks no startup geralmente significa JavaScript demais na primeira carga. Um chunk massivo costuma ser problema de roteamento ou um bundle compartilhado que cresceu ao longo do tempo.

Notas que tornam o próximo teste comparável

Auditorias rápidas falham quando cada execução é diferente. Capture o básico para deixar as mudanças claras: URL da página e versão/build, dispositivo e perfil de rede do teste, descrição do elemento LCP, os números chave que você rastreia (por exemplo LCP, total de JS bytes, contagem de requisições) e uma nota curta sobre o maior culpado.

Testes em desktop servem para feedback rápido e checagens de PR. Use um dispositivo real quando estiver próximo do orçamento, quando a página parecer travada ou quando seus usuários forem majoritariamente mobile. CPUs móveis tornam long tasks óbvias, e é aí que muitas releases “parece ok no meu laptop” falham.

O que consertar primeiro: regras simples que economizam tempo

Quando um orçamento falha, o pior é “otimizar tudo”. Use uma ordem de triagem repetível para que cada correção tenha retorno claro.

Uma ordem prática de triagem

Comece pelo que os usuários mais notam e depois vá para ajustes mais finos:

• Faça o elemento principal acima da dobra renderizar rápido. Encontre o que pinta como o maior conteúdo e corrija esse ativo ou caminho de render. Redimensione e comprima imagens, use o formato certo e evite fontes carregadas tardiamente que bloqueiem a primeira vista.
• Corte JavaScript antes de polir o CSS. Se a página envia muito JS, todo o resto sofre: parsing mais lento, mais trabalho na main-thread e render retardado. Remova código não usado, divida rotas pesadas e prefira conteúdo renderizado no servidor ou estático para UI simples.
• Controle scripts de terceiros cedo. Widgets de chat, analytics, tag managers e ferramentas de A/B podem adicionar grandes downloads e long tasks. Se não é necessário na primeira vista, atrase o carregamento. Se for de baixo valor, remova.
• Evite shifts de layout por design. Reserve espaço para imagens, anúncios e embeds. Defina largura/altura, use placeholders estáveis e evite injetar UI acima do conteúdo existente após o carregamento.
• Se a interação está lenta, elimine long tasks. Quando o INP está ruim, procure trabalho pesado no cliente: renders grandes, atualizações de estado caras e processamento grande de JSON. Divida o trabalho em pedaços menores, reduza rerenders e mova trabalho não-UI para fora do caminho crítico.

Um exemplo rápido

Um time envia um novo dashboard e de repente perde o orçamento de LCP. Em vez de ajustar cabeçalhos de cache primeiro, eles descobrem que o elemento LCP é uma imagem de gráfico em full-width. Redimensionam, servem em formato mais leve e carregam só o que importa cedo. Em seguida, notam que uma grande biblioteca de gráficos carrega em todas as rotas. Carregam-na apenas na página de analytics e adiam um widget de suporte de terceiros até a primeira interação. Em um dia, o dashboard volta ao orçamento, e a próxima release tem respostas claras de “o que mudou”.

Erros comuns que os times cometem com orçamentos de desempenho

O maior modo de falha é tratar orçamentos como um documento único. Orçamentos só funcionam quando são fáceis de checar, difíceis de ignorar e ligados a como você entrega.

Erros que fazem orçamentos falharem

A maioria dos times cai em alguns atalhos:

• Definir orçamentos demais no dia um, ou torná-los tão rígidos que todo build falha.
• Medir com configurações diferentes a cada vez (dispositivo, throttling, estado de cache, página de teste).
• Perseguir pontuações de laboratório enquanto perde a dor do usuário real.
• Deixar uma dependência grande entrar sem perceber.
• Tratar desempenho como um projeto que se termina em vez de uma regra de release.

Um padrão comum é uma feature “pequena” que puxa uma nova biblioteca. O bundle cresce, o LCP atrasa um segundo em redes lentas e ninguém nota até tickets de suporte. Orçamentos existem para tornar essa mudança visível na revisão.

Como evitar esses erros

Comece simples e mantenha checagens consistentes. Escolha 2–4 orçamentos que mapeiem para experiência do usuário e aperte-os gradualmente. Trave seu setup de teste e registre-o. Rastreie pelo menos um sinal de usuário real se puder e use testes de laboratório para explicar o “porquê”, não para vencer discussões. Quando uma dependência adicionar peso relevante, exija uma nota curta: quanto custa, o que substitui e por que vale a pena. O mais importante: coloque a checagem de orçamento no caminho normal de release.

Se orçamentos parecerem fricção constante, geralmente são irreais para hoje ou não estão ligados a decisões reais. Corrija essas duas coisas primeiro.

Exemplo: transformar um app lento em um processo de release com orçamentos

Um time pequeno lançou um dashboard analytics em React em uma semana. No começo parecia rápido, mas a cada release de sexta ele ficava um pouco mais pesado. Depois de um mês, usuários começaram a dizer que a primeira tela “travava” e filtros pareciam lentos.

Eles pararam de discutir “rápido o suficiente” e escreveram orçamentos ligados ao que os usuários notam:

• LCP: 2.5s em um celular de gama média em 4G
• INP: abaixo de 200ms para ações comuns (abrir menu, aplicar filtro)
• JavaScript: 250KB gzip para a rota inicial, com um teto claro por nova feature
• Imagens: nada de hero images sem compressão e tamanho máximo de pixels por componente

A primeira falha apareceu em dois pontos. O bundle inicial subiu conforme gráficos, bibliotecas de data e um kit de UI foram adicionados. Ao mesmo tempo, a imagem de cabeçalho do dashboard foi trocada por um arquivo maior “só por agora”, empurrando o LCP além do limite. O INP piorou porque cada mudança de filtro disparava rerenders pesados e cálculos caros na main thread.

Eles consertaram numa ordem que gerou ganhos rápidos e preveniu regressões:

1. Reverter o LCP para dentro do limite redimensionando e comprimindo imagens, definindo dimensões explícitas e evitando fontes bloqueantes.

2. Reduzir o JS inicial removendo bibliotecas não usadas, dividindo rotas não críticas e lazy-loading de gráficos.

3. Melhorar o INP memoizando componentes caros, debouncing em filtros de digitação e movendo trabalho pesado para fora do caminho crítico.

4. Adicionar uma checagem de orçamento a cada release para que, se uma métrica quebrar, a release espere.

Depois de duas releases, o LCP caiu de 3.4s para 2.3s, e o INP melhorou de cerca de 350ms para menos de 180ms no mesmo dispositivo de teste.

Checklist e próximos passos (incluindo um fluxo leve com Koder.ai)

Um orçamento só ajuda se as pessoas puderem segui-lo do mesmo jeito toda vez. Mantenha pequeno, documente e torne parte do envio.

Escolha algumas métricas que se encaixem no seu app, defina limiares de “aviso vs falha” e documente exatamente como você testa (dispositivo, navegador, rede, página/fluxo). Salve um relatório baseline do melhor release atual e rotule claramente. Decida o que conta como exceção válida e o que não conta.

Antes de cada release, rode a mesma auditoria e compare com o baseline. Se algo regredir, registre onde você rastreia bugs e trate como uma etapa de checkout quebrada, não como uma tarefa “depois”. Se você enviar com uma exceção, registre um responsável e uma data de expiração (frequentemente 1–2 sprints). Se a exceção for renovada continuamente, o orçamento precisa de discussão real.

Leve orçamentos para mais cedo no planejamento e nas estimativas: “Esta tela adiciona uma biblioteca de gráficos, então precisamos remover algo ou lazy-load”. Se você está construindo com Koder.ai (koder.ai), também pode escrever essas restrições desde o início no Modo de Planejamento, iterar em fatias menores e usar snapshots e rollback quando uma mudança ultrapassar o limite. O ponto não é a ferramenta, é o hábito: cada nova feature tem que pagar pelo seu peso, ou não é enviada.