Преимущества динамического рендеринга для SEO

За последние несколько лет популярность фреймворков JavaScript росла, в немалой степени благодаря гибкости, которую они предлагают. «Фреймворки JavaScript позволяют быстро разрабатывать. Он предлагает лучший пользовательский опыт. Он предлагает более высокую производительность и расширенные функциональные возможности, которых не хватает традиционным фреймворкам, не поддерживающим JavaScript», — сказал Нати Элимелех, руководитель отдела технического SEO в Wix.

«Поэтому неудивительно, что очень большие веб-сайты или сложные пользовательские интерфейсы со сложной логикой и функциями в настоящее время обычно используют фреймворки JavaScript», — добавил он.

На SMX Next Элимелех представил обзор того, как JavaScript работает для клиентского, серверного и динамического рендеринга, а также поделился информацией об аудите, полученной в результате рендеринга JavaScript на более чем 200 миллионах веб-сайтов.

Рендеринг на стороне клиента и на стороне сервера

Различные методы рендеринга подходят для разных целей. Элимелех выступал от имени динамического рендеринга как средства удовлетворения поисковых роботов и пользователей, но сначала необходимо понять, как работает рендеринг на стороне клиента и на стороне сервера.

Рендеринг на стороне клиента

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

«Когда мы говорим о инфраструктурах JavaScript, этот сервер отвечает чем-то, что немного отличается от того, к чему мы привыкли», — сказал Элимелех.

«Он отвечает каркасным HTML — просто базовым HTML, но с большим количеством JavaScript. По сути, он говорит моему браузеру запустить сам JavaScript, чтобы получить весь важный HTML», — сказал он, добавив, что браузер пользователя затем создает визуализированный HTML (окончательный HTML, который используется для построения страницы так, как мы реально увидеть). Этот процесс известен как рендеринг на стороне клиента.

«Это очень похоже на сборку собственной мебели, потому что в основном сервер говорит браузеру: «Привет, это все части, это инструкции, создай страницу. Я доверяю тебе.' А это значит, что вся тяжелая работа переносится в браузер, а не на сервер», — сказал Элимелех.

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

Рендеринг на стороне сервера

Для клиентов, которые не выполняют JavaScript, можно использовать рендеринг на стороне сервера.

«Рендеринг на стороне сервера — это когда весь этот JavaScript выполняется на стороне сервера. Все ресурсы требуются на стороне сервера, и вашему браузеру и боту поисковой системы не нужно выполнять JavaScript, чтобы получить полностью отрендеренный HTML», — пояснил Элимелех. Это означает, что рендеринг на стороне сервера может быть более быстрым и менее ресурсоемким для браузеров.

«Рендеринг на стороне сервера похож на предоставление вашим гостям настоящего стула, на котором они могут сидеть, вместо того, чтобы собирать его», — сказал он, продолжая свою предыдущую аналогию. «И когда вы выполняете рендеринг на стороне сервера, вы в основном делаете свой HTML видимым для всех видов ботов, всех видов клиентов. . . Неважно, каковы возможности JavaScript, он может видеть окончательный важный визуализированный HTML», — добавил он.

Динамический рендеринг

Динамический рендеринг представляет собой «лучшее из обоих миров», — сказал Элимелех. По словам Google, динамический рендеринг означает «переключение между визуализированным контентом на стороне клиента и предварительно обработанным контентом для определенных пользовательских агентов».

Ниже представлена ​​упрощенная схема, объясняющая, как работает динамическая отрисовка для разных пользовательских агентов (пользователей и ботов).

«Итак, есть запрос к URL, но на этот раз мы проверяем: знаем ли мы этот пользовательский агент? Это известный бот? Это Гугл? Это Бинг? Это Семруш? Это что-то, о чем мы знаем? Если это не так, мы предполагаем, что это пользователь, а затем выполняем рендеринг на стороне клиента», — сказал Элимелех.

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

С другой стороны, если клиент является ботом, то рендеринг на стороне сервера используется для обслуживания полностью визуализированного HTML. «Значит, оно видит все, что нужно видеть», — сказал Элимелех.

Это представляет собой «лучшее из обоих миров», поскольку владельцы сайтов по-прежнему могут обслуживать свой контент независимо от возможностей JavaScript клиента. А поскольку существует два потока, владельцы сайтов могут оптимизировать каждый из них, чтобы лучше обслуживать пользователей или ботов, не влияя на другой.

Но динамический рендеринг не идеален

Однако есть сложности, связанные с динамическим рендерингом. «Нам нужно поддерживать два потока, два набора логики, кэширование, другие сложные системы; так что это более сложно, когда у вас есть две системы вместо одной», — сказал Элимелех, отметив, что владельцы сайтов также должны вести список пользовательских агентов, чтобы идентифицировать ботов.

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

«Динамический рендеринг на самом деле является предпочтительным и рекомендуемым решением Google, потому что Google заботится о том, чтобы важные вещи были одинаковыми [между двумя версиями]», — сказал Элимелех, добавив, что «важные вещи» — это то, что нас волнует. как оптимизаторы: контент, заголовки, метатеги, внутренние ссылки, навигационные ссылки, роботы, заголовок, каноническая, разметка структурированных данных, контент, изображения — все, что связано с тем, как бот будет реагировать на страницу . . . важно сохранять идентичность, и когда вы сохраняете их идентичными, особенно контент и особенно метатеги, у Google нет проблем с этим».

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

Для проверки потенциальных проблем Elimelech рекомендует Screaming Frog или аналогичный инструмент, который позволяет сравнивать два сканирования. «Итак, нам нравится сканировать веб-сайт как робот Googlebot (или другой пользовательский агент поисковой системы), сканировать его как пользователь и проверять, нет ли каких-либо различий», — сказал он. Сравнение соответствующих элементов между двумя обходами может помочь вам определить потенциальные проблемы.

Элимелех также упомянул следующие методы выявления проблем:

• Визуальная проверка путем переключения пользовательского агента в браузере и/или отключения JavaScript, чтобы увидеть, изменилось ли что-либо между версиями.
• Google Search Console можно использовать, чтобы увидеть, какой HTML-код возвращается в Google и как он может его отобразить.
• Инструменты тестирования, такие как тест Google для мобильных устройств, тест расширенных результатов и инструмент проверки разметки схемы Schema.org (ранее инструмент тестирования структурированных данных).

«Помните, JavaScript-фреймворки никуда не денутся, — сказал он. «Возможно, вы скоро встретитесь с одним из них, так что вам лучше быть готовым справиться с ними».

Посмотреть полную презентацию SMX Next можно здесь (требуется бесплатная регистрация).

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