Наши кодеры постоянно пробуют что-то новое — недавно тестили Flutter, например (если пропустили пост об этом, вам сюда). А в этот раз мы решили проверить, насколько жизнеспособна идея seo-френдли сайтов на Битриксе и React.js. Мы будем упрощать описание до безобразия, т.к. с точки зрения программирования здесь существует много нюансов и подходов, но полное их рассмотрение порвет мозг любому.

Классические сайты используют, в основном, серверный рендеринг компонентов в HTML. Есть ряд существенных оговорок, типа подгрузки части блоков по AJAX, или «композитные сайты», но в целом, можно считать, что контент отдается сервером прямо на страницу. В случае CMS Битрикс — обычно, с помощью компонентов. В случае с классическими фреймворками — View, ViewHelper и тому подобное. Короче, классически — сервер отдает контент в HTML-виде. Это нравится поисковикам.

Однако современные клиентские фреймворки, вроде React или Vue, предполагают отрисовку страниц на клиенте (то есть в браузере) с помощью JavaScript. Сам контент при этом передается в браузер не в HTML-формате, а, как правило, в JSON. Чего очень не любят и не понимают поисковики. А еще поисковики очень сильно НЕ любят, когда по одному и тому же адресу страницы можно получить совсем разный контент. Или (что то же самое) есть страницы без реальных адресов — вроде бы ты смотришь на каталог товаров, но если скопируешь и отправишь ссылку своей супруге, она будет видеть не то же самое, что видишь ты.

В реактивных сайтах такое встречается вдоль и поперек, поскольку страница вроде как одна (физически — и впрямь одна). Просто на ней динамически, в зависимости от действий пользователя, что-то меняется. И без специально-продуманных танцев с бубнами это не лечится. Зато скорость реакции на действия пользователя — молниеносная. Короче: скорость — высокая, но поисковики недовольны ссылками, отсутствием контента на страницах и метатегами.

Решение «в лоб» — уметь отдавать для браузеров одну версию страниц (реактивную), а для поисковиков — другую (статическую). Для этого берем серверный JavaScript (Node.js), и, прежде чем отдать страницу поисковику, — выполняем там все нужные скрипты. Но только на сервере.

Плюсы серверного рендеринга

• контент выводится сразу — пользователь не ждёт, когда он подгрузится;
  
• и, главное, — SEO: поисковые боты могут индексировать сайт.
  
  

Проблемы серверного рендеринга

1. Запросы данных на сервере выполняются асинхронно, но компоненты не перерендериваются после их получения
Решение: выполнять запросы на сервере синхронно, чтобы рендер выполнялся после получения данных.

2. componentDidMount не запускается в серверном рендеринге.
Решение: запускать его «насильно».

Собственно, ни при чем. В качестве серверной оснастки может выступать все, что угодно. Однако именно на нем у нас довольно много разработки e-commerce-сайтов. Как раз таких, где нужна seo-оптимизация, но и скорость, с которой React может реагировать на поведение пользователя — была бы не лишней.

Несмотря на изначальный скепсис, схема оказалась реально рабочей. Мы и раньше использовали React с битриксовыми проектами, но, как правило, изолированно (например — в проекте eBazaar на детальной странице ежедневника блок с персонализацией выполнен отдельным изолированным React-юнитом).

Ну, а для программистов, которые хотят в полную силу использовать React на проектах, где требованиями заказчика значится «Битрикс» — дорога открыта. Пользуйтесь. Но учтите, что типового shared-хостинга без поддержки Node.js на такую конструкцию вам не хватит (VDS или выделенный сервер — ваш вариант).

Заходите к нам в GutHub посмотреть экспериментальный код :) А если хотите послушать рассказ от первого лица, велкам на наш ютуб-канал (подпишитесь, чтобы не пропустить свежие видео о внутренней кухне студии).