SSR и поисковая оптимизация: продвигаем сайт в ТОПы выдачи

Начнем с того, какие вообще бывают типы рендеринга.

Client-side rendering

Этот тип рендеринга стал популярен с появлением и популяризацией SPA-приложений и соответствует привычному поведению таких приложений. Сервер отправляет клиенту статичную почти пустую HTML-страницу и js-файлы. И уже на стороне браузера происходит загрузка скриптов и стилей, получение данных, роутинг, и приложение рендерится.

Server-side rendering

Существует server-side rendering. В SSR клиенту отдаются уже готовые к рендеру HTML-страницы. В этом случае сервер берет на себя некоторую функцию браузера. Он заранее выполняет все необходимые запросы для получения данных, выполняет скрипты, сериализует DOM дерево в строку и отправляет клиенту. Дальше браузер загружает нужные js-файлы, инициализирует внутренний роутинг, загружает стили, медиа и т.д.

SSG ISR

Часто отдельно от SSR выделяют пререндеринг. Следует упомянуть SSG (static site generation) и ISR (incremental static regeneration).

SSG – технология, когда веб-страницы генерируются во время сборки и предоставляются в виде обычных html файлов.

ISR – гибридный подход, который сочетает в себе преимущества SSR и SSG, создаётся набор html страниц с каким-то временем жизни (инкрементом), а также есть механизм перегенерации этого набора при необходимости обновления времени жизни. Самый простой пример реализации ISR — это SSR + кэширование страниц на выходе. В запросе клиента и ответе сервера существенных различий от SSR нет, поэтому эти термины не всегда разделяют. Основное различие этих подходов заключается во времени отдачи страницы.

Преимущества CSR

• Понятен и привычен для разработки​. Не нужно задумываться о том, в каком виде отдавать клиенту файлы.
• Скорость отрисовки определяется клиентом (браузером).
• Полностью доступное BrowserAPI. Можно использовать все его возможности, не задумываясь о том, как будет происходить рендеринг страницы на сервере, где browserapi просто нет.
• Минимальная нагрузка на сервер при первоначальной загрузке сайта​ 

Недостатки

• Проблемы с SEO. Для SEO важны множество различных данных и показателей на странице.
• С ростом приложения растет и количество требуемого и загружаемого JS. Поэтому для больших приложений нужно тщательно продумывать как корректно разбивать js файлы для загрузки.

SSR

Давайте теперь разберем преимущества и проблемы SSR.

Проблемы

• Невероятная нагрузка на сервер. В SSR сервер должен выполнять рендеринг и обработку каждого запроса. В случае высоких нагрузок (например, при обращении большого количества пользователей) это может повлиять на ухудшение производительность сервера, временным задержкам в отображении страниц и требовать дополнительных ресурсов для обработки запросов.
• Усложнение инфраструктуры. Появляется дополнительный сервер для SSR, соответственно и дополнительная точка отказа.
• Производительность коробочных решений и решений под фреймворки. Суть этих решений состоит в том, чтобы преобразовать DOM- дерево в строку. Они используют серверный NodeJs, производительность которого намного ниже, чем у других стандартных серверных языков.
• Возникают дополнительные требования к клиентскому коду. Есть необходимость использования полифиллов. Например, тот же самый browser API на сервере не существует. Нужно следить за тем, какой код должен исполняться на сервере, а какой на клиенте.
• Возникает проблема настройки регидратации. Быстро упомяну, регидратация – это повторный рендеринг, который производится на клиенте. Сервер отрендерил содержимое страницы, сразу после этого клиентский JS начинает выполнение по созданию полноценного клиентского приложения. В этот момент может возникать проблема мерцания, когда уже отрендеренная страница снова обновляется. Сложность здесь возникает в том, что регидратация уникальна для каждого сайта. Универсальных решений нет. Для каждого фреймворка создаются свои варианты.

Преимущества

• Ускорение первичной отрисовки. Довольно важный пункт, который влияет на SEO. Но если одна из задач сайта, это достичь минимального времени первичной отрисовки, то существуют библиотеки/фреймворки, которые как раз специализируются на этом (например, SOLID, Qwik)
• Упрощение индексации страницы поисковыми ботами, т.е. улучшение SEO. И действительно, SSR является единственным вариантом гарантированно сделать оптимизацию SEO. Так как большинство поисковых ботов работают с уже готовым html файлом.
• Отображение на устаревших браузерах. Самый странный плюс SSR.
• При должной настройке регидратации можно уменьшать количество выполняемого JS кода на клиенте, повышать производительность и для TTI (Time to Interactive).
• Немного притянутый плюс – улучшение безопасности за счет уменьшения уязвимостей к XSS атакам. Идея в том, что загружается HTML на сервере и все запросы для получения данных происходят так же на сервере. И на клиенте нет возможности подменить адрес на другой. Но XSS атаки со временем становятся серьезнее и сложнее, и это сказывается на безопасности сайта. К тому же как уже говорилось, что сервер – дополнительная точка отказа, и возникает огромная проблема с DDOS-атаками.
• То есть самыми значимыми здесь являются первое и второе преимущество. И перед тем, как браться за SSR стоит оценить и понять, стоят ли эти преимущества тех проблем, которые могут возникнуть и которые придется решить.

Теперь давайте немного поговорим о SEO - главной причине, по которой стоит задумываться о SSR. 

SEO – оптимизация под поисковые движки, комплекс мер, направленный на улучшение позиций сайта в поисковой выдаче. Поисковая выдача зачастую является основным источником актуального целевого трафика. По статистике, собранной Google, на вторую страницу в поиске переходит менее 1% пользователей. Первая тройка результатов поиска получает около 52% всех откликов. Поэтому важно оставаться как можно выше в поиске. Но сложность и многообразие факторов, влияющих на ранжирование сайта, делают SEO далеко нетривиальной задачей. Существуют отдельные SEO специалисты, которые следят за поисковой выдачей, определяют качество SEO и формулируют конкретные задачи по улучшению ранжирования сайта. Задачи могут быть как для разработки, так и для DevOps, менеджмента и PR’а.

Как работают поисковые боты

Рассмотрим на примере Google поиска.Google поиск работает в 3 стадии:

1. Crawling (краулинг) – Google скачивает текст, картинки, видео со страниц, которые он нашел в интернете, с помощью программ, которые называются краулеры (роботы, боты или пауки)
2. Индексация – анализ текста, картинок, видео на страницы и сохранение информации в Google Index (большая БД)
3. Представление результатов поиска

Немного подробнее про каждую стадию.

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

Таким образом формируется очередь для обхода страниц. Когда Google-бот загружает URL из очереди с помощью HTTP запроса, он в первую очередь смотрит, разрешена ли страница вообще для обхода. Google-бот читает robots.txt файл. Если страница отмечена как неразрешенная, то запрос до нее прерывается, и ссылка пропускается. Затем Google-бот парсит ответ на наличие атрибута href у ссылок и добавляет новые ссылки в очередь для обхода.

Далее Googlе-бот кладет все страницы в очередь для рендеринга, если страница не запрещена для индексации посредством robots meta tag или header. Headless Chrome рендерит страницу и исполняет JS-код. Google-бот еще раз парсит страницу на наличие ссылок и кладет их в очередь для обхода. И затем уже отрендеренная страница используется для индексации. Специальные алгоритмы пытаются понять, о чем эта страница. Это стадия индексации, она включает в себя обработку и анализ текстового контента и ключевых тегов и атрибутов.

Собранная информация может быть сохранена в Google Index (большая БД).

- Представление результатов поиска 

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

Что влияет на выдачу в поиске?

• Уникальность контента и частота его обновления​
• Качество и количество внешних ссылок​
• Время, проводимое пользователями на сайте, и глубина просмотра​
• Техническое состояние: скорость открытия страниц, ошибки, битые ссылки​
• Корректность разметки и метатегов(title, description, h1, микроразметка) ​
• Открытость сайта для индексации, наличие sitemap​
• Возможность что-то купить или заказать на сайте​
• CTR- кликабельность карточки в выдаче

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

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

У других поисковым систем даже нет идей создавать такой функционал, к сожалению. И до тех пор, пока существует значимая метрика для SEO – скорость отдачи сайта, нужно будет задумываться о SSR. Таким образом, хочешь хорошее SEO – делай SSR.Перейдем к возможным решениям реализации.

Angular Universal и Angular SSR

Рассмотрим решения в контексте Angular. Если вы используете Angular до 16 версии включительно, то можно использовать Angular Universal. С 17 версии и выше рекомендуется использовать Angular SSR. Он привязывается к внутреннему потоку событий applicationRef.isStable, связанному с состоянием очередей микро- и макротасок.

Официальный гайд предлагает использовать медленный express.js для сервера.  Производительность скалируется только путем увеличения количества подов, а требования к памяти существенные.

Проблема регидратации у Angular была на протяжении нескольких лет, и в 16 версии вышло демо решение, а в 17 оно значительно улучшилось.

Аngular Universal активно поддерживался командой, напрямую связанной с основной командой разработки Angular. А теперь уже и сама команда Angular поддерживает пакет SSR. И это является огромным плюсом.

Возьмем в пример React. Сам React и его дополнения делают разные команды, которые не всегда между с собой взаимодействуют. Это приводит к ситуации, когда при обновлении React зависимые плагины становятся deprecated и нужно ждать, когда другие команды обновят версии своих проектов.

Также в последних версиях Angular появилась возможность SSG, но пока попробовать это не было возможности. В конфигурационном файле приложения можно включить специальную опцию "prerender”, которая будет генерировать html-страницы для всех роутов или отдельных, которые можно передать в списке в виде файла.