Svelte

Гидрация: почему Svelte быстрее

Пользователь открывает страницу, видит контент за полсекунды и довольно тыкает в кнопку - а она не реагирует. HTML уже на экране, но JavaScript ещё догружается и оживляет страницу, и до этого момента клики уходят в пустоту. Этот разрыв между видимым и работающим - цена гидрации. Чем больше JS нужно выполнить, тем дольше окно мёртвых кликов. Svelte атакует проблему с другой стороны: компилятор заранее знает, что и где может измениться, поэтому оживляет страницу точечно, а не пересобирает её целиком в памяти.

  • Карточка товара: HTML виден сразу после SSR, но Купить срабатывает только после гидрации - её скорость решает
  • Лента контента: фреймворки с виртуальным DOM строят всё дерево в памяти при гидрации, Svelte привязывается точечно
  • Метрики Core Web Vitals: меньше клиентского JS - лучше INP и TBT, что напрямую влияет на ранжирование
  • Мобильный трафик на слабом процессоре: тяжёлая гидрация заметно задерживает интерактивность именно там
  • Лендинг почти без интерактива: Svelte догружает минимум JS только для реально интерактивных мест

Предварительные знания

  • Режимы рендеринга SvelteKit: SSR, CSR и поведение по умолчанию
  • Понимание, что после SSR в браузере исполняется тот же код страницы
  • Базовое представление о виртуальном DOM как промежуточном дереве в памяти

Что такое гидрация

После SSR браузер получает готовый HTML: содержимое видно, но это пока статичная разметка без обработчиков событий и реактивности. Гидрация - это процесс, в котором загруженный JavaScript проходит по уже существующему DOM, привязывает к нему обработчики кликов, ввода и реактивные связи, превращая статичную страницу в интерактивное приложение. Разметку при этом не пересоздают - её переиспользуют.

Между моментом, когда HTML стал виден, и моментом, когда гидрация завершилась, есть разрыв. Пользователь видит кнопку и может на неё нажать, но обработчик ещё не привязан, и клик пропадает. Чем больше JavaScript нужно загрузить и выполнить, тем шире это окно неотзывчивости. Сокращение работы при гидрации - прямой путь к более раннему интерактиву.

Гидрация нужна только тогда, когда есть и SSR, и клиентский JS. Полностью статичная страница с csr = false не гидрируется вовсе - ей нечем и незачем оживать. Чистое клиентское приложение, наоборот, не гидрирует, а строит DOM с нуля, потому что серверного HTML для переиспользования нет.

Что происходит во время гидрации страницы после SSR?

Компилятор против виртуального DOM

Рантайм-фреймворки с виртуальным DOM работают в браузере как универсальная машина: при гидрации они строят в памяти виртуальное дерево всего интерфейса и сверяют его с пришедшей разметкой, чтобы понять, к чему привязываться. Эта работа пропорциональна размеру страницы и требует тащить в браузер сам рантайм - движок сравнения деревьев.

Svelte устроен иначе: он компилятор, а не рантайм. На этапе сборки компилятор анализирует каждый компонент и заранее знает, какие именно узлы DOM зависят от какого состояния. В браузер он отдаёт небольшой код, который при гидрации привязывается напрямую к нужным элементам по их позиции в разметке - без построения виртуального дерева и без пошагового сравнения всей страницы.

  • Виртуальный DOM (рантайм) — Браузер тащит движок сравнения, при гидрации строит дерево всей страницы в памяти и сверяет его с разметкой. Работа растёт с размером интерфейса
  • Компилятор Svelte — Связи узел-состояние известны на сборке. В браузере точечная привязка к нужным элементам, без виртуального дерева и общего сравнения

Практическое следствие - меньше клиентского JavaScript и меньше работы процессора при старте. Не нужно грузить рантайм-движок, не нужно сравнивать дерево целиком. Свежие версии Svelte углубляют это: реактивность на рунах позволяет привязываться ещё точечнее, оживляя ровно те фрагменты, что действительно интерактивны, а не страницу целиком.

Идея проста: чем больше работы сделано на этапе компиляции, тем меньше её остаётся на устройстве пользователя. Svelte переносит анализ интерфейса со времени выполнения в браузере на время сборки, и именно поэтому гидрация выходит легче.

Чем гидрация в Svelte отличается от рантайм-фреймворка с виртуальным DOM?

Влияние на Core Web Vitals

Core Web Vitals - набор метрик Google, которыми измеряют реальный опыт пользователя и которые влияют на ранжирование. Часть из них напрямую страдает от тяжёлой гидрации. INP (Interaction to Next Paint) измеряет, насколько быстро страница отвечает на действия пользователя. TBT (Total Blocking Time) показывает, как долго главный поток занят выполнением JavaScript и не реагирует на ввод.

МетрикаЧто измеряетСвязь с гидрацией
LCPСкорость показа основного контентаУлучшается от SSR и пререндера: контент виден рано
INPОтзывчивость на действия пользователяСтрадает, пока тяжёлая гидрация занимает главный поток
TBTВремя блокировки главного потокаРастёт с объёмом исполняемого при старте JavaScript

Логика прямая: чем меньше JavaScript нужно загрузить и выполнить при гидрации, тем короче блокировка главного потока и тем раньше страница начинает отвечать на ввод. Точечная гидрация Svelte и меньший объём клиентского кода уменьшают TBT и улучшают INP. На мощном десктопе разница может быть незаметна, но на бюджетном телефоне со слабым процессором она ощутима.

Гидрация - не единственный фактор метрик, и Svelte не делает медленный код быстрым автоматически. Раздутые сторонние библиотеки, тяжёлые изображения и лишние запросы испортят Core Web Vitals независимо от фреймворка. Преимущество компиляторного подхода - в меньшем базовом объёме клиентского кода, а не в иммунитете к плохим решениям.

Почему меньший объём клиентского JavaScript при гидрации улучшает метрику INP?

Связь с другими темами

Гидрация - продолжение разговора о рендеринге, начатого в предыдущем уроке:

  • SSR, CSR и prerender — Гидрация наступает сразу после SSR; режим рендера определяет, нужна ли она вообще
  • Адаптеры и пререндеринг — Пререндер и лёгкая гидрация вместе минимизируют работу клиента ради быстрых метрик
  • Паттерны загрузки данных — Стриминг данных и быстрая гидрация дополняют друг друга в гонке за ранний интерактив

Итог

  • Гидрация - это оживление уже отрисованного сервером HTML: код в браузере привязывает обработчики и реактивность к существующей разметке
  • Между показом HTML и завершением гидрации страница видна, но не реагирует на ввод - это окно стоит сокращать
  • Рантайм-фреймворки с виртуальным DOM при гидрации строят дерево в памяти и сверяют его с разметкой по всей странице
  • Svelte компилирует компоненты заранее и при гидрации привязывается точечно к нужным узлам, без полного виртуального дерева
  • Меньше клиентского JavaScript и точечная привязка улучшают Core Web Vitals: INP и TBT, особенно на слабых устройствах

Связанные уроки

  • sv-25-ssr-csr — Гидрация - это второй шаг после SSR; без понимания серверного рендера разговор о ней повисает в воздухе
  • sv-27-prerendering-adapters — И пререндер, и точечная гидрация служат одной цели - минимуму работы у клиента ради быстрых метрик
  • sv-23-data-loading-patterns — Стриминг данных и быстрая гидрация дополняют друг друга в гонке за ранний интерактивный экран
Гидрация: почему Svelte быстрее

0

1

Войти