SSR (серверный рендеринг)

Руководство Vue описывает именно такую последовательность: сервер формирует HTML, отправляет его браузеру, затем клиентский код может сделать приложение интерактивным. ^[7]

Кратко

Готовый текст страницы и работающая кнопка — разные результаты, которые проверяют отдельно. ^[2]
SSR отличается от статической генерации моментом подготовки страницы. ^[4]
Гидратация связывает полученную разметку с программным поведением приложения. ^[7]
Доступность содержания поисковому роботу ещё не означает включения страницы в индекс. ^[1]

Происхождение и история

Серверная подготовка ответа существовала задолго до современных библиотек интерфейса. Документ RFC 3875, опубликованный в октябре 2004 года, описывает CGI (Common Gateway Interface — общий шлюзовой интерфейс), использовавшийся в вебе с 1993 года. Сервер передавал запрос программе; она выполняла прикладную работу, включая доступ к данным и обработку документов. Так содержание ответа могло зависеть от запроса, а не только от заранее сохранённого файла. ^[6]

Это ранний этап развития серверного формирования страниц, а не установленная дата появления сокращения SSR. Позднее существенным стал выбор между подготовкой страницы сервером и построением интерфейса браузерным кодом. Обзор web.dev, впервые опубликованный 6 февраля 2019 года и обновлённый 5 января 2026 года, систематизирует серверный, клиентский и статический подходы. ^[4] В современной документации React сервер может преобразовать компоненты — программные части интерфейса — в HTML, после чего приложение продолжает работу в браузере. ^[2]

Суть и механизм

Представим учебный пример: читатель открывает новость «В городе открылся музей». Сервер получает запрос страницы, извлекает заголовок и текст, подставляет их в шаблон и отправляет разметку. Такая последовательность соответствует серверному формированию ответа; конкретный способ получения данных зависит от приложения. ^{[2, 6]}

Браузер разбирает разметку и строит DOM (Document Object Model — объектную модель документа): дерево элементов страницы в памяти. Заголовок становится одним элементом, абзац — другим. Программы могут читать это дерево и изменять его содержимое. Поэтому исходный ответ сервера и DOM после выполнения JavaScript, языка программирования веб-страниц, могут различаться. ^[8]

Для кнопки «Показать комментарии» одного изображения кнопки недостаточно. Нужен обработчик события — функция, запускаемая при нажатии. В приложении React гидратация подключает программное поведение к HTML, созданному сервером. Учебная кнопка может уже отображаться, пока её обработчик ещё не подключён; наличие текста новости не доказывает готовности комментариев. ^[2]

Функция React renderToString возвращает HTML одной строкой. Она не поддерживает потоковую выдачу и ожидание данных; документация предлагает другие функции для этих задач. ^[2] Это ограничение конкретного средства, а не серверного рендеринга вообще.

Виды и соседние понятия

По терминологии web.dev место выполнения и момент подготовки страницы помогают различить основные подходы. ^[4] Потоковая передача и гидратация описывают другие стороны работы, поэтому их нельзя считать взаимоисключающими вариантами SSR. ^{[2, 7]}

Понятие	Что происходит
SSR	Сервер готовит HTML при обработке запроса. ^[4]
CSR, Client-side rendering — клиентский рендеринг	JavaScript строит представление в браузере. ^[4]
SSG, Static Site Generation — статическая генерация сайта	HTML создаётся заранее при сборке и выдаётся как готовый файл. ^[7]
Потоковый SSR	Части HTML отправляются по мере готовности; не обязательно ждать окончания всей работы. ^[4]
Гидратация	Клиентский код подключает поведение к уже полученной разметке. ^[7]

Серверные компоненты React, или RSC (React Server Components), — ещё одно отдельное понятие. В Next.js они формируют специальный набор данных, который используется вместе с клиентскими компонентами для подготовки HTML. При первой загрузке HTML показывает начальное представление, а JavaScript делает клиентские компоненты интерактивными. При последующих переходах внутри приложения механизм отличается: клиентские компоненты могут отрисовываться уже в браузере. ^[3] Поэтому название компонента само по себе не описывает всю доставку страницы.

Как применяется на практике

Для учебного новостного сайта разумно разделить задачи: текст и ссылки должны быть доступны сразу, комментарии могут появиться после запуска клиентского кода. Это пример проектного решения, а не требование к каждому сайту. Команде следует заранее назвать содержание, которое она ожидает увидеть в серверном ответе, и действия, которые должны работать после загрузки.

В поисковой оптимизации, или SEO (Search Engine Optimization), важно различать получение страницы роботом, выполнение её кода и индексирование содержания. Google описывает эти три этапа отдельно; если исходный ответ содержит только оболочку приложения, содержимое становится доступным после выполнения JavaScript. ^[1]

В российском контексте справка Яндекса также не требует считать любой JavaScript-сайт невидимым: при обработке сайтов с загрузкой содержания через JavaScript робот посещает исходные адреса и выполняет код. ^[5] Поэтому проверять нужно фактически доступную страницу, а не одно название её архитектуры.

Как измерить или проверить

Редакция предлагает проверку в три прохода. Сначала открыть страницу напрямую и сохранить исходный ответ сервера. Для учебной новости искать точную фразу «В городе открылся музей», её заголовок и основную ссылку. Затем сравнить ответ с DOM после загрузки: если фраза появилась только там, браузер получил или построил её позднее. Основа такого сравнения — возможность программно изменять DOM. ^[8]

Третий проход проверяет действие: открыть комментарии, заполнить форму, получить предусмотренный результат. Показ кнопки и успешное нажатие фиксируют раздельно. Для приложений вроде Next.js стоит повторить сценарий после прямого открытия адреса и после перехода с другой страницы: документация различает эти режимы. ^[3]

Учебный пример измерения: текст появился через 0,8 секунды после начала загрузки, а кнопка заработала через 1,9 секунды. Разрыв составляет 1,1 секунды. Это два наблюдения одного сценария; их нельзя превращать в утверждение, что вся страница «загрузилась за 0,8 секунды». Числа придуманы для объяснения, а не взяты из измерений сайта.

Для скорости полезен TTFB (Time to First Byte) — время до получения первого байта ответа. Подготовка HTML на сервере может увеличить это ожидание, даже если содержание затем появится раньше. ^[4] При сравнении редакция предлагает повторять один сценарий при одинаковых условиях сети и нагрузки, отдельно отмечая использование кэша — сохранённого результата предыдущей работы.

Ошибки, ограничения и спорные вопросы

Гидратация требует клиентских вычислений: раннее появление разметки не означает, что браузер закончил работу и страница готова отвечать на действия. ^[4]

SSR переносит часть вычислений на сервер и предъявляет дополнительные требования к развёртыванию. Руководство Vue предупреждает о нагрузке и несовместимости некоторых браузерных возможностей с серверным выполнением. Оно также описывает ошибки гидратации, когда ожидаемое клиентом представление не совпадает с полученным, например из-за разных случайных значений. ^[7]

Серверная разметка не исправляет автоматически отсутствующие страницы. Google рекомендует содержательные коды ответа, например 404 для ненайденной страницы. ^[1] Поэтому приёмка должна охватывать и ошибочные адреса. Улучшение доступности содержания также не следует выдавать за обещание позиции в поиске: описанный механизм объясняет обработку страницы, а не гарантированный результат продвижения. ^[1]

Частые вопросы

SSR и статическая генерация — одно?

Нет. В базовой модели SSR готовит ответ по запросу, а статическая генерация создаёт HTML заранее. ^{[4, 7]}

При SSR не нужен JavaScript?

Он может понадобиться для поведения приложения. Серверный HTML и клиентская интерактивность выполняют разные задачи. ^[2]

Server Components — другое название SSR?

Нет. В Next.js серверные компоненты участвуют в подготовке данных для интерфейса; формирование HTML — отдельный этап. ^[3]

SSR гарантирует индексацию?

Нет. Получение HTML, выполнение кода и включение содержания в индекс — отдельные этапы обработки. ^[1]

Решить с помощью сервиса

SEO-проверка — внутренний инструмент, который готовится к открытию для внешних пользователей. Он проверяет технические параметры одной страницы, метатеги и скорость с помощью PageSpeed/Lighthouse. Эти сведения помогают оценивать страницу после изменения способа рендеринга.

Сервисы MEDIATRONE →

Связанные термины

Источники

Google. (n.d.). Understand the JavaScript SEO basics. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics (дата обращения: 30.10.2026). ↑ а б в г д
React. (n.d.). renderToString. API reference. https://react.dev/reference/react-dom/server/renderToString (дата обращения: 30.10.2026). ↑ а б в г д е ж
Next.js. (n.d.). Server and Client Components. App Router documentation. https://nextjs.org/docs/app/getting-started/server-and-client-components (дата обращения: 30.10.2026). ↑ а б в
Osmani, A., & Miller, J. (2026, January 5). Rendering on the web. web.dev. Первоначальная публикация 6 февраля 2019 года. https://web.dev/articles/rendering-on-the-web (дата обращения: 30.10.2026). ↑ а б в г д е ж з и
Яндекс. Индексирование AJAX-сайтов // Справка Вебмастера. URL: https://yandex.ru/support/webmaster/ru/robot-workings/ajax-indexing (дата обращения: 30.10.2026). ↑
Robinson, D., & Coar, K. (2004, October). The Common Gateway Interface (CGI) Version 1.1 (RFC 3875). RFC Editor. https://www.rfc-editor.org/rfc/rfc3875 (дата обращения: 30.10.2026). Исторический документ категории Informational, не Internet Standard. ↑ а б
Vue.js. (n.d.). Server-side rendering (SSR). Guide. https://vuejs.org/guide/scaling-up/ssr.html (дата обращения: 30.10.2026). ↑ а б в г д е ж
MDN contributors. (n.d.). Document Object Model (DOM). MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model (дата обращения: 30.10.2026). ↑ а б