Почему динамическая визуализация не является долгосрочным решением

Если вы пропустили это, Google недавно уточнил, что:

• Динамический рендеринг — это обходной путь, а не долгосрочное решение проблем с JavaScript.
• Google рекомендует вместо этого использовать рендеринг на стороне сервера, статический рендеринг или гидратацию.

Хотя официальная документация Google проливает свет на то, как нам теперь относиться к динамическому рендерингу, вопрос, который беспокоит многих, остается: почему именно динамический рендеринг мы должны рассматривать как временное решение?

Если этот вопрос побуждает вас искать ответ, как и меня, давайте копать!

Почему это обновление важно?

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

Хронология истории динамического рендеринга

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

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

В 2014 году Google официально признала, что начала отображать веб-сайты на основе JavaScript, а в 2015 году сообщила, что в целом способна отображать JavaScript . Тем не менее, многие веб-сайты по-прежнему боролись с правильным отображением и индексацией своего содержимого JavaScript.

Вот почему Бартош Горалевич, генеральный директор Onely, начал исследовать эту тему и экспериментировать, чтобы выяснить, может ли Google правильно сканировать и индексировать JavaScript-фреймворки .

В то время как со стороны Google более точная информация о динамическом рендеринге появилась в 2018 году. Во время конференции Google I/O гуглеры признались, что используют две волны индексации. В нем указано, что, как правило, рендеринг веб-сайтов на основе JavaScript откладывается до тех пор, пока у Google нет ресурсов для обработки этого контента. Кроме того, вскоре после конференции Google опубликовала свою официальную документацию (теперь обновленную), рекомендуя динамический рендеринг для более быстрой индексации вашего контента JavaScipt.

Затем, в 2019 году, Бартош Горалевич подробно остановился на динамическом рендеринге во время своей презентации на SMX WEST . Он стремился объяснить, почему это решение не является панацеей от всех проблем с рендерингом.

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

Что такое динамическая визуализация?

Динамический рендеринг (также известный как предварительный рендеринг) состоит из предоставления полнофункциональной версии JavaScript вашего веб-сайта пользователям и статической HTML-версии сканерам для представления вашего контента JavaScript. Он работает, обнаруживая и различая различные пользовательские агенты и предоставляя пользователям и ботам подходящие версии веб-сайтов.

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

Google дополняет это определение, уточняя:

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

источник: Джон Мюллер

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

Вот почему Google предполагает, что динамический рендеринг может быть компромиссом в основном для веб-сайтов:

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

Чем динамический рендеринг отличается от других популярных способов обслуживания JavaScript?

Рендеринг — это важный этап процесса индексации: то, как отображается ваш веб-сайт, влияет на то, как поисковые системы видят ваш контент. И чтобы удовлетворить потребности как ботов, так и пользователей, вам нужно узнать о двух разных подходах: рендеринг на стороне сервера и на стороне клиента.  

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

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

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

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

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

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

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

Нет бонусов SEO-рейтинга за его реализацию тем или иным способом — это просто разные способы сделать контент индексируемым (как и рендеринг на стороне клиента). Различия между динамическим рендерингом и рендерингом на стороне сервера из моего POV больше касаются практической настройки и обслуживания инфраструктуры (это также может повлиять на скорость, в зависимости от того, как вы все настроили).

источник: Джон Мюллер

Как работает динамический рендеринг?

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

Google рекомендует использовать следующие динамические средства визуализации:

• Prerender.io (стороннее ПО),
• Puppeteer (программное обеспечение с открытым исходным кодом) или
• Rendertron (программное обеспечение с открытым исходным кодом).

Настроив любое из рекомендуемых решений, не забудьте:

1. Выберите пользовательские агенты, которые вы хотите обслуживать статическую HTML-версию вашего веб-сайта, например, «googlebot» или «twitterbot».
2. Настройте кеш, чтобы ваш сайт обслуживался как можно быстрее и избегал тайм-аутов.
3. Убедитесь, что предварительно обработанная версия вашего веб-сайта обслуживает версию, ориентированную на устройства. Другими словами, краулеры мобильных поисковых систем должны видеть мобильную версию вашего сайта, когда другие краулеры — десктопную.
4. Убедитесь, что ваш сервер может обслуживать статический HTML для выбранных пользовательских агентов.

Что касается реализации динамического рендеринга, Google предоставляет официальную документацию по реализации и проверке конфигурации динамического рендеринга.

Почему и как начать разбираться с проблемами динамического рендеринга?

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

В качестве примера возьмем популярные веб-сайты электронной коммерции в США: 80% используют JavaScript для создания основного контента и ссылок на аналогичные продукты . Это представляет серьезную угрозу индексируемости критически важных частей этих доменов. Теперь подумайте о том, как это отразится на снижении их доходов.

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

Используйте тест для мобильных устройств

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

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

В этом инструменте вы можете погрузиться в раздел «Подробности», чтобы узнать, когда и каким сканером была просканирована страница, или даже проверить ответ HTTP. Если вы проверяете свой домен, тест на совместимость с мобильными устройствами может перевести вас на дальнейший анализ в Google Search Console.

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

Используйте консоль поиска Google

Одним из отчетов, которые необходимо проверить, чтобы убедиться, что вы правильно реализовали динамическую визуализацию, является отчет Index Coverage (индексация страниц). Это поможет вам решить проблемы с индексацией и информирует вас о том, какие из ваших страниц не проиндексированы и почему.

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

Еще одна полезная функция Google Search Console — инструмент проверки URL . Как и в случае с Mobile-Friendly Test, инструмент проверки URL позволяет проверить статус протестированной страницы и просмотреть ее обработанную версию.

Используйте ZipTie.dev

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

Чтобы проверить, проиндексирован ли конкретный фрагмент вашей страницы, вы можете использовать команду site: вместе с текстовым фрагментом в кавычках. Но когда у вас есть большой веб-сайт с миллионами URL-адресов для анализа, вы не сможете проверить их все вручную.

ZipTie.dev анализирует индексацию вместе с другими точками данных, такими как количество слов, заголовки, заголовки, метаописания и многое другое. Это поможет вам определить потенциальные причины ваших проблем с индексацией (и, следовательно, рендерингом).

Используйте тест расширенных результатов

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

Тест также показывает вам обработанную версию вашего веб-сайта и показывает, как Googlebot понимает вашу разметку, указывая любые ошибки, их типы и места их появления в коде.

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

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

Устранение неполадок (динамического) рендеринга всегда требует общих технических знаний в области SEO и тщательного анализа.

Почему динамическая визуализация не является долгосрочным решением?

Динамический рендеринг использует значительное количество ресурсов сервера.

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

• Получите пустую страницу ‒ робот Googlebot видит только начальный HTML-код, но поскольку в коде нет ссылки на JavaScript, остальная часть веб-сайта ему не видна. Веб-сайт не может быть проиндексирован, так как робот Googlebot не видит содержание.
• Получите версию веб-сайта, обработанную на стороне клиента. Технически Google может работать с JavaScript во многих случаях, но весь смысл реализации динамического рендеринга заключался в том, чтобы обслуживать статический контент. В некоторых случаях стоимость загрузки содержимого JavaScript и обновления исходной HTML-версии веб-сайта может оказаться слишком высокой для робота Googlebot.

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

Внедрение и обслуживание динамического рендеринга может использовать значительное количество ресурсов сервера. И если вы видите, что Googlebot может правильно индексировать ваши страницы, то, если вы не вносите критические, часто повторяющиеся изменения на свой сайт, возможно, вам не нужно на самом деле реализовывать что-то особенное. […]

источник: Джон Мюллер

Динамический рендеринг создает две отдельные структуры сайта вместо одной

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

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

Динамический рендеринг ухудшает взаимодействие с пользователем

Динамический рендеринг подразумевает, что вашим пользователям предоставляется версия, визуализированная на стороне клиента, и это может плохо повлиять на производительность страницы для пользователей, поскольку требует, чтобы их браузеры обрабатывали процесс рендеринга на их стороне. И это может стать настоящей проблемой, особенно для пользователей старых телефонов, которым будет трудно обрабатывать большие объемы JavaScript. Хотя рендеринг на стороне клиента — это еще не все зло, мы рекомендуем по возможности использовать маршрут на стороне сервера.

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

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

Из-за проблем на сервере или отсутствующих компонентов динамический рендеринг часто дает сбой. В результате Googlebot получает пустую страницу. К сожалению, вы не имеете ни малейшего представления об этом, когда смотрите на сайт как пользователь (с полнофункциональным JavaScript), а не как бот. Чтобы устранить эту проблему, переключите пользовательский агент на Googlebot в браузере .

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

Каковы лучшие альтернативы динамическому рендерингу?

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

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

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

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

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

Более того, в отличие от динамического рендеринга, рендеринг на стороне сервера не заставляет пользователей обрабатывать файлы JavaScript на своей стороне для создания ключевых элементов страницы. Это ускоряет загрузку страницы; некоторые показатели веб-производительности влияют на ваш рейтинг и взаимодействие с пользователем.

Но будьте осторожны: при рендеринге на стороне сервера пользователи могут испытывать несколько худшие показатели времени до первого байта, если серверу необходимо генерировать статический HTML ad hoc или сервер, кеширующий ответы, недостаточно эффективен.

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

Статический рендеринг

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

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

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

Регидратация

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

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

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

Может ли динамический рендеринг работать долго?

Может, но редко. Особенно, если у вас большой веб-сайт и вы не разбираетесь в SEO, не используйте этот подход в одиночку.

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

Вот два примера, когда наши клиенты использовали динамический рендеринг для:

Обслуживание отображаемых на стороне клиента ссылок для пользователей в нижнем колонтитуле

В этом случае, благодаря динамическому рендерингу, Googlebot мог найти ссылки в исходном коде, но в то же время ссылки нижнего колонтитула были сгенерированы для пользователей и добавлены в DOM (который представляет состояние вашей страницы после рендеринга) после того, как они начал листать страницу. Клиент решил реализовать динамический рендеринг для оптимизации производительности — не все элементы нужно сразу сохранять в DOM, если пользователи не прокручивают страницу до конца.

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

Клиент решил предоставить версию, обработанную на стороне сервера, ботам (более легкая версия списков), а версию, обработанную на стороне клиента, — пользователям (когда список продуктов создается специально и может быть персонализирован).

Подведение итогов

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

Если вам нужно реализовать динамическую визуализацию, не забудьте выполнить следующие четыре шага:

1. Планируйте обновления и развертывания. Убедитесь, что у ваших команд разработки и SEO достаточно ресурсов для реализации и обслуживания предварительно обработанного веб-сайта.
2. Убедитесь, что установка эффективна и не содержит ошибок. Разработайте способ проверки того, что установка работает правильно и в версии, предоставляемой ботам, отсутствуют ключевые элементы страницы.
3. Помните, что вам необходимо иметь возможность сравнивать версии HTML и JavaScript вашего веб-сайта и выявлять расхождения.
4. Помните, что в большинстве случаев динамический рендеринг должен быть только обходным путем. Ищите возможности переключиться на другие рекомендуемые решения, учитывая ваши ресурсы разработки и технологические возможности.