Capstone · Performance & rendering

Capstone: "Ticker" — painel de mercado em tempo real com 100k linhas (Angular 21, zoneless)

Capstone "Ticker": painel de mercado ao vivo com 100k+ linhas em Angular 21 zoneless que força junto OnPush/signals granulares, virtual scroll, Web Worker off-main-thread, SSR+hydration+@defer, análise de bundle e budgets/CWV no CI — cada ganho provado por número antes/depois, anti-tutorial-hell por construção.

▶ Demo funcional ao vivo

→ Abrir o Ticker (100k instrumentos, preços ao vivo)
Referência construída do que "pronto" significa: 60fps, ~25 linhas no DOM de 100k, ~15k updates/s via Web Worker, com HUD de performance. É o teu alvo — agora constrói a tua versão em Angular 21.

🎯 O que você constrói

Você constrói uma única feature real: um painel de cotações ao vivo — 100.000+ instrumentos (ações/cripto), busca e filtro instantâneos, uma tabela virtualizada que atualiza de preços por WebSocket, e um bloco de gráficos que só carrega quando entra em viewport. Pequeno para um fim de semana, denso o bastante para portfólio.

Essa feature é o pretexto perfeito porque cada gargalo de performance aparece naturalmente — você não "estuda" os tópicos, você bate de frente com eles:

Change detection / zoneless: preços mudam 20×/s. Com Zone.js isso é morte por CD global. Você roda provideZonelessChangeDetection(), estado 100% em signal()/computed(), tudo OnPush, e prova que só as células que mudaram re-renderizam.
Virtualização: 100k linhas no DOM = travamento. CDK virtual scroll + @for track por id estável forçam DOM recycling. Aqui você sente por que track errado destrói o ganho.
Off-main-thread: filtrar/ordenar/agregar 100k itens na main thread trava o input (INP alto). Web Worker faz o número; a UI só recebe o resultado. requestIdleCallback + debounce na busca evitam layout thrash.
Rendering strategy: SSR com hydration (não-destrutiva) para LCP baixo do shell; @defer como "islands" para o pacote de gráficos; streaming SSR para o TTFB.
Bundle & splitting: a lib de charts é pesada — ela nunca entra no bundle inicial. source-map-explorer prova onde o peso está; budgets no CI impedem regressão.
Core Web Vitals: você mede LCP/INP/CLS de verdade (lab + RUM com web-vitals) e trava orçamento no pipeline.

O fio condutor: tornar visível o invisível. Todo ganho de perf tem que ser medido antes/depois, não sentido "no olho".

Critérios de pronto

App é zoneless (provideZonelessChangeDetection, sem zone.js no polyfills) e TODOS os componentes usam ChangeDetectionStrategy.OnPush — provado por um teste/inspeção que mostra CD disparando só nas linhas com preço alterado, não na árvore inteira.
Tabela renderiza 100.000+ linhas com virtual scroll: DevTools mostra ~algumas dezenas de nós no DOM (não 100k), scroll a 60fps, e @for usa track por id estável.
Filtro + ordenação + agregação de 100k itens rodam num Web Worker; a main thread nunca bloqueia >50ms durante a digitação da busca (comprovado no Performance panel).
Rota renderiza via SSR com hydration incremental/não-destrutiva (sem flicker, sem re-render do shell no cliente) e o bloco de gráficos usa @defer com on viewport.
Bundle inicial (JS transferido) fica abaixo de um budget explícito (ex.: < 200KB gzip); a lib de charts NÃO está no chunk inicial — provado com source-map-explorer e um relatório de chunks commitado.
CI falha se o budget de bundle estourar (angular.json budgets ou bundlesize) E se Lighthouse-CI cair abaixo das metas de CWV — as duas gates no mesmo pipeline.
web-vitals coletando LCP/INP/CLS reais e enviando para um endpoint/console (RUM), com LCP < 2.5s, INP < 200ms e CLS < 0.1 medidos na build de produção.
README com tabela ANTES/DEPOIS de cada otimização (métrica, número, delta) — nenhuma melhoria alegada sem número que a sustente.

Passos sugeridos

Ordem incremental — cada passo entrega algo medível e prepara o próximo. Meça no fim de cada um.

Baseline ruim de propósito. Gere as 100k linhas mock, renderize com @for sem virtual scroll, Zone.js ligado, filtro síncrono na main thread. Rode Lighthouse e Performance panel. Anote os números horríveis — esse é seu ponto de comparação. Sem baseline, nada do resto tem prova.
Vá zeless + OnPush. Remova zone.js, adote provideZonelessChangeDetection(), migre estado para signals, marque tudo OnPush. Meça INP e o custo de CD. Aqui você entende por que CheckAlways não escala com stream de alta frequência.
Virtualize. Troque a lista por CDK virtual scroll (ou windowing manual pra sentir o mecanismo). Corrija o track. Compare DOM node count e fps antes/depois.
Empurre o trabalho pro worker. Mova filter/sort/aggregate para um Web Worker (Angular CLI gera com ng generate web-worker). Debounce a busca; use requestIdleCallback para o que não é urgente. Prove no Performance panel que a main thread respira durante a digitação.
Ligue o real-time. WebSocket (ou mock com interval) atualizando preços. Atualize por signal granular — só a célula do preço, não a linha, não a tabela. Observe o CD com Angular DevTools profiler.
SSR + hydration + @defer. Adicione SSR, hydration não-destrutiva, e isole os gráficos atrás de @defer (on viewport). Meça LCP e TTFB; experimente streaming SSR e compare.
Ataque o bundle. source-map-explorer no build de prod. Ache o peso morto, garanta que charts está em chunk lazy, elimine duplicação. Commit do relatório de chunks.
Trave tudo no CI. Configure budgets no angular.json (ou bundlesize) + Lighthouse-CI com asserts de LCP/INP/CLS. Faça uma PR que estoura o budget de propósito e mostre o CI vermelho.
RUM. Instrumente web-vitals, mande as métricas pra um endpoint (ou log). Feche o README com a tabela antes/depois.

Rubrica de arquitetura

Granularidade de atualização: um preço mudar deve re-renderizar SÓ aquela célula. Se o profiler mostra a linha ou a tabela inteira re-checando, a arquitetura de signals está grossa demais — estado mal fatiado, não OnPush mal aplicado.
Fronteira de dados limpa: o Worker recebe/devolve dados serializáveis mínimos (ids, deltas), não a lista inteira a cada tecla. Transferência excessiva na fronteira main↔worker é falha de arquitetura mesmo com INP ok num dataset pequeno.
Cada otimização é defensável por número, não por intuição: o README liga cada decisão a um delta medido. 'Botei virtual scroll porque é boa prática' sem antes/depois = reprovado no critério de rigor.
Estratégia de rendering coerente com o conteúdo: o que é above-the-fold e estável entra no SSR/hydration; o que é pesado e below-the-fold vai pra @defer/island. Deferir a coisa errada (ou hidratar tudo) mostra que a escolha foi cargo-cult.
Os gates de CI protegem o usuário, não o commit: budgets e CWV asserts têm valores justificados e realmente barram regressão (você provou com uma PR vermelha). Budget frouxo que nunca falha é teatro.
Trade-offs explícitos: em algum ponto do README você nomeia o que sacrificou (ex.: complexidade do worker vs. ganho de INP, custo de SSR vs. LCP) — sênior sabe que perf é troca, não vitória grátis.

← voltar ao skill treefio de evolução · projeto integrador