Disponibilidade de material de suporte

Esta cópia do catálogo contém as orientações inline abaixo, mas não inclui os seguintes caminhos de suporte. Eles são pré-requisitos externos, não arquivos empacotados:

• <support-root>/references/performance-checklist.md

Obtenha o material necessário da fonte upstream declarada ou de uma instalação fornecida pelo usuário dessa fonte. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças aplicáveis e pré-requisitos de execução. Não execute um comando nem afirme que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não fabrique os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Otimização de Desempenho

Visão Geral

Meça antes de otimizar. Trabalho de desempenho sem medição é adivinhação — e adivinhação leva à otimização prematura que adiciona complexidade sem melhorar o que importa. Perfilar primeiro, identificar o gargalo real, corrigi-lo, medir novamente. Otimize apenas o que as medições provam que importa.

Quando Usar

• Requisitos de desempenho existem na especificação (orçamentos de tempo de carregamento, SLAs de tempo de resposta)
• Usuários ou monitoramento relatam comportamento lento
• Pontuações do Core Web Vitals estão abaixo dos limites
• Você suspeita que uma mudança introduziu uma regressão
• Construindo recursos que lidam com grandes conjuntos de dados ou alto tráfego

Quando NÃO usar: Não otimize antes de ter evidências de um problema. Otimização prematura adiciona complexidade que custa mais do que o desempenho que ela ganha.

Metas do Core Web Vitals

O Fluxo de Trabalho de Otimização

1. MEASURE  → Establish baseline with real data
2. IDENTIFY → Find the actual bottleneck (not assumed)
3. FIX      → Address the specific bottleneck
4. VERIFY   → Measure again, confirm improvement
5. GUARD    → Add monitoring or tests to prevent regression

Etapa 1: Medir

Duas abordagens complementares — use ambas:

• Sintética (Lighthouse, aba Performance do DevTools): Condições controladas, reproduzíveis. Melhor para detecção de regressão em CI e isolamento de problemas específicos.
• RUM (biblioteca web-vitals, CrUX): Dados de usuários reais em condições reais. Necessário para validar que uma correção realmente melhorou a experiência do usuário.

Frontend:

# Synthetic: Lighthouse in Chrome DevTools (or CI)
# Chrome DevTools → Performance tab → Record
# Chrome DevTools MCP → Performance trace

# RUM: Web Vitals library in code
import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

Backend:

# Response time logging
# Application Performance Monitoring (APM)
# Database query logging with timing

# Simple timing
console.time('db-query');
const result = await db.query(...);
console.timeEnd('db-query');

Onde Começar a Medir

Use o sintoma para decidir o que medir primeiro:

What is slow?
├── First page load
│   ├── Large bundle? --> Measure bundle size, check code splitting
│   ├── Slow server response? --> Measure TTFB in DevTools Network waterfall
│   │   ├── DNS long? --> Add dns-prefetch / preconnect for known origins
│   │   ├── TCP/TLS long? --> Enable HTTP/2, check edge deployment, keep-alive
│   │   └── Waiting (server) long? --> Profile backend, check queries and caching
│   └── Render-blocking resources? --> Check network waterfall for CSS/JS blocking
├── Interaction feels sluggish
│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)
│   ├── Form input lag? --> Check re-renders, controlled component overhead
│   └── Animation jank? --> Check layout thrashing, forced reflows
├── Page after navigation
│   ├── Data loading? --> Measure API response times, check for waterfalls
│   └── Client rendering? --> Profile component render time, check for N+1 fetches
└── Backend / API
    ├── Single endpoint slow? --> Profile database queries, check indexes
    ├── All endpoints slow? --> Check connection pool, memory, CPU
    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps

…