Страница уже видна, а кнопка ещё не работает. Или сервер отвечает долго, хотя разработчики перенесли на него весь рендеринг. Такие ситуации показывают, почему выбирать архитектуру только по аббревиатуре неудобно. В Гуси-Лебеди мы предлагаем начинать с другого: какие данные нужны посетителю сразу, как часто они меняются и когда интерфейс должен стать готовым к действию.
Разберём, что такое серверный рендеринг, чем SSR отличается от CSR и SSG, где он полезен и что проверять при внедрении. Это поможет обсуждать решение с командой без обещаний, что смена технологии сама исправит скорость и продвижение.
Чем SSR отличается от CSR и SSG
SSR, Server-Side Rendering, означает подготовку HTML на сервере. Браузер получает разметку страницы, а затем может подключить клиентский JavaScript для взаимодействий. При CSR основную работу по построению интерфейса выполняет браузер. При SSG HTML заранее генерируется во время сборки.
| Режим | Когда готовится HTML | Что учитывать |
|---|---|---|
| CSR | В браузере после загрузки приложения и нужных данных | Первое открытие зависит от клиентского кода и запросов |
| SSR | На сервере при обработке запроса | Время ответа зависит от подготовки данных и разметки |
| SSG | Заранее при сборке | Для изменения подготовленного содержимого нужен процесс обновления |
Для приложения с серверным HTML обычно нужна гидратация: клиентский код связывает существующую разметку с интерактивной логикой. Поэтому появление текста и готовность фильтра или формы могут происходить в разное время. Определения и устройство SSR описаны в документации Vue.
Режим рендеринга не определяет весь характер сайта. Серверная страница может иметь сложный интерактивный интерфейс, а клиентское приложение может быстро работать после загрузки. Оценивать нужно конкретный путь посетителя: открытие ссылки, чтение, выбор параметров и отправку формы.
Как выбрать рендеринг для разных страниц
Необязательно переводить весь проект на один режим. Сначала разделите страницы по содержанию, частоте изменений и доступу. Затем выясните, какая часть страницы общая, а какая зависит от пользователя. Для обсуждения архитектуры полезно составить короткую карту разделов с этими признаками.
- Статья или справочник. Если материал меняется через публикацию редактора, можно рассматривать предварительную генерацию. Сразу согласуйте, как исправление попадёт на публичную страницу.
- Каталог и карточка товара. Разделите описание, цену, остаток и персональную скидку. У них могут быть разные требования к актуальности и кешированию.
- Личный кабинет. Главное здесь: проверка доступа, изоляция данных и работоспособность действий. Открытая индексация закрытого содержимого не является целью.
- Интерактивный сервис. Определите полезное начальное состояние и данные, которые можно запросить после первого отображения.
Уточните допустимую задержку обновления каждого блока. Формулировка «всё должно быть свежим» слишком расплывчата для приёмки. Например, изменение редакционной статьи и изменение доступности товара требуют разных правил. Это проектное решение, которое нужно записать до разработки.
При разработке сайта на Next.js или создании проекта на Nuxt.js обсуждайте режимы на уровне маршрутов. Возможности и настройки кеша проверяйте для конкретной версии фреймворка. Общая статья не заменяет такую проверку.
Почему SSR может отвечать медленно
Перенос запросов на сервер не сокращает их автоматически. Если страница ждёт каталог, затем цены, затем рекомендации, последовательность ожиданий может сохраниться. Посетитель увидит готовый HTML только после выполнения необходимых операций.
Разберите зависимости: какой ответ нужен для заголовка и основного содержимого, какой для покупки, а какой только для дополнительного блока. Независимые запросы можно рассматривать для параллельного выполнения. Необязательный сервис не должен без обсуждения становиться условием показа всей страницы.
Для каждого внешнего источника предусмотрите тайм-аут и понятное состояние ошибки. Если недоступны рекомендации, страница товара может оставаться полезной. Если нельзя достоверно получить цену, нельзя незаметно подставить случайное или устаревшее значение. Поведение зависит от бизнес-правил, и его нужно проверить отдельно.
Сравнивайте время ответа сервера, появление основного содержимого и готовность взаимодействий. Разбор показателей Core Web Vitals помогает обсуждать пользовательскую скорость, но один показатель не объясняет всю цепочку задержек. Для причины нужны данные запросов и выполнения, а не только итоговая оценка.
Что проверять при гидратации
Первая разметка, которую ожидает клиент, должна соответствовать серверному HTML. В документации React о hydrateRoot несовпадения рассматриваются как ошибки, которые необходимо исправлять. Скрытие предупреждения не устраняет причину.
Проверьте значения, способные отличаться при двух выполнениях: время, случайные идентификаторы, локализованное форматирование и данные, обновившиеся между ответом и запуском клиента. Также проверьте корректность вложенности HTML и условные ветки, зависящие от окружения браузера.
Функции, которым нужны окно браузера или локальное хранилище, должны выполняться в подходящей клиентской части жизненного цикла. Не стоит получать два разных начальных интерфейса только потому, что один запуск происходит на сервере, а второй в браузере.
Приёмка включает действия: открыть меню, выбрать фильтр, изменить вариант товара, отправить тестовую форму. Отдельно проверьте первый вход по прямой ссылке и переход внутри приложения. Внешне одинаковые страницы могут проходить разные последовательности загрузки.
Как разделить общий кеш и персональные данные
Общий кеш полезен для содержимого, одинакового для посетителей. Но ответ с данными аккаунта нельзя распространять как публичную страницу. Составьте перечень персональных полей и определите, на каком этапе они появляются: в HTML, отдельном запросе или клиентском состоянии.
Отдельный риск серверного приложения: изменяемое состояние пользователя в общем объекте, который переживает обработку одного запроса. Его нельзя использовать как хранилище текущего аккаунта для всех посетителей. Изоляцию проверяют на уровне запроса и окружения выполнения.
Опишите ключ кеша, срок хранения, основания для сброса и поведение после обновления. Учитывайте язык, регион и другие параметры, если они меняют ответ. Не включайте персональные токены в доступные журналы и публичные адреса.
Практическая проверка: в тестовом окружении открыть два разных аккаунта в независимых сессиях, пройти одинаковые маршруты, обновить данные и выйти из системы. Проверять нужно и HTML, и последующие ответы. Удачный тест одного пользователя не подтверждает изоляцию всех сценариев.
Как проверить SEO и результат внедрения SSR
Серверный HTML облегчает доступ к содержимому, но не гарантирует позиции в поиске. Google описывает обработку JavaScript и необходимость корректных ссылок и HTTP-ответов в руководстве по JavaScript SEO. Проверяйте фактическую страницу и её ответ, а не только название технологии.
| Проверка | Что считать результатом |
|---|---|
| Прямое открытие страницы | Есть нужные заголовок, содержимое и рабочие ссылки |
| Отсутствующий адрес | Корректный HTTP-статус, а не пустая успешная страница |
| Метаданные | Title, description и canonical соответствуют адресу |
| Интерактивность | Основные действия работают после первого открытия |
| Обновление данных | Изменение появляется согласно согласованному правилу |
| Доступ | Персональные данные видит только соответствующая сессия |
Согласуйте канонические адреса страниц и сохраните рабочие URL при изменении архитектуры. Сравните исходный HTML и состояние после выполнения JavaScript: заголовок, ссылки и указания для робота не должны противоречить друг другу.
Замеры проводите в сопоставимых условиях: одинаковая страница и данные, фиксированное устройство и сеть, отдельно первый запрос и прогретый кеш. Сохраните результаты до изменения и после него. Один удачный запуск не доказывает устойчивое улучшение.
Мы предлагаем начинать с одного подходящего маршрута и заранее согласовать возврат к прежней реализации. Проверить скорость, содержимое и ошибки, затем расширять решение. Для SPA-приложения это позволяет оценить SSR на конкретном пользовательском сценарии и выбрать архитектуру по результату проверки.