Site lento perde venda. Protótipo vibe-coded não aguenta produção.

O problema que vemos no mercado

Chegam até nós dois tipos de dor que parecem diferentes, mas têm a mesma raiz: software que funciona na superfície e desmorona quando alguém olha de perto. O primeiro tipo é o site ou aplicação lenta. O LCP passa de quatro segundos, o usuário fecha a aba antes do conteúdo principal aparecer, e o Google rebaixa o ranking porque Core Web Vitals virou sinal de busca. Quando abrimos o capô, o padrão se repete: bundle JavaScript de vários megabytes entregue de uma vez, sem code-splitting; imagens de 3000px servidas em PNG para um container de 400px, sem lazy-load nem formato moderno; fontes que bloqueiam a renderização; e nenhuma camada de cache ou CDN na frente — cada request bate no servidor de origem do zero. O resultado é conversão perdida em silêncio: ninguém vê o carrinho que não foi preenchido porque a página não carregou.

O segundo tipo é mais recente e cresce rápido: o protótipo "vibe-coded". Alguém gerou um produto inteiro conversando com uma IA, ou montou num no-code, e funcionou na demo. O problema é o que não está lá. Não há testes — qualquer mudança é uma aposta. Não há tratamento de erro — a primeira exceção inesperada derruba a aplicação inteira na frente do cliente. Não há validação de entrada — o formulário aceita qualquer coisa, inclusive payload malicioso. Não há revisão de segurança — chaves de API no front-end, queries montadas por concatenação de string, CORS aberto. Não há observability — quando quebra em produção, ninguém sabe onde nem por quê. E não há arquitetura — toda a lógica vive em três arquivos gigantes que ninguém mais consegue mexer sem medo.

Os dois casos têm o mesmo desfecho se ninguém intervém. O site lento continua perdendo venda enquanto o time discute redesign. O protótipo promissor trava na primeira leva de usuários reais, ganha fama de instável internamente, e acaba abandonado — não porque a ideia era ruim, mas porque ninguém o transformou em sistema antes de colocá-lo de pé sob carga real.

Como entregamos

Para o problema de performance, começamos sempre pela medição — porque otimizar no escuro é como apertar parafusos aleatórios. Rodamos auditoria de Core Web Vitals com Lighthouse em laboratório, WebPageTest para perfis de rede e dispositivo realistas, e RUM (Real User Monitoring) quando o cliente já tem tráfego, porque o número que importa é o do usuário real em 4G num celular mediano, não o do nosso desktop com fibra. Daí sai um diagnóstico com os três números que pesam — LCP, INP e CLS — e a lista priorizada do que está custando cada milissegundo.

Com o diagnóstico em mãos, a otimização é cirúrgica. Atacamos o bundle com code-splitting e tree-shaking para entregar só o JavaScript que aquela rota precisa, e movemos lógica para React Server Components quando a stack permite, tirando peso do cliente. Tratamos as imagens com formatos modernos (AVIF, WebP), dimensionamento correto e lazy-load abaixo da dobra. Colocamos caching e CDN na frente para que o conteúdo estático não toque o servidor de origem, e arrumamos o carregamento de fontes para que texto não fique invisível esperando download. Cada mudança é medida antes e depois — se não mexeu no número, foi removida.

Para o protótipo vibe-coded, o trabalho é hardening: transformar código que roda em código que você opera. Começamos cobrindo o caminho crítico com testes — Vitest para unidade e lógica, Playwright para fluxos de ponta a ponta — porque sem rede de segurança nenhuma refatoração é responsável. Refatoramos a estrutura para uma arquitetura sustentável, separando responsabilidades para que o código volte a ser modificável. Adicionamos validação e guardrails em toda entrada externa (schema validation, sanitização), tratamento de erro real com fronteiras claras, e logging mais observability para que falha em produção seja diagnosticável, não adivinhada. Fechamos com uma revisão de segurança — segredos fora do código, queries parametrizadas, headers e CORS corretos — e um pipeline de CI que roda lint, types e testes a cada push, para que o nível de qualidade não regrida depois que saímos.

Stack que usamos em produção hoje

Frontend e framework: Next.js e React são o default, com React Server Components e streaming quando a versão e o caso justificam — é onde conseguimos cortar mais peso do cliente sem reescrever a aplicação. Quando o projeto já está em Vite, Astro ou outro stack, trabalhamos dentro dele; o objetivo é acelerar o que existe, não impor uma migração que ninguém pediu.

Medição e build: Lighthouse e a Lighthouse CI para regressão automática, WebPageTest para cenários de rede realistas, e RUM (web-vitals, ou a stack de observability que o cliente já usa) para os números de usuário real. No build, atacamos o bundle com o analisador do próprio bundler (Webpack, Turbopack ou Vite) para enxergar o que está pesando antes de cortar. CDN e caching ficam onde o cliente já está — Cloudflare, Vercel Edge ou a camada de CDN da cloud em uso.

Hardening e qualidade: Vitest para testes de unidade e Playwright para end-to-end, validação de schema (Zod ou equivalente) nas fronteiras de entrada, e ESLint mais TypeScript em modo estrito como rede de qualidade contínua. A revisão de segurança cobre o básico que costuma faltar em código gerado: gestão de segredos, queries parametrizadas, validação de entrada e configuração de headers e CORS. Tudo amarrado num CI que falha o merge se a qualidade cair.

O que vai (e o que não vai) entregar valor

Acelerar entrega valor quando o gargalo é de verdade frontend ou build: bundle inchado, imagens não otimizadas, ausência de CDN, render bloqueado por JavaScript ou fontes. Nesses casos, o ganho costuma ser grande e mensurável, porque há fruta baixa colhendo poeira. E o hardening entrega valor quando há um protótipo promissor que precisa virar produto — a ideia foi validada, há tração ou demanda real, e o que falta é a engenharia que o sustenta. Aí transformar protótipo em sistema é o melhor dinheiro que se gasta.

Onde NÃO vamos fingir que cabe: se o protótipo é tão emaranhado que reescrever do zero custa menos que destrinchar e endurecer o que existe, dizemos isso — hardening de um código irrecuperável é jogar dinheiro fora, e em geral percebemos isso na primeira leitura. E se o seu site está lento mas a medição aponta o backend como culpado — banco de dados sem índice, query N+1, ou infraestrutura de cloud mal dimensionada — acelerar o frontend não resolve nada. Nesse caso a gente fala a verdade e encaminha para o trabalho certo, porque otimizar o lado errado é só adiar o problema com fatura.

A regra que usamos para decidir: medimos antes de prometer. Se a auditoria mostra que o ganho está ao alcance do frontend, do build ou do código de aplicação, é nosso. Se mostra que a dor está embaixo — no dado ou na infra — dizemos onde está e quem deve atacar, mesmo que isso signifique um projeto menor para nós.

Propriedade · o resultado é seu

Você sai com prova, não com promessa. Entregamos um relatório de métricas antes e depois — LCP, INP, CLS, tamanho de bundle e os números de Lighthouse — para que o ganho seja verificável, não uma sensação. Os PRs com cada otimização e cada refatoração ficam no seu repositório, revisáveis e revertíveis. A suíte de testes que escrevemos é sua e roda no seu CI, então a qualidade que instalamos continua de pé depois que saímos. Sem caixa-preta, sem dependência da gente para mexer no próprio código.

Próximo passo

O diagnóstico que abrimos é uma auditoria rápida e objetiva. Rodamos a medição no seu site ou lemos o seu protótipo e respondemos uma pergunta só: onde está o gargalo de verdade, qual é o ganho realista, e quanto trabalho ele exige? Você sai com os números na mão — LCP, INP, tamanho de bundle, ou o mapa do que falta para o protótipo aguentar produção — e uma resposta direta: vale acelerar aqui, vale endurecer aqui, ou o problema está em outro lugar e é honesto te mandar para lá. Sem proposta inflada. Sem reescrita vendida antes de medir.

Veja também

• websites e plataformas
• otimização de banco de dados