Современные интерфейсы часто собираются прямо в браузере: сервер отдаёт почти пустой документ, а содержимое подгружает скрипт. Для сложных приложений это удобно, для сайтов, которым нужен поисковый трафик, — рискованно. Ниже разбираем три способа получить страницу, их сильные и слабые стороны и то, как мы выбираем схему на практике.
Три подхода к сборке страницы
Различие между ними сводится к одному вопросу: в какой момент появляется готовая разметка — на сервере, в браузере посетителя или ещё на этапе сборки проекта.
| Подход | Как работает | Кому подходит |
|---|---|---|
| Рендеринг на сервере | Сервер собирает HTML на каждый запрос и отдаёт готовый документ | Каталоги, карточки товаров, блоги, страницы услуг |
| Рендеринг в браузере | Приходит пустой каркас, содержимое подставляет скрипт после загрузки | Личные кабинеты, панели управления, внутренние сервисы |
| Заранее собранные страницы | HTML генерируется один раз при сборке проекта и лежит файлами | Документация, лендинги, материалы, которые меняются редко |
| Смешанная схема | Публичная часть с сервера, закрытый раздел собирается в браузере | Большинство коммерческих проектов |
Чистые варианты встречаются реже, чем смешанные. Обычно у проекта есть витрина, которая обязана быть в поиске, и закрытая часть, куда робот не попадёт при всём желании, — разумно применять к ним разные подходы.
Почему это важно для поиска
Поисковые роботы умеют выполнять скрипты, но делают это в отдельной очереди и не всегда полностью. Если текст, цена и заголовок появляются на странице только после выполнения кода, обход растягивается: сначала робот забирает документ, потом ставит его в очередь на отрисовку, и только затем в индекс попадает содержимое. На сайте из десятка страниц разница почти незаметна, на каталоге из нескольких тысяч — уже ощутима.
Отдельная проблема — ошибки при выполнении. Скрипт может не дождаться ответа от внешнего сервиса, упасть на неподдерживаемой конструкции, зависеть от параметров, которых у робота нет. Человек в такой ситуации перезагрузит страницу, робот просто зафиксирует пустой документ. Мы регулярно видим это на проектах, которые пришли к нам с жалобой «страницы есть, а в поиске их нет»: в инструменте проверки адреса содержимое отсутствует, хотя в браузере всё на месте.
Проверить это можно без специальных инструментов. Достаточно запросить страницу утилитой командной строки или отключить выполнение скриптов в браузере: то, что осталось на экране, и есть минимум, на который может рассчитывать робот.
Что ещё даёт рендеринг на сервере
- Быстрый первый экран. Посетитель видит текст, пока скрипты ещё загружаются. На слабых телефонах и медленной сети разница исчисляется секундами.
- Корректные превью ссылок. Мессенджеры и социальные сети читают разметку без выполнения скриптов: если заголовка и картинки нет в исходном HTML, ссылка будет выглядеть пустой.
- Устойчивость. Если один из скриптов не загрузился, страница остаётся читаемой, а не превращается в белый экран.
- Доступность. Программы чтения с экрана и режимы экономии трафика работают с готовой разметкой предсказуемее.
- Кэшируемость. Готовый HTML можно положить в кэш и отдавать без обращения к базе.
Чем приходится платить
Серверный рендеринг — это не настройка, которую включают галочкой. Появляется постоянно работающий процесс приложения, который нужно запускать, перезапускать после падения, обновлять и мониторить. К обычному веб-серверу добавляется ещё один компонент, и у него есть свои требования к памяти и процессору: каждая страница теперь собирается на вашей стороне, а не на устройстве посетителя.
Второй источник сложности — дублирование логики. Один и тот же код выполняется и на сервере, и в браузере, и различия между этими средами регулярно приводят к ошибкам: на сервере нет объекта окна, нет размеров экрана, нет данных из локального хранилища. Третий — рассинхронизация: если разметка, собранная сервером, не совпадает с тем, что ожидает получить скрипт, происходит повторная сборка страницы, и выигрыш в скорости теряется.
Наконец, кэширование. Отдавать всем один и тот же HTML быстро и дёшево, но как только на странице появляется имя пользователя, содержимое корзины или региональная цена, схему кэша приходится усложнять.
Как мы выбираем подход на проекте
- Разделяем страницы на публичные и закрытые. Всё, что должно приводить людей из поиска, получает готовую разметку с сервера.
- Смотрим на частоту изменений. Если содержимое обновляется раз в неделю, заранее собранные страницы дешевле и надёжнее серверного рендеринга.
- Оцениваем нагрузку. Сотни страниц с редкими изменениями и высокая посещаемость — повод собирать заранее и раздавать статикой.
- Проверяем, есть ли персонализация. Если на странице разное содержимое для разных посетителей, планируем схему кэша до начала разработки, а не после.
- Считаем сопровождение. Дополнительный серверный процесс требует мониторинга и автоматического перезапуска: если этого не предусмотреть, любое падение превращается в недоступный сайт.
Типичные ошибки
- Серверный рендеринг ради галочки. Внутренний кабинет, куда заходят по паролю, не нуждается в индексации — сложность добавили, пользы не получили.
- Готовая разметка есть, а мета-теги подставляет скрипт. Робот видит один и тот же заголовок на всех страницах: типичная причина, по которой каталог не растёт в выдаче.
- Нет запасного плана при падении. Процесс приложения упал, и сайт отдаёт ошибку целиком, хотя мог бы показать закэшированную версию.
- Разные версии на сервере и в браузере. Сборка обновилась только с одной стороны, и страница пересобирается заново с миганием содержимого.
- Тяжёлый первый экран. Разметка приходит сразу, но вместе с ней прилетает несколько мегабайт скриптов, и страница всё равно долго не отвечает на нажатия.
Как проверить, что всё работает
После запуска мы проходим короткий чек-лист. Запрашиваем несколько типовых страниц без выполнения скриптов и убеждаемся, что в ответе есть заголовок, текст, цена и ссылки. Проверяем, что у каждой страницы свои мета-теги и канонический адрес. Смотрим коды ответа: карточка удалённого товара должна отдавать 404, а не двухсотый код с пустым макетом. Прогоняем страницы через инструменты проверки в панелях поисковых систем и сравниваем, что видит робот, с тем, что видим мы. Отдельно замеряем время до первого содержимого и время до готовности к нажатиям — они различаются, и второе часто оказывается хуже.
Практический вывод
Если страница должна приводить людей из поиска, содержимое обязано быть в разметке сразу: либо серверный рендеринг, либо заранее собранные страницы. Если речь о разделе после входа в аккаунт, сборка в браузере проще и дешевле в сопровождении. Смешанная схема, где витрина отдаётся сервером, а кабинет собирается на клиенте, покрывает большинство реальных задач и обходится без лишних расходов на инфраструктуру.
Нужна помощь
Мы проектируем и собираем сайты так, чтобы содержимое было доступно и людям, и поисковым роботам с первого запроса. Если у вас есть проект на скриптовом фреймворке, который плохо индексируется, посмотрим, что видит робот, и предложим схему рендеринга под ваш случай. Обсудить создание сайта можно с оценкой сроков и объёма работ.
