Pular para o conteúdo principal
Voltar aos Casos de Sucesso
Performance

Como otimizei meu bundle size corrigindo o tree-shaking no React

PerformanceReactCore Web Vitals

O Ponto de Partida: O que é o LCP e por que ele importa?

O Largest Contentful Paint (LCP) mede quanto tempo o maior elemento de conteúdo leva para aparecer na tela. Ao auditar 8 Micro-Frontends (MFEs), descobri um LCP de 12.7 segundos. Decidi que meu primeiro passo seria reduzir o peso do bundle.

Minha Caixa de Ferramentas

  • New Relic: Observabilidade em tempo real. Essencial para ver o impacto das mudanças no mundo real.
  • Webpack Bundle Analyzer: Gera um mapa visual do bundle. Foi onde vi o "lixo" que estávamos enviando.
  • Import Cost: Extensão para VSCode que mostra o peso de cada biblioteca direto no editor.

O Problema dos Barrel Files

Arquivos index.ts que exportam tudo de uma pasta são práticos, mas perigosos. Eles muitas vezes impedem o Tree-shaking (a remoção de código morto).

❌ Como estava (Barrel File):

// Mesmo que eu só use o Button, o bundler pode acabar trazendo 
// o Modal, o Chart e o Form juntos.
import { Button } from '@/components'; 

✅ Como corrigi (Import Granular):

// Aqui eu garanto que apenas o código do Button entre no bundle.
import { Button } from '@/components/Button/Button';

Ícones Dinâmicos: O vilão silencioso

Eu usava um componente que carregava ícones baseado em uma string. Como o bundler não sabe qual ícone será usado em tempo de execução, ele incluía a biblioteca inteira.

❌ Antes (150KB extras):

const MyIcon = ({ name }) => <Icon name={name} />;

✅ Depois (5KB):

import { HomeIcon } from '@/icons/HomeIcon';
const MyIcon = () => <HomeIcon />;

Primeiro Marco: -500KB no Bundle

Com essas correções, reduzi o bundle de 850KB para 350KB. O LCP caiu para 9.75s. Ainda não é o ideal de 2.5s, mas agora tenho uma base leve para atacar a próxima fase: otimização de renderização.

“O código mais rápido é aquele que nunca é enviado ao usuário.”