A Verdadeira Raiz do Peso do seu React

O problema

Tem explicação sobre React pesado que e simples demais para ajudar:

• “React e pesado”
• “SPA e sempre lenta”
• “o problema e o virtual DOM”

Essas frases podem soar inteligentes em discussão rápida.

Mas para diagnostico real elas ajudam pouco.

Porque o que o usuário sente como peso normalmente não vem de uma unica causa abstrata chamada React.

Modelo mental

Quando um app React parece pesado, vale decompor o problema em camadas:

• quanto JavaScript foi enviado
• quanto desse JavaScript precisa ser executado
• quanta hydration foi feita
• quanto estado e lógica foram jogados para o cliente
• quanto trabalho de renderização e re-renderização foi criado

Em linguagem simples:

o peso costuma vir da quantidade de trabalho que o browser recebeu, não do nome da biblioteca sozinho.

Quebrando o problema

Bundle grande e só uma parte

Claro que enviar script demais pesa.

Mas o peso continua depois:

• parse
• execução
• hydration
• atualização de estado

Entao reduzir o problema a “o bundle esta grande” ainda e meia explicação.

Cliente demais

Um erro comum em app React moderno e empurrar para o cliente coisas que não precisavam estar la.

Exemplos:

• componente puramente estatico marcado como cliente
• pagina inteira hidratada por conveniencia
• dado simples transformado em estado interativo sem necessidade

Quando a fronteira entre servidor e cliente fica frouxa, o browser recebe mais responsabilidade do que precisava.

Estado demais também pesa

Quanto mais estado espalhado, mais chance de:

• render desnecessaria
• efeito em cascata
• dependências mal controladas
• componente recomputando mais do que deveria

O problema não e “usar estado”.

E usar estado onde bastava:

• valor derivado
• props
• HTML pronto
• dado sem necessidade de interação imediata

Hydration larga custa caro

Esse ponto costuma ser subestimado.

A pagina chega com HTML, mas para ficar interativa o browser ainda precisa ligar muita coisa.

Se quase tudo precisa hidratar:

• a CPU trabalha bastante
• a interatividade demora
• o app parece pesado mesmo com primeira pintura aceitavel

React pesa mais quando vira desculpa para falta de critério

React permite compor muita coisa rápido.

Sem critério, isso vira:

• árvore enorme
• abstração demais
• provider demais
• wrapper demais
• re-render demais

O framework não obrigou isso.

Ele só deixou possível.

Exemplo simples

Imagine uma pagina de produto.

Versão pesada:

• quase toda a pagina e cliente
• vários providers globais para coisas locais
• recomendações, reviews e widgets todos hidratados na primeira carga
• estado duplicado em várias camadas

Versão mais leve:

• HTML principal vem pronto
• só o que precisa de interação imediata vira cliente
• partes secundarias entram depois ou com menos escopo
• estado fica mais perto de onde realmente muda

Nos dois casos o app “usa React”.

Só que o trabalho empurrado para o browser e muito diferente.

Erros comuns

• Culpabilizar o framework e parar a analise ai.
• Tratar hydration como detalhe invisível.
• Colocar tudo no cliente por conveniencia.
• Criar estado para dado que não precisava virar estado.
• Confundir componente demais com arquitetura melhor.

Como um senior pensa

Quem tem mais experiência costuma olhar para app React pesado e perguntar:

“Que parte desse trabalho realmente precisa acontecer no cliente, e que parte esta aqui só por falta de fronteira melhor?”

Essa pergunta corta bastante ruido.

Porque tira a conversa da tribo e leva para desenho.

Menos “eu gosto ou não gosto de React”.

Mais “por que o navegador esta trabalhando tanto?”.

O que o entrevistador quer ver

Em entrevista, esse tema costuma separar quem faz crítica tribal de quem entende browser e arquitetura.

Você sobe de nivel quando:

• fala de JavaScript, hydration e fronteira cliente/servidor
• menciona estado e renderização desnecessaria
• evita transformar a resposta em guerra de framework
• mostra critério sobre o que realmente precisa ser interativo

Uma resposta forte costuma soar assim:

“Eu não culparia React por reflexo. Primeiro eu olharia quanto JavaScript foi enviado, quanta hydration aconteceu e quanta lógica foi empurrada para o cliente sem necessidade. Em muitos casos, o peso vem mais dessas decisões do que da biblioteca em si.”

React pesado raramente e só um problema de React. Quase sempre e um problema de critério sobre o que o browser foi obrigado a fazer.