Otimização da performance UI

1) O que contar «rápido»

TTFB (até o primeiro byte) - resposta rápida do servidor/CDN.
LCP (Largest Contentful Paint) - conteúdo «principal» apareceu rapidamente.
INP (Interation to Next Paint) - Reactividade na interação.
CLS (Cumulative Layout Shift) - Nenhuma interface «tremer».
TTI - Quando tudo já responde.
Referência recomendada: LCP ≤ 2. 5 c, INP ≤ 200 ms, CLS ≤ 0. 1 (para 75 percenteis de utilizadores reais).

2) Processo: medir → encontrar estreitos → fixar orçamentos

1. Mede: RUM (usuários reais, sintetizados por países/redes/device) + sintéticos (navegadores Lighthouse).
2. Localizar: Perfilador de Performance (tarefas longas> 50 ms, layout thrashing, renders extras).
3. Fixar: orçamentos (peso JS/CSS/fontes, LCP/INP) e «linhas vermelhas» em CI.

3) Rede e download de recursos

3. 1 HTTP e prioridades

Incluir HTTP/2/3, compactação Brotli.
'precisnect' a domínios críticos; 'dns-prefetch' a domínios secundários.
'pronoad' para recursos críticos (imagem herói, fonte principal).
'fetchpriority =' high/low 'e' priority 'dicas de suporte.

3. 2 Armazenamento em dinheiro

A estática com o hasteamento do arquivo é 'Cachê-Controle: público, max-age = 31536000, imutável'.
HTML - TTL + stale-while-revalidate curto via CDN.
ETAG/Last-Modificed e Service Worker para visitas offline/repetidas.

4) Código: menor, mais tarde, «mais fácil»

4. 1 Montagem

Tree-shaking, minify (в т.ч. dead-code-elim).
Código-splitting por rotas/widgets, importação dinâmica.
Evitar pacotes pesados «globais» no bandle básico (point → Intl/Day. js).

4. 2 Renderização e entrega de HTML

SSR/ISR/strip - dar o esqueleto e o conteúdo principal primeiro.
Partial/Islands hypration - Hidratar apenas áreas interativas.
Defer é tudo não-rítico: '<script estando =' module 'defer>'.

4. 3 Especificidades reativas (se usar o React)

`React. lazy '+' suspense 'para widgets preguiçosos.
'startTransition' e 'useDeferredValue' para filtros pesados/busca.
RSC (Server Componentes) - Computação no servidor, menos JS no cliente.
Seletores no estato (zustand/redux): assina o componente em fatias, em vez de todo o estore.

5) Render e condição: onde «trava»

5. 1 Isolamento dos reteiros

Fatie os grandes componentes, memue ('memo', 'useMemo', 'useCallback').
Chaves de lista - estáveis; não crie novas funções/objetos sem necessidade.
Evite o contexto global para dados que mudam frequentemente - use seletores ou pneus de evento.

5. 2 Virtualização e grandes listas

Folhas/tabelas → virtualização (render window).
Paginação/impinit scroll com backpressure (não carregue 100k linhas imediatamente).
Inicialização adiada de widgets pesados fora do vooport.

5. 3 Layout & paint

content-visibility: auto; para seções ocultas (o navegador não renderá o invisível).
contain e 'contain-intrinsic-size' para tamanhos previsíveis.
Evite as leituras frequentes de layout (layout thrashing); agrupe as medidas.
use a dosagem (senão memória extra/camadas).

6) Imagens e gráficos

Formatos: AVIF/ WebP (fallback em PNG/JPEG).
Abordagem Responsive: 'srcset' + 'sizes', density-based para retina.
'loading =' lazy 'para imagens não heróicas; priority/proload - apenas para o candidato LCP.
Playsholders com tamanhos fixos → nenhum salto CLS.
Canvas/lista: offscreen-canvas e Web Worker para cálculos; batching de desenhos.

7) Fontes e texto

Um ou dois fons variáveis em vez de muitos desenhos.
'fonte-display: swap '/' optional', proload para o desenho principal.
'size-adjust' para reduzir «saltar» ao trocar uma fonte.
Fontes fallback locais com métricas semelhantes.

8) CSS e animações

Crucial CSS inline (<14-20 kB), o resto é adiado.
Remover estilos não utilizados (Purge/CSSTree).
Animações sempre que possível em transfer/opacity; respeitar 'preferers-reduced-motion'.
Evitar cascatas profundas e seletores detonantes.

9) Web Workers, fluxo e tarefas pesadas

Todos os CPU pesados são em Worker (parsing, triagem, agregação, ML).
API de streaming ('ReadableStream', 'fetch' com fluxos) para respostas longas.
Dividir tarefas em chancas através de 'requestIdleCallback '/microtascos para manter a sensibilidade.

10) Estabilidade do layout (CLS)

Reserve espaço abaixo do item LCP (imagem/widget).
Não coloque banners/fitas sem tamanho fixo.
Tultipos/brindes assimétricos - não mover conteúdo; usar camadas/portais.

11) Exemplos de snippets

Fonte crítica e imagem LCP

html
<link rel="preload" href="/fonts/Inter. var. woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" as="image" href="/hero. avif" imagesrcset="/hero. avif 1x, /hero@2x. avif 2x" fetchpriority="high">

Inicialização preguiçosa e segura do widget

js const Widget = React. lazy(() => import('./Widget'));
function Section() {
const inView = useInViewport('#sec');
return <div id="sec">{inView? <React. Suspense fallback={null}><Widget/></React. Suspense>: null}</div>;
}

Estabilizar layout

css
.hero {
content-visibility: auto;
contain: layout paint;
contain-intrinsic-size: 720px 320px ;/LCP reserve/
}

12) Controle de regressão e orçamentos

Bundle-budget: JS-N kB compartilhado, CSS-M kB, inicial-chunk KB.
Web-Vitals em CI (emulados) + alertas RUM (em percentilos).
Análise de Bandle: fonte-map-explorer/analisador em PR.
Performance-benchmark de componentes (render 10k elementos, tempo de reação).

13) Anti-pattern

Carregar «tudo e logo»: gráficos, editores, mapas na primeira tela.
Uma enorme esteira global → retalhos em cascata.
Imagens em 2-4 x do tamanho desejado, sem 'srcset/sizes'.
Ciclos sincronizados longos no fluxo principal.
'outline: none' e fofocas de castoma sem otimização - atrapalham os indicadores de render.
Animações por 'top/left' (quebram o layout e causam reflow).

14) Folha de cheque da tela

• LCP ≤ 2. 5 c no tráfego 3G/mobile, CLS ≤ 0. 1, INP ≤ 200 ms
• Recursos críticos: proload/prioridades; resto - defer/lazy
• Bandas: código-split, sem dependências extras
• Virtualização de listas/tabelas, inicialização adiada de widgets pesados
• Imagens: AVIF/WebP, 'srcset/sizes', 'loading =' lazy '
• Fontes: variável + 'fonte-display', preteload apenas
• CSS: inline crítico, Purge, 'conteúdo-visibilidade' e 'contain' onde for apropriado
• Workers/idle para cálculos pesados
• Orçamentos e Web-Vitals estão ligados a dashboards/alertas

15) Plano de implementação (3 iterações)

Iteração 1 - Vitórias rápidas (1-2 semanas)

Incluir Brotli/HTTP-2/3, CDN. CSS e recursos LCP críticos.
Levar widgets pesados para importações dinâmicas.
Imagens → AVIF/WebP + 'srcset'. Fontes: 'fort-display: swap'.

Iteração 2 - Melhorias estruturais (3-4 semanas)

Código-split sobre trilhos, análise de bandlho, remoção de «pesados».
Virtualização de listas, conteúdo-visibilidade, contain-intrinsic-size.
Implementar SSR/streaming/ilhas (onde é relevante).
RUM com Web-Vitals, orçamentos em CI.

Iteração 3 - Escala e estabilidade (contínua)

Workers/offscreen-canvas, batching, startTransition/deferredValue.
Auditoria de perf regular, regresso automático, treinamento de equipa.

16) Mini-FAQ

O que vai acelerar mais no mobil?
Reduza o JS inicial, SSR/streaming e otimiza a imagem LCP.

É sempre necessário um SSR?
Não. Se a página for dinâmicamente interativa e mal armazenada - islands/partial hypration pode ser melhor.

Porque é que o INP é mau com um bando leve?
Provavelmente longas tarefas (triagem, gráficos) no fluxo principal - leve para o Worker e execute as tarefas.

Resultado

A UI rápida é um conjunto de disciplinas: prioridades de rede e dinheiro, bandos menores e recentes, render previsível sem saltos, imagens e fontes de baixo custo e controle contínuo de métricas no mundo real. Digite os orçamentos, automatize as verificações e ensine o comando a pensar na velocidade a cada passo - para que a interface fique rápida hoje e dentro de um ano.