Manutenção de código web: browser é caixa preta.

TL;DR

• Estado invisível — frontend é manutenção de código web que lida com estado que mora no browser, na memória, no cache, no localStorage e em cookies; quando o bug aparece, o estado está em algum lugar que o usuário não consegue inspecionar.
• Session replay é observabilidade mínima — Sentry, LogRocket ou FullStory em produção capturam clicks, navegação e estado; o custo é da ordem de minutos por sessão e o valor é da ordem de horas poupadas no diagnóstico — insumo básico da manutenção de código web madura.
• Performance degrada continuamente — bundle cresce, dependências entram, código fica lento; Web Vitals (LCP, FID, CLS) precisam de alerta, não de relatório mensal — caso clássico de manutenção de código web preventiva.
• Compatibilidade é matriz, não checkbox — Chrome funciona, Safari não funciona, desktop funciona e mobile não funciona; teste cross-browser e critério explícito de “últimas N versões suportadas” são a única defesa na manutenção de código web.
• Cache é inimigo silencioso — usuário relata bug que ninguém reproduz porque production tem cache novo e o usuário tem cache antigo; cache busting por content hash é a forma mais barata de fechar isso na manutenção de código web.

Manutenção de código web começa por estado invisível

No backend, o estado mora em três lugares previsíveis: banco, sistema de arquivos e fila. Cada um tem ferramenta padrão para inspecionar. Query errada? `EXPLAIN ANALYZE` resolve. Request lento? APM mostra a chamada. Bug em produção? Stack trace chega no log com linha, classe e método.

No frontend, o estado mora em pelo menos cinco lugares, nenhum deles persistente entre sessões por padrão:

• memória do processo (estado React/Angular/Vue);
• cookies de sessão;
• localStorage e sessionStorage;
• cache HTTP (browser cache, Service Worker cache);
• storage de extensões do browser.

O bug que o usuário relata pode ter sido gerado por uma interação que acontece em sequência específica, em cache desatualizado, em cookie expirado ou em estado intermediário que só existiu por 200ms. Reproduzir localmente é, no melhor caso, demorado. No pior caso, impossível sem saber o caminho exato que o usuário percorreu.

Por isso, três práticas são inegociáveis para qualquer manutenção de código web que dependa de visibilidade:

// console.log em pontos críticos do fluxo
// NÃO remover em produção: vira a única forma de auditar
// comportamento em cenário que não foi reproduzido localmente
function processarPagamento(payload) {
  console.log('[pagamento] estado inicial:', { userId, cartaoId });
  // ...
}

<!-- Source maps em produção -->
<!-- Permite ler código original mesmo depois do bundle minificado -->
<script src="https://cdn.example.com/bundle.v123.min.js"></script>
<script src="https://cdn.example.com/bundle.v123.min.js.map"></script>

// Error boundary em React / try-catch global em Angular
class ErrorBoundary extends React.Component {
  componentDidCatch(error, info) {
    logToSentry(error, info.componentStack);
    return <FallbackUI />;
  }
}

A diferença entre backend e frontend na manutenção de código web é exatamente esta: em backend a ferramenta de debug é a stack; em frontend a ferramenta de debug é o conjunto de rastros deixados em produção e a capacidade de reproduzir o que usuário viu — duas coisas que DevTools local não entrega sozinho.

Manutenção de código web exige debug em produção

O desenvolvedor não consegue sentar no browser de cada usuário e clicar junto. Quando o usuário relata “tá bugado”, há um abismo entre o que ele viu e o que o dev consegue reconstituir localmente.

A solução padrão de mercado é session replay. Ferramentas como Sentry (com Session Replay), LogRocket e FullStory gravam a sessão do usuário — DOM, clicks, navegação, console, exceções de rede — e permitem reproduzir a tela exata que ele viu no momento do bug. Quando o ticket chega, abre a sessão, vê o que aconteceu, vai direto no `git blame` da linha que quebrou.

// Setup típico de Sentry com replay
import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "https://[email protected]/...",
  replaysSessionSampleRate: 0.1,   // 10% das sessões gravadas
  replaysOnErrorSampleRate: 1.0,   // 100% das sessões com erro gravadas
});

O custo de session replay é da ordem de R$ 1k/mês para 100k sessões/mês (dependendo do provedor). O valor é multiplicador: um bug que levaria dois dias para reproduzir manualmente vira diagnóstico de dez minutos.

Há um ponto que precisa ficar explícito: privacy. Sessões gravadas podem capturar dados sensíveis do usuário (PII, dados de pagamento, conteúdo digitado). Sessão replay precisa de política de mascaramento — campos com classe `sentry-mask` ou `data-private` são omitidos da gravação. Não dá para simplesmente ligar e assumir conformidade com LGPD.

A regra operacional é simples: se não há ferramenta que mostre exatamente o que o usuário viu quando ele abriu o ticket, a observabilidade de frontend está inadequada.

Performance em manutenção de código web é trabalho contínuo

Aplicação web degrada de performance por inércia. Cada dependência que entra vira 30kB no bundle. Cada render que ficou condicional vira loop que roda mais vezes. Cada feature nova adiciona código que ninguém mede individualmente. Web Vitals — LCP (Largest Contentful Paint), FID (First Input Delay), CLS (Cumulative Layout Shift) — são definidos pelo Google como sinais oficiais de experiência de página, e todos pioram com o tempo se ninguém medir.

Três práticas evitam a degradação silenciosa — e cada uma cabe num ciclo de manutenção de código web maduro.

// bundle size em CI: bloqueia PR que inflar bundle
npx bundlesize --max-size 250kb dist/bundle.js

// alerta de regressão em Web Vitals
alerts:
  lcp_p75: { threshold: 2500, severity: warning }
  fid_p75: { threshold: 100, severity: critical }
  cls_p75: { threshold: 0.1, severity: warning }

Prática	Ferramenta típica	Custo	Valor
Medir Web Vitals em produção	Lighthouse CI, SpeedCurve, Datadog RUM	baixo (R$ 200-500/mês)	alto (detecta regressão antes do usuário abandonar)
Alertar regressão	Slack/webhook contra o pipeline de release	quase zero	crítico (PR ruim não chega em produção)
Auditar bundle a cada PR	webpack-bundle-analyzer, bundlesize, size-limit	nenhum (open source)	alto (dependência nova aparece explícita no diff)

Bundle size é métrica que cabe em CI sem custo de licença. Web Vitals precisa de RUM em produção para ser útil — dado de laboratório não detecta regressão que só aparece com 30% dos usuários em 3G. RUM é gasto, mas é o único jeito de saber o que usuário final está vendo, e sem ele a manutenção de código web vira cega às condições reais de uso.

Compatibilidade é debugging multiplataforma

Aplicação web roda em uma matriz de combinação: Chrome (últimas 4 versões), Firefox (últimas 4), Safari (últimas 2), Edge, Samsung Internet, browsers mobile Android, Safari iOS em versão fixa (não atualiza com OS). Cada combinação tem motor de render diferente, suporte de API diferente, comportamento de touch diferente. Esse é o calcanhar de Aquiles clássico da manutenção de código web: o que funciona no Chrome do desenvolvedor pode quebrar no Safari do iPad do usuário.

A regra mínima é:

1. Critério explícito de suporte. Documentar a matriz alvo no formato “Chrome últimas 2 versões, Safari últimas 2, Firefox últimas 2, Edge última versão. Mobile iOS 16+ Safari, Android Chrome últimas 2” — sem isso, qualquer relato de “funciona no browser do relator” vira debate interminável de backlog. 2. BrowserStack ou Sauce Labs em CI. Cada PR roda em pelo menos Chrome, Firefox e Safari desktop + iOS Safari + Android Chrome. Custo: R$ 1-3k/mês por seat. Sem isso, regressão cross-browser só é descoberta quando o usuário reclama. 3. Mobile-first em teste manual. Device lab com pelo menos 1 iPhone e 1 Android físico. Emulação em desktop não reproduz comportamento de touch, viewport real e rendering de fonte em densidade baixa.

Aplicação web não tem a frase “mas funciona no Chrome”. O critério é o que foi documentado; qualquer cenário fora da matriz declarada está fora de SLA, e a resposta padrão ao ticket é “atualize o browser, ajuste o código para a matriz, ou amplie a matriz formalmente”. Manutenção de código web sem matriz explícita vira manutenção reativa a cada relato de bug.

Cache é inimigo silencioso

O cenário clássico de bug web incompreensível: usuário diz que a tela está mostrando informação errada; o dev abre a mesma URL em três browsers e vê informação certa. A diferença é cache — e cache é parte inseparável de qualquer manutenção de código web séria.

Há quatro camadas de cache em web, cada uma com vida própria:

• Browser cache HTML — controlado pelo header `Cache-Control`. Se setado para `no-cache` ou com `max-age=0`, browser sempre revalida. Se setado para `max-age=31536000`, browser guarda por um ano.
• Browser cache de assets (JS, CSS, imagens, fonts) — versionado por content hash no filename. `bundle.v123.js` é único por build. Quando sai `bundle.v124.js`, browser entende que é arquivo novo e busca.
• Service Worker cache — controle programático via `workbox` ou implementação manual. Service Worker precisa ter estratégia explícita de update — sem isso, ele serve cache antigo depois de deploy.
• CDN cache — varia por provedor. Cloudflare, Cloudfront e Fastly têm regras próprias de purge.

A forma simples de fechar a maioria dos bugs de cache é a regra dos três níveis — disciplina obrigatória em qualquer rotina de manutenção de código web que respeite deploy e versionamento:

// HTML — nunca cachear
location ~* \.html$ {
  add_header Cache-Control "no-cache, no-store, must-revalidate";
}

// Assets com hash no filename — cache imortal
location ~* \.[a-f0-9]{8}\.(js|css)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

// Assets sem hash — cache curto + revalidação
location ~* \.(js|css)$ {
  add_header Cache-Control "public, max-age=0, must-revalidate";
}

Sem essa disciplina, deploy vira loteria: para 80% dos usuários a versão nova chega imediatamente, para 20% chega em algumas horas, e o time gasta o dia seguinte entendendo por que “o bug não foi corrigido” em produção — quando na verdade a versão nova nem está rodando para esse usuário.

Fechamento

Manutenção de código web é diferente porque a execução mora no browser do usuário, e o estado que reproduz o bug está em algum lugar que o desenvolvedor não vê. A defesa é tríplice: observabilidade em produção (session replay, RUM, Web Vitals), critério explícito de compatibilidade cross-browser, e disciplina de cache com content hash. Sem esses três, o navegador do usuário segue sendo uma caixa preta. Implementar session replay hoje é o passo de menor custo e maior retorno.

Leitura relacionada

• Você não sabe o que está acontecendo em produção porque não tá olhando direito — porque a base do problema de frontend é o mesmo de qualquer sistema: o que não é medido em produção é o que demora a ser diagnosticado.
• O código novo que ninguém consegue manter é pior que o legado — porque a decisão de qual observabilidade adicionar depende do tipo de código que se escolheu escrever, e o código de manutenção barata é decidido na escrita.
• Você não tem problema de pipeline. Você tem problema de código que ninguém entende. — porque quando o código é ilegível e o cache é antigo, nenhuma ferramenta de produção consegue encurtar a distância entre quem relata o bug e quem tenta corrigir.