O problema da hidratação completa

Hidratação é o processo pelo qual o React pega o HTML renderizado pelo servidor e associa ouvintes de eventos JavaScript a ele. O servidor envia o HTML inicial (rápido); em seguida, o navegador baixa o pacote de JavaScript, e o React "hidrata" o HTML estático para torná-lo interativo. Até a hidratação ser concluída, a página parece interativa, mas não é.

Uma aplicação de página única tradicional envia todo o pacote de JavaScript para o navegador. O React precisa baixá-lo, analisá-lo, executá-lo e, em seguida, associar ouvintes de eventos a cada componente da árvore. Em aplicações grandes, esse processo pode levar vários segundos em dispositivos móveis de desempenho intermediário.

O tempo até a interatividade mede quanto tempo leva até que o usuário possa interagir com a página. A hidratação bloqueia diretamente o TTI: a página pode parecer pronta (o HTML renderizado pelo servidor está visível), mas os botões e formulários não respondem até que o React termine de associar os ouvintes de eventos. Um TTI alto proporciona uma experiência ruim ao usuário.

Considere uma página de marketing: 80% do conteúdo consiste em texto estático, imagens e cabeçalhos que nunca mudam. Apenas 20% envolve componentes interativos, como um formulário de boletim informativo ou um reprodutor de vídeo. A hidratação tradicional de uma aplicação de página única ainda é executada em 100% da página, processando componentes estáticos sem necessidade.

A criação de perfis de desempenho no Chrome DevTools revela o custo da hidratação. No gráfico em cascata da linha de execução principal, é possível identificar a tarefa de "hidratação do React" como um bloco longo de execução de JavaScript após a pintura inicial. Quanto mais longo esse bloco, mais ocupada fica a linha de execução principal e menos responsiva fica a página.

Quanto maior a árvore de componentes do React, mais trabalho a hidratação exige. O React precisa visitar cada componente, comparar o HTML renderizado pelo servidor com o que o componente renderizaria e associar ouvintes de eventos. Uma página complexa com centenas de componentes pode ter uma sobrecarga de hidratação mensurável até mesmo em dispositivos rápidos.

O React 18 introduziu a hidratação concorrente, que permite ao React dividir a hidratação em partes menores e ceder o controle ao navegador entre elas. Isso impede que o navegador pareça completamente congelado durante a hidratação de árvores grandes. No entanto, a hidratação concorrente reduz o impacto, mas não elimina o custo fundamental.

A hidratação seletiva (por meio de Suspense) permite que o React hidrate os componentes por ordem de prioridade — as interações do usuário acionam a hidratação imediata do componente relevante. Isso melhora a responsividade, mas ainda funciona dentro de uma única árvore do React: todos os componentes da árvore acabam sendo hidratados.

A ideia fundamental que impulsiona a Arquitetura de ilhas é que a maior parte de uma página típica simplesmente não precisa de JavaScript. Barras de navegação, seções principais, links do rodapé, texto de publicações de blog e descrições de produtos são puramente elementos de apresentação. Forçar a hidratação desses elementos é, por definição, desperdício.

Estudos de equipes de desempenho web mostram que o tempo de análise e execução do JavaScript é o principal custo em dispositivos móveis. Um pacote de JavaScript de 300 KB leva de 2 a 3 segundos para ser analisado em um telefone Android mediano. Reduzir o JavaScript enviado ao navegador traz benefícios de desempenho muito maiores do que qualquer otimização interna do React.

Cada quilobyte de JavaScript adicionado a uma aplicação React acrescenta trabalho de hidratação. Mesmo que um componente seja puramente decorativo, se estiver na árvore do React, ele participará da hidratação. Esse "imposto da hidratação" aumenta conforme o tamanho da aplicação e torna progressivamente mais difícil manter bons valores de TTI à medida que as aplicações crescem.

Qual é a relação entre a hidratação do React e o tempo até a interatividade (TTI)?

A hidratação tradicional do React processa toda a árvore de componentes, inclusive o conteúdo estático que não precisa de JavaScript. Isso bloqueia o tempo até a interatividade e apresenta uma escalabilidade ruim conforme o tamanho da aplicação aumenta. As melhorias de hidratação concorrente e seletiva do React 18 reduzem o impacto, mas não eliminam o custo fundamental. A ideia central é que a maior parte do conteúdo da página simplesmente não precisa de JavaScript, tornando a hidratação completa um desperdício.