server side rendering

Server-Side Rendering (SSR, серверный рендеринг) — техника веб-разработки, при которой HTML-страница формируется на сервере и отправляется клиенту уже в готовом виде. В отличие от клиентского рендеринга (CSR), где браузер сначала загружает JavaScript-бандл и только потом строит DOM, SSR позволяет пользователю увидеть содержимое страницы значительно быстрее — ещё до того, как весь JavaScript будет загружен и выполнен.

SSR vs CSR: принципиальные различия

В модели клиентского рендеринга (типичный React SPA) браузер получает пустой HTML-файл с тегом <div id="root">, загружает JavaScript-бандл, выполняет его, строит виртуальный DOM и монтирует приложение. Всё содержимое страницы появляется только после завершения этой цепочки. Для пользователей с медленным соединением или слабыми устройствами это приводит к заметной задержке белого экрана.

При SSR сервер выполняет рендеринг React/Vue/Angular компонентов, генерирует полноценный HTML и отправляет его клиенту. Браузер сразу отображает содержимое. JavaScript по-прежнему загружается, но его единственная задача — «оживить» уже существующий HTML (hydration), а не строить DOM с нуля.

Метрики производительности: FCP, LCP, TTI

SSR напрямую влияет на ключевые метрики Web Vitals:

• First Contentful Paint (FCP) — время до первого отображения любого содержимого. SSR значительно улучшает FCP, так как браузер получает готовый HTML без ожидания JS.
• Largest Contentful Paint (LCP) — время рендеринга наибольшего видимого элемента. SSR ускоряет LCP, что напрямую влияет на позиции в Google.
• Time to Interactive (TTI) — время до полной интерактивности. Здесь SSR не всегда выигрывает: страница видна, но не интерактивна до завершения гидратации.

Гидратация (Hydration): соединение HTML и React

После получения HTML сервера браузер загружает JavaScript и React «гидратирует» DOM: привязывает обработчики событий и состояние к существующим HTML-узлам без перерисовки. Это критичный шаг: если серверный HTML не совпадает с тем, что React ожидает (несоответствие гидратации), React перестроит DOM, что приведёт к мерцанию и потере производительности.

React 18 введёт Selective Hydration: компоненты, обёрнутые в Suspense, гидратируются независимо и в порядке приоритета — сначала те, с которыми взаимодействует пользователь.

SSR и SEO

Поисковые роботы (Googlebot, Яндексбот) индексируют HTML-содержимое страниц. Хотя Google научился рендерить JavaScript, рендеринг CSR-страниц ставится в очередь и происходит позже. SSR гарантирует, что бот получит полноценный HTML при первом обращении — без задержек рендеринга. Это особенно важно для коммерческих сайтов, новостных порталов и любых ресурсов, зависящих от органического трафика.

SSR в современных фреймворках

Большинство современных метафреймворков поддерживают SSR из коробки:

• Next.js — SSR через функции getServerSideProps (Pages Router) или серверные компоненты (App Router).
• Nuxt — SSR для Vue с универсальным рендерингом (можно переключаться между SSR, SSG и SPA).
• SvelteKit — SSR из коробки с поддержкой нескольких адаптеров деплоя.
• Remix — SSR-first фреймворк на React, ориентированный на Web-стандарты и прогрессивное улучшение.
• Angular Universal — SSR для Angular-приложений.

Streaming SSR и React Server Components

Традиционный SSR блокирует ответ до полной генерации HTML. Streaming SSR (доступен в React 18) отправляет HTML потоком по мере готовности отдельных частей страницы. Браузер начинает рендерить первые секции, пока сервер ещё генерирует остальные. Компоненты, обёрнутые в Suspense, передаются асинхронно — сначала показывается skeleton, затем заменяется реальным содержимым.

React Server Components (RSC) идут дальше: компоненты выполняются только на сервере, не отправляют JavaScript клиенту и могут напрямую обращаться к базам данных. Это принципиально новая парадигма, совмещающая преимущества SSR с уменьшением клиентского бандла.

Компромиссы и когда выбирать SSR

SSR добавляет серверную нагрузку (каждый запрос требует рендеринга) и усложняет деплой (нужен Node.js-сервер, а не просто CDN). Время до первого байта (TTFB) может быть выше, если сервер медленно генерирует HTML. Для страниц с редко меняющимся контентом предпочтительна статическая генерация (SSG). SSR оптимален для страниц с персонализированным, часто обновляемым или зависящим от запроса содержимым: ленты новостей, корзина магазина, профиль пользователя.