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

Что такое JavaScript SEO?

По своей сути, JavaScript SEO - это в основном практика проверки того, что контент на странице (выполняемый через JS) правильно отображается, индексируется и, в конечном итоге, ранжируется в результатах поиска поисковыми системами. Это особенно актуально в связи с растущей популярностью рендеринга на стороне клиента и веб-сайтов, построенных на фреймворках JavaScript. Прежде чем продолжить, давайте посмотрим на два преобладающих типа рендеринга:

  • Отрисовка на стороне сервера (SSR) - традиционный метод отрисовки, при котором практически все ресурсы вашей страницы размещаются на сервере. Затем, когда страница запрашивается, HTML доставляется в браузер и обрабатывается, JS и CSS загружаются, а окончательный рендеринг отображается пользователю / боту.
  • Отрисовка на стороне клиента (CSR) - более новый вид метода отрисовки, основанный на JS, выполняемом на стороне клиента (браузере) через платформу JavaScript. По сути, клиент сначала запросит исходный код, в котором будет очень мало индексируемого HTML, затем будет сделан второй запрос для файла .js, содержащего весь HTML в JavaScript в виде строк.

Основные различия между SSR и CSR?

Рендеринг на стороне сервера может быть немного быстрее при первоначальном запросе просто потому, что для этого не требуется столько циклов обращения к серверу. Однако на этом все не заканчивается, производительность также зависит от некоторых дополнительных факторов. Все это может привести к кардинальным изменениям в пользовательском опыте:

  • Скорость интернета пользователя, отправляющего запрос.
  • Сколько активных пользователей заходят на сайт одновременно
  • Физическое расположение сервера
  • Насколько оптимизированы страницы по скорости
  • Так далее…

С другой стороны, рендеринг на стороне клиента выполняется медленнее при первоначальном запросе, поскольку он совершает несколько циклических обращений к серверу. Однако, как только эти запросы будут выполнены, CSR предлагает невероятно быстрый опыт работы через JS-фреймворк.

Вот полезная метафора, описывающая разницу между SSR и CSR:

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

Почему наблюдается эта тенденция?

С ростом популярности фреймворков JavaScript, таких как Angular, React и Vue.js, разработчики теперь могут более эффективно доставлять веб-страницы, а также обеспечивать невероятно быструю загрузку пользователей. Однако, если это не спланировать тщательно, этот скачок в эффективности в настоящее время может стоить существенной стоимости SEO.

Прежде чем продолжить, давайте быстро сделаем шаг назад и рассмотрим разницу между тем, как JavaScript обычно использовался в прошлом, и тем, как он изменился в настоящее время. Этот прогресс проиллюстрирован ниже на графике DeepCrawl / Elephate.

В прошлом JS преимущественно использовался для добавления различных уровней взаимодействия к веб-странице. Это было достигнуто путем ссылки на библиотеки JS, такие как JQuery. Поскольку JS просто манипулировал содержимым HTML, уже присутствующим в исходном коде, проблем с обнаружением и индексированием содержимого поисковыми системами не возникало. Однако с некоторыми современными JS-фреймворками и CSR исходный код веб-страницы внезапно оказывается практически пустым, а содержимое отображается исключительно путем выполнения JS на стороне клиента.

Это усложняет работу поисковых систем, но Google на самом деле является единственной поисковой системой сегодня, которая даже в некоторой степени призвана справиться с этим. Ни у одной из других поисковых систем нет возможностей рендеринга JS, используемых в настоящее время Google. Это означает, что даже если ваш контент CSR может быть проиндексирован Google, он, вероятно, не будет индексироваться другими поисковыми системами.

Как Google сегодня обрабатывает отрисовку JavaScript?

Google недавно представил свой текущий двухволновой процесс рендеринга и индексации JS в Google I / O.

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

  • Однако на сайтах, отображаемых на стороне клиента, Google практически нечего индексировать в исходном коде во время первой волны.

Вторая волна может произойти через несколько часов или даже через несколько недель. Google вернется на страницу, когда станут доступны дополнительные ресурсы для полной визуализации и индексации сгенерированного JS контента.

  • Это означает, что там, где, как и в случае с SSR, обычно нет проблем с задержкой отрисовки Google, потому что весь контент находится в исходном коде и индексируется во время первой волны. В CSR, где индексируемый контент раскрывается только при рендеринге, эта значительная задержка может означать, что контент может не индексироваться или не отображаться в результатах поиска в течение нескольких дней или даже недель.

Почему Google борется с обработкой JavaScript?

Вы можете спросить себя,

"Зачем Google вообще нужен двухэтапный процесс для рендеринга JavaScript?"

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

Причина?

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

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

  • Для пользовательских компьютеров (пользовательские настольные компьютеры, ноутбуки, мобильные устройства, планшеты и т. Д.) Их возможности ЦП могут сильно различаться для каждого типа устройства, например, ЦП мобильного устройства обычно больше борется с тяжелым сайтом, загруженным JS, чем с настольным компьютером.
  • Тяжелый JavaScript может потреблять большой объем ЦП устройства, памяти и даже время автономной работы. Это показывает, насколько далеко влияние JavaScript может иметь на производительность - от робота Google до мобильного устройства пользователя.
  • В результате всегда рекомендуется тестировать страницы с помощью вкладки Производительность в Инструментах разработчика Chrome, чтобы проверить производительность во время выполнения. Здесь вы можете проверить производительность устройства с помощью дросселирования сети, что помогает имитировать различные возможности ЦП мобильных устройств, разные скорости интернета и то, насколько хорошо ваши страницы обрабатываются в соответствии с этими спецификациями.

Каковы последствия SSR и CSR для SEO?

Для рендеринга на стороне сервера весь HTML-контент присутствует в исходном коде, что означает, что поисковая система может запрашивать, сканировать и индексировать его немедленно. В результате сокращается время до фактического появления и ранжирования в результатах поиска.

Для рендеринга на стороне клиента HTML, который необходимо проиндексировать, раскрывается только тогда, когда JS полностью отображается на стороне клиента. Таким образом, с двухволновой системой, которую Google использует в настоящее время, может пройти от нескольких часов до недели, прежде чем контент будет просканирован, проиндексирован и начнет ранжироваться в результатах поиска.

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

Какое решение?

Хотя Google в настоящее время работает над обновлением своих возможностей рендеринга JavaScript для включения в будущие выпуски Chrome, этот расплывчатый график не помогает веб-мастерам сегодня бороться с тем, что их контент CSR не индексируется. Это также не принимает во внимание все другие поисковые системы, которые даже не соответствуют текущим возможностям рендеринга JS в Google.

Есть два основных решения этой проблемы:

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

2. Изоморфный JavaScript. Рекомендуемый Google. Этот вариант предполагает, что и клиент, и поисковые системы получают предварительно обработанную страницу с индексируемым HTML-содержимым при начальной загрузке (по сути, действуя как SSR). Затем все функциональные возможности JS накладываются поверх этого, чтобы обеспечить высокую производительность на стороне клиента. Он также лучше всего работает как для пользователей, так и для роботов поисковых систем, однако есть несколько вопиющих проблем с изоморфным рендерингом:

  • Реализация может быть сложной задачей, и многим разработчикам это сложно. Это также может быть довольно дорого, учитывая ресурсы, необходимые для успешного внедрения. Необходимо провести обширное исследование, чтобы определить лучший способ выполнения SSR с вашим фреймворком JS. Вот несколько ресурсов о том, как делать SSR как для Angular, так и для React.

Заключение

Ясно, что использование JavaScript для интерактивного улучшения пользовательского опыта и визуализации веб-страниц только увеличивается. Таким образом, мы, как специалисты по оптимизации, должны лучше сообщать об этих соображениях нашим разработчикам при приближении к новым проектам.

Google и поисковые системы в целом будут продолжать улучшать свою способность отображать JS-страницы в большом масштабе. Однако это, несомненно, выявит новые препятствия, которые необходимо преодолеть, поскольку методы разработки также продолжают развиваться. Идеи, описанные в этой статье, призваны дать вам общее представление о JavaScript SEO и последствиях, которые его породили. Если вы хотите узнать больше, я предлагаю начать с этой замечательной статьи, написанной SEO-экспертами по JavaScript в Elephate.

Дополнительная информация