Гидратация: совпасть с HTML сервера и заплатить за отгруженный JS

Что гидратация делает на самом деле

Серверный HTML — это краска, а не поведение: пользователь видит готовую страницу, но ни один слушатель не навешен, состояния не существует, ref пустые. Гидратация — то, как React оживляет страницу: hydrateRoot(domNode, reactNode) рендерит дерево компонентов на клиенте ещё раз — но вместо создания DOM он обходит существующий серверный DOM, усыновляет каждый узел в своё fiber-дерево, навешивает обработчики событий и инициализирует состояние и эффекты. Это рендер, чей результат — реконсиляция с уже существующей разметкой.

У этой конструкции одно жёсткое предусловие, прямо сформулированное в доках React: дерево, переданное в hydrateRoot, обязано произвести тот же результат, что произвёл сервер. React не сверяет-и-патчит различия во время гидратации; совпадение — допущение, зашитое в алгоритм, а не предоставляемая фича. Текстовые различия в development патчатся с предупреждением, но структурные и атрибутные расхождения в React 18 запускают восстановление: React бросает серверный HTML затронутой границы и выполняет полный клиентский рендер ей на замену. Видимая цена — вспышка заменённого контента; цена по производительности — пользователь на среднем устройстве только что отрендерил страницу дважды: один раз в HTML, с которым нельзя взаимодействовать, второй — в JS, заблокировавшем главный поток.

// Три классические фабрики расхождений — везде «два честных рендера, два ответа»:

// 1. Время: сервер рендерит в T0, клиент гидратируется в T0 + сеть + парсинг + исполнение.
<span>{formatRelative(order.createdAt, Date.now())}</span>

// 2. Локаль/окружение: ICU Node против настроек браузера пользователя.
<td>{price.toLocaleString()}</td>

// 3. Browser-only ветки: во время серверного рендера window не существует.
<div>{typeof window !== "undefined" ? <LocalStorageGreeting /> : <DefaultGreeting />}</div>

// Форма лекарства всегда одна: первый клиентский рендер равен серверному.
function ClientOnly({ children }: { children: React.ReactNode }) {
  const [mounted, setMounted] = useState(false);
  useEffect(() => setMounted(true), []);   // эффекты выполняются только после гидратации
  return mounted ? <>{children}</> : null; // и сервер, и первый клиентский рендер: null
}

Паттерн лечения стоит подчеркнуть, потому что он выглядит парадоксально: чтобы отрендерить браузеро-зависимый контент, вы рендерите ничего (или плейсхолдер) и на сервере, и в первом клиентском проходе, а переключаетесь после срабатывания useEffect — эффекты выполняются только после гидратации, так что переключение становится обычным обновлением, а не расхождением. Для единичного неустранимого различия (метка времени, которую сервер обязан отрендерить) есть suppressHydrationWarning на этом элементе — он велит React не трогать одно текстовое различие: скальпель, а не политика. Случайные ID правильно решаются через useId, который стабилен при гидратации по построению.

Выборочная гидратация: Suspense как граница гидратации

До React 18 гидратация была монолитной: один синхронный проход по всему дереву, и ничто не интерактивно, пока не готово всё. Страница не могла даже начать гидратироваться, пока не приехал весь её JS, а тяжёлый компонент высоко в дереве держал в заложниках всех соседей. Выборочная гидратация React 18 ломает монолит через <Suspense>: каждая граница Suspense становится независимо гидратируемым островом. Гидратация идёт граница за границей, кусками, уступающими главный поток — и она управляется приоритетом: если пользователь кликает внутри ещё-не-гидратированной границы, React записывает событие и синхронно гидратирует эту границу первой, вне очереди, а затем воспроизводит взаимодействие. Тяжёлый виджет комментариев внизу больше не задерживает кнопку покупки наверху.

Это сочетается со стриминговым SSR: серверный компонент, который суспендится (медленные данные), достримливает свой HTML позже и гидратируется по прибытии, пока оболочка уже интерактивна. Ментальная модель сдвигается от «страница гидратируется» к «границы гидратируются — в порядке, нужном пользователю».

export default function ProductPage() {
  return (
    <main>
      <BuyBox />                       {/* критично: гидратируется первым */}
      <Suspense fallback={<Skeleton />}>
        <Reviews />                    {/* тяжёлый: стримится + гидратируется позже */}
      </Suspense>
      <Suspense fallback={<Skeleton />}>
        <Recommendations />            {/* пользователь кликнул сюда? -> вне очереди */}
      </Suspense>
    </main>
  );
}

Второе свойство важно операционно: в React 18 расхождение гидратации внутри границы Suspense восстанавливается только в этой границе — клиентский перерендер ограничен островом и не каскадирует до корня. Границы — это стены, ограничивающие радиус поражения при восстановлении, а не только loading-состояния.

Острова, INP и JS, который вы не отгрузили

Прежде чем оптимизировать скорость гидратации, задайте более полезный вопрос: а сколько из того, что вы гидратируете, вообще должно работать в браузере? В большинстве приложений — намного меньше, чем сейчас отгружается.

Стоимость гидратации примерно пропорциональна отгруженному JS: каждый отгруженный компонент нужно скачать, распарсить, исполнить и реконсилировать с DOM, прежде чем он станет по-настоящему интерактивным. Эта работа ложится на главный поток и проявляется в двух полевых метриках. TBT (Total Blocking Time, лабораторная) накапливает каждый кусок long task свыше 50 мс во время загрузки — монолитная гидратация большого дерева и есть такая задача: нередко 1–3 секунды блокировки на среднем Android за несколько сотен KB компонентов. INP (Interaction to Next Paint, Core Web Vital) измеряет задержку реальных взаимодействий; порог «хорошо» — 200 мс, и тап, попавший в середину гидратации, ждёт главный поток, прежде чем хоть что-то отрисуется. Страница выглядит готовой — HTML отрисован секунды назад — но тычется как мёртвая: зазор между «отрисовано» и «интерактивно» и есть окно гидратации, и пользователи проводят его в rage-кликах.

Архитектурный ответ экосистемы — острова интерактивности: рендерить на сервере всё, гидратировать только компоненты, которым JS действительно нужен. Next.js выражает острова через границу RSC — серверные компоненты не шлют JS и не гидратируются вовсе; гидратируются только поддеревья за "use client". Astro выражает то же по-островными директивами; Qwik идёт дальше и возобновляет сериализованное состояние вместо повторного рендера. Инженерный рычаг везде один, и он у вас в руках: самая быстрая гидратация — та, которую вы не отгрузили. Перенос форматтера, статического графика или markdown-тела из клиентского компонента в серверный не ускоряет гидратацию — он заставляет гидратацию этого поддерева перестать существовать, и TBT/INP улучшаются прямо пропорционально.