Привет, Хабр! Все знают что для того, чтобы ваш сайт увидели поисковые роботы вам нужен SSR. Но единственное ли это решение? Всегда ли он нужен? Есть ли другие варианты роботам увидеть контент? Что мы можем выиграть от альтернатив?

В этой статье рассмотрим альтернативное решение для SSR, а именно Динамический рендеринг (он же Пререндеринг).

* SSR имеется ввиду с регидрацией.

Какую проблему мы решаем?

Есть два способа генерации контента веб сайта:

• Серверный - генерируется программой на стороне сервера. Для генерации такого контента на стороне сервера должна работать ваша программа.

• Клиентский - генерируется скриптом на стороне браузера. Для генерации такого контента на стороне сервера программа не нужна, достаточно сервера статики.

На самом деле есть еще 4 смешанных варианта, но о них позже.

Оба метода имеют свои плюсы и минусы. Большой минус серверного рендеринга заключается в том что веб сайт получается "не живой". В нем мало интерактивных элементов, переход по страницам крайне неприятен и занимает много времени. Но такой контент видят поисковые роботы. Большой минус клиентского рендеринга это отсутствие видимости для роботов. Роботы такой контент просто не видят. Только недавно Гугл и Яндекс научились видеть такой контент, но скорость такой индексации оставляет желать лучшего. Но зато такой веб сайт "живой". В нем много интерактивных элементов и переходы по страницам мгновенны для пользователя.

SSR является компромиссным вариантом и объединяет в себе подходы серверного и клиентского рендеринга. Он с начало рендерит страницу на сервере, потом оживляет ее при рендеринге на клиенте. Таким образом поисковые роботы видят контент, а клиенты получают живой и интерактивный сайт.

Но помимо плюсов у данного подхода есть и минусы. И далее мы сравним плюсы и минусы подходов Пререндеринга и SSR.

Что такое Пререндеринг?

Если SSR является компромиссным вариантом выдающий одинаковый результат для пользователей и роботов, то пререндеринг это бескомпромиссный вариант. Который позволяет выдать роботам и клиентам лучшее решение независимо друг от друга. Роботы получают контент для индексации при помощи серверного рендеринга, а клиенты живой сайт при помощи клиентского рендеринга.

Для пререндера вам понадобится вспомогательная программа работающая на стороне сервера независимо от вашего веб сайта. На стороне прокси сервера вашего сайта делается настройка, которая разделяет пути следования клиентов и поисковых роботов. Клиентам отдается статичный сайт с клиентским рендерингом. Роботы отправляются на программу пререндеринга. Программа пререндеринга открывает сайт, дожидается его загрузки и отправляет результат открытого сайта поисковому роботу. Фактически это то же самое чем занимаются пререндеры поисковых роботов, только мы это реализуем на своей стороне, чтобы помочь роботам лучше индексировать контент своего сайта.

Детальнее про пререндеринг можно почитать в документации гугла. Я для обзора буду рассматривать микросервис пререндеринга от компании МТС который называется BotView. Так же есть сервис prerender.io который предоставляет услуги пререндеринга и открытый контейнер для пререндеринга. Но его мы рассматривать не будем так как он менее стабильный, менее быстрый и менее функциональный чем BotView.

Как настроить пререндер?

Чтобы настроить пререндер, необходимо сделать два простых шага. Во-первых, запустить контейнер с микросервисом пререндеринга.

docker run -d --restart always -p 3000:3000 mtsrus/botview

Во-вторых, на прокси сервере необходимо настроить разделение путей для реальных клиентов и поисковых роботов. Чтобы реальным клиентам отдавались статичные файлы, а поисковые роботы перенаправлялись на пререндер.

location / {

    set $prerender 0;

    # all popular bots
    if ($http_user_agent ~* "googlebot|facebookexternalhit|twitterbot|telegrambot|yahoo|bingbot|baiduspider|yandex|yeti|yodaobot|gigabot|ia_archiver|developers\.google\.com") {
        set $prerender 1;
    }

    # bot with escape fragments
    if ($args ~ "_escaped_fragment_") {
        set $prerender 1;
    }

    # prerender microservice
    if ($http_user_agent ~ "Prerender") {
        set $prerender 0;
    }

    # static files
    if ($uri ~ \.[a-zA-Z0-9]+$) {
        set $prerender 0;
    }

    if ($prerender = 1) {
        rewrite (.*) /render/$scheme://$host$1?prerender break;
        proxy_pass http://localhost:3000;
    }

    if ($prerender = 0) {
        proxy_pass http://localhost:8080;
    }
}

Теперь клиенты будут получать клиентский код, а роботы необходимую им информацию. Кроме того в пререндере можно настроить возвращение статус кодов 300 и 400 для их корректной обработки поисковыми роботами.

Как будем сравнивать?

Для сравнения возьмем две популярные технологии разработки сайтов. Сайт реализованный как статичные файлы и сайт реализованный на Next.js с SSR. И пройдемся по наиболее интересным вопросам использования.

Стоимость хостинга

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

Когда вы хостите сайт как программу с SSR, то на сервере вам понадобится много ресурсов для вашей программы. Потому что теперь для рендеринга сайта будут использоваться серверные ресурсы и много. Понадобится много процессора, много памяти, много сети. Кроме того вырастет нагрузка на сеть, ведь отрендереную серверную страницу нельзя кэшировать. Но самое забавное, что клиент все равно будет рендерить, то же самое. Переложив рендеринг на сервер вы не на чем не сэкономили, вы лишь заплатили за поддержку поисковых роботов.

В моей практике был случай когда я реализовал программу, выполненную как статичный клиентский код и эта программа потребляла в 30 раз меньше серверных ресурсов чем похожая серверная программа.

Но на самом деле у SSR тоже есть козыри. Например, если брать фреймворк Next.js то он может работать не только как SSR решение, но и как SSG, и как SSG + SSR решение. Таким образом страницы могут генерироваться как статичные на этапе сборки или в рантайме по интервалу с новыми данными. Таким образом фреймворк позволяет снизить нагрузку на сервер и клиентам выдавать кэшированные данные.

Но за пререндер на сервере тоже надо платить? Да. Но робот приходит на страницу 1 раз в 2 недели. Это гораздо меньше чем обычно клиентов приходят на вашу страницу.

Победитель: Пререндер.

Надежность

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

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

Победитель: Пререндер.

Стоимость разработки

Когда вы разрабатываете для SSR вам необходимо разрабатывать сразу под две платформы Браузер и NodeJS. Эти платформы имеют разное API. В частности на стороне NodeJS отсутствуют такие объекты как window, location, screen и многие другие. Из-за чего часто приходиться выкручиваться создавая логику без использования этих объектов или вовсе оставляя заглушку для обработки на стороне клиента. Например частенько при разработке под SSR нужно знать размер экрана пользователя, но вы его никак не можете знать на стороне сервера, поэтому вы рендерите заглушку, потом код передается на клиент где уже происходит более полноценный расчет логики и перерендеринг уже с реальными данными. Все эти нюансы увеличивают стоимость разработки.

Когда вы разрабатываете под Пререндер вы разрабатываете только под браузер. Где есть все необходимое для написания логики.

Победитель: Пререндер.

Поддержка технологий

Когда вы используете SSR вы сильно ограничены в используемых технологиях. Next.js только два месяца назад научился безболезненно работать с динамическими данными. В других фреймворках работать с динамическими данными все еще проблемно или невозможно вовсе. На стороне SSR вы не можете использовать множество браузерных фич, таких как Веб компоненты, Микрофронтенды, Фреймворки и пр.

Пререндеринг выполняется в полноценном браузере, поэтому вам доступны все те технологии которые есть браузере без ограничений. Вы не ограничены в библиотеках и фреймворках. Вы можете использовать его для чего угодно, включая JQuery, AngularJS, Angular, Vue, SolidJS и др.

Победитель: Пререндер.

Хайп и комьюнити

SSR в настоящий момент является основным и рекомендуемым Гуглом. По данному подходу можно найти огромное количество статей и документации. Все современные фреймворки обладают функцией рендеринга через SSR.

Пререндер удел интузиастов. Он перестал быть основным инструментом поставки контента поисковым роботам, так же перестал быть рекомендованным инструментом Гугл.

Победитель: SSR.

Функциональность

Когда вы разрабатываете с SSR вам приходиться хостить на сервере программу. При таком подходе у вас появляется возможность разместить в программе не только клиентский код, но и API, и код бекенда. Таким образом вы можете принимать запросы от клиента, делать рассылки и исполнять любую необходимую бизнес логику. Фактически вы превращаетесь в фуллстек разработчика.

Когда вы хостите сайт как набор статичных файлов, то кроме отображения статичных файлов в браузере вы не можете делать ничего.

Победитель: SSR.

Какое из решений является костылем?

Оба. Единственная задача для которой они существуют это сделать контент видимым для поисковых роботов, реальным клиентам они не нужны. Если ваш контент не должны индексировать роботы, то вы можете не использовать эти решения совсем.

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

Что выбрать вам?

Решать вам. Я выбираю в зависимости от задачи проекта.

Свои личные проекты я реализую как статичные сайты с пререндером. Потому что так стоимость хостинга значительно ниже и не надо заморачиваться с надежностью.

На работе решение выбирается в зависимости от задачи. Где то это статика с пререндером, где то это фулстек проект на Next.js. Но в подавляющем большинстве это все же Next.js с SSG + SSR.

С другой стороны если ваш фреймворк не поддерживает SSR, например это JQuery или старый Angular, то Пререндер это ваш единственный вариант, при котором контент будет доступен поисковым роботам.