00:00:00O GitHub acaba de lançar um add-on muito poderoso para o Storybook que muda totalmente a
00:00:05forma como testamos o desempenho de componentes.
00:00:07Ele inclui um painel de desempenho muito detalhado, repleto de informações valiosas, como medição
00:00:12de tempo de quadro, responsividade de entrada, estabilidade de layout, perfil do React, pressão de memória
00:00:18e muito mais.
00:00:19Neste vídeo, vamos analisar de perto o que esse add-on tem a oferecer.
00:00:23Vai ser muito legal, então vamos nessa.
00:00:31Uma pergunta rápida antes de começarmos.
00:00:32Você sabe o que é teste de desempenho "shift-left"?
00:00:35É um paradigma de desenvolvimento que dita que o desempenho dos componentes do seu app
00:00:40deve ser testado logo no início do processo, e não como uma reflexão tardia.
00:00:45E esta ferramenta foi feita especificamente para ajudar os desenvolvedores a tomarem essas decisões precoces,
00:00:50oferecendo uma visão em tempo real de como seus componentes se comportam antes de chegarem à produção.
00:00:55O painel de desempenho do Storybook fornece uma visão de alta fidelidade de como seus componentes
00:01:00interagem com o mecanismo de renderização do navegador.
00:01:02Ele rastreia, por exemplo, o tempo dos quadros para identificar o "jitter" — aquelas pequenas falhas
00:01:07irregulares entre os quadros que fazem as animações parecerem travadas.
00:01:10Também monitora a thread principal em busca de rotatividade e excesso de processamento no DOM.
00:01:15A rotatividade do DOM ocorre quando o código cria, exclui ou atualiza elementos desnecessariamente em um loop curto,
00:01:20enquanto o excesso de processamento ocorre quando o navegador é forçado a recalcular o layout várias
00:01:25vezes em um único quadro porque você está lendo e escrevendo estilos consecutivamente.
00:01:30E este add-on se adapta a qualquer framework que você esteja usando.
00:01:33Se estiver usando React, ele pode destacar métricas como cascatas de renderização, que são aquelas pequenas
00:01:38mudanças de estado que acidentalmente disparam uma onda massiva e lenta de re-renderizações em todo o app.
00:01:44Ele também rastreia a duração P95, que mostra o pior cenário para os seus usuários mais lentos,
00:01:50em vez de apenas uma média.
00:01:52E se você não usa React, o modo universal funciona perfeitamente para Vue, Svelte ou web
00:01:58components.
00:01:59Para melhores resultados, recomenda-se executar este add-on no Chrome ou Edge.
00:02:04Eles também têm um guia ao vivo onde podemos ver essas métricas em ação.
00:02:08Por exemplo, no exemplo da caixa animada, podemos rastrear exatamente quantas mutações
00:02:13de estilo inline estão ocorrendo durante uma animação.
00:02:16Neste caso, tudo parece saudável.
00:02:18A taxa e o tempo de quadros permanecem perfeitamente estáveis, o que significa que o navegador está lidando
00:02:23com essas atualizações de estilo sem o menor esforço.
00:02:25No entanto, o exemplo da lista pesada conta uma história diferente.
00:02:29Ao filtrar esta lista grande, vemos alguns sinais de alerta.
00:02:32Primeiro, o deslocamento cumulativo de layout (CLS) sobe para um valor muito alto, indicando que os elementos
00:02:38estão saltando significativamente conforme carregam, criando uma experiência desagradável para o usuário.
00:02:43Também vemos um pico na rotatividade do DOM, o que significa que o navegador está trabalhando dobrado para
00:02:49remover e reconstruir um número massivo de nós de uma só vez.
00:02:52Isso também resulta em quadros perdidos, o que acaba com a percepção de velocidade e fluidez
00:02:57da interface.
00:02:58No exemplo de tempo do elemento, qualquer elemento DOM com o atributo "element timing" é medido
00:03:04quanto ao seu tempo exato de renderização.
00:03:06Isso é incrivelmente útil porque ajuda a identificar o momento exato em que seu conteúdo principal
00:03:11ou sua chamada para ação se torna visível, dando uma imagem mais precisa do desempenho percebido
00:03:17em vez de apenas métricas genéricas de carregamento de página.
00:03:21E quando olhamos para o exemplo de renderização cara, se clicarmos no botão de re-renderizar, isso faz
00:03:26com que a duração p95 dispare.
00:03:29Isso acontece porque a thread principal está sendo mantida refém pela execução pesada de JavaScript,
00:03:34fazendo a interface parecer muito lenta.
00:03:36Também vemos avisos de jitter de quadro aqui, que indicam uma renderização inconsistente onde o tempo
00:03:41entre os quadros oscila bruscamente.
00:03:44E também há um alto tempo total de bloqueio, ou TBT.
00:03:47O TBT é um grande sinal de alerta porque indica que a thread principal foi bloqueada por tempo
00:03:52suficiente para impedir que o usuário interagisse com a página, como clicar
00:03:57em um botão ou rolar a tela.
00:03:58Vemos uma falha semelhante no exemplo de desperdício de memoização.
00:04:03Aqui, a demonstração mostra que re-renderizar cada elemento desnecessariamente leva a um
00:04:08atraso massivo.
00:04:09Em contraste, o exemplo devidamente memoizado mostra quanto trabalho é economizado se
00:04:15memoizarmos nossos componentes.
00:04:16Ao pular essas renderizações redundantes, mantemos a thread principal livre e a taxa de quadros estável
00:04:21para obtermos aqueles 60 quadros por segundo super fluidos.
00:04:25No exemplo de cascata de renderização, vemos exatamente o que acontece quando você usa o "set state" dentro
00:04:30do "use layout effect".
00:04:31Cada incremento dispara uma cascata porque o "use layout effect" é executado sincronicamente após
00:04:37todas as mutações do DOM, mas antes que o navegador tenha a chance de pintar a tela.
00:04:42Ao disparar a atualização de estado aqui, você está forçando o React a reprocessar a árvore de componentes
00:04:47e o navegador a recalcular o layout uma segunda vez antes mesmo que o usuário veja o
00:04:52primeiro resultado.
00:04:53Isso é ruim porque, efetivamente, dobra o trabalho para cada quadro, levando a um
00:04:58atraso de renderização que pode fazer até interações simples parecerem pesadas.
00:05:02E há o exemplo de rotatividade de estilo que também demonstra uma observação crítica.
00:05:07O que acontece quando alteramos os estilos inline de 600 nós diferentes ao mesmo tempo?
00:05:13Vemos imediatamente estes avisos de paralisação na seção de excesso de processamento, indicando que
00:05:18o navegador está sendo forçado a entrar em um loop de reflow.
00:05:21Ele tenta calcular as posições de 600 elementos simultaneamente enquanto o JavaScript ainda
00:05:26está fazendo alterações.
00:05:27Isso leva a sinais vitais prejudiciais para nossas métricas de quadros porque a thread principal está totalmente
00:05:33saturada.
00:05:34Espero que todos esses exemplos mostrem como você pode usar este add-on do Storybook para identificar
00:05:38gargalos em um ambiente muito mais preciso.
00:05:41Claro, você pode usar uma ferramenta como o Lighthouse, mas o Lighthouse é uma abordagem genérica.
00:05:46Ele não oferece aquela precisão cirúrgica para ver exatamente como um componente individual
00:05:51impacta o desempenho do seu aplicativo.
00:05:53Eu realmente encorajo você a baixar este add-on, adicioná-lo ao seu conjunto do Storybook e apenas
00:05:58testá-lo.
00:05:59Há muitos insights valiosos a serem obtidos ao ver a imagem completa de como seus componentes
00:06:03realmente operam nos bastidores.
00:06:06Então é isso, pessoal, este é o novo add-on do painel de desempenho do GitHub para o Storybook
00:06:10em resumo.
00:06:11O que você achou dele?
00:06:13E como você mede o desempenho na sua aplicação?
00:06:16Conte para a gente nos comentários abaixo.
00:06:18Pessoal, se vocês gostam desse tipo de análise técnica, por favor me avisem clicando
00:06:22no botão de curtir abaixo do vídeo e também não se esqueçam de se inscrever no canal.
00:06:28Aqui é o Andres, da Better Stack, e vejo vocês nos próximos vídeos.