Недавно я сделал небольшой доклад о том, как рендеринг может повлиять на SEO. Я начал с пары слайдов по архитектуре динамического рендеринга и попытался вернуться к первым принципам. Я закончил более или менее с историей Интернета. Попутно я понял, что есть много основ веба, которые часто упускают из виду. У нас есть отличные инструменты, такие как React и Server Side Rendering (SSR), но они предлагают решения проблем, которые некоторые инженеры могут не понять. Не все создают веб-сайты с 90-х годов, поэтому многие проблемы что такие инструменты, как NextJS, не совсем понятны. Попросите любого кандидата на собеседование сравнить CSR и SSR, и вы неизбежно получите ответ, что SSR лучше для SEO. Но почему? Почему SSR влияет на SEO?

Этот пост попытается ответить на этот вопрос, начиная с основ Интернета. Мы рассмотрим:

Что такое веб-сайт? Что такое сканер?
Что такое рендеринг? Что такое CSR и SSR?
Как это влияет на SEO?
Что я видел в производстве?

Это в основном исходит из моих заметок, так что ожидайте больше повествования, чем чего-то отточенного и идеального. По пути я связался с полезными ресурсами. Старайтесь думать о вещах с основ. Если вы думаете про себя, читая «ага, но библиотека xyz решает эту проблему!» затем спросите себя, как он решает эту проблему. Потягивание за нити может быть отличным способом обучения.

Что такое веб-сайт?

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

HTML — это разметка — она может содержать такие вещи, как текст, изображения, видео, css, Javascript и т. д. Вы можете помещать теги внутри других тегов (например, h3 внутри тела), что делает его иерархическим. Само по себе это довольно скучно читать, поэтому мы используем веб-браузеры, такие как Chrome или Firefox, для его просмотра.

Наблюдается, что браузеры превращают HTML в пиксели на экране. Он берет HTML, анализирует его, строит в памяти структуру данных для его представления и взаимодействия с ним (дерево — помните, мы говорили, что HTML является вложенным/иерархическим?), выполняет некоторые математические расчеты для определения макета. , затем рисует его на экране.

Я написал HTML, что теперь?

На данный момент у нас есть HTML для нашего контента и браузер для его отображения. Люди (и роботы) и сейчас просматривают нашу страницу в Интернете.

Однако, если вы когда-либо публиковали свой собственный блог или веб-сайт, этот визуальный элемент может быть вам знаком.

К сожалению, просто разместить что-то в Интернете — все равно, что бросить гальку в океан — рябь не так заметна. Нам нужен способ направить трафик на наш сайт. Как люди находят сайты? С помощью поисковых систем! Как поисковые системы находят сайты? Ползком.

Что такое веб-сканер?

Время собеседования по проектированию систем — нам нужно создать что-то, что сможет сканировать и индексировать Интернет. Это существует (Google), поэтому это должно быть возможно. Как работает человек? Возможно вот так:

  1. Возьмите действительно большой список/очередь исходных URL-адресов (может быть, 1000, 10 000, сколько угодно)
  2. Откройте первый URL-адрес. Сделайте запрос HTTP GET и загрузите HTML для сайта.
  3. Разобрать HTML. Посмотрите на ‹метатеги› в ‹шапке›, заголовке и содержании. Попробуйте создать небольшое резюме или фрагмент этого сайта. (Также как-то хранить и индексировать весь этот контент. Пока не в тему.)
  4. При анализе HTML найдите все теги гиперссылок ‹a›. Посмотрите на их свойство href и извлеките URL-адрес, на который они указывают. Добавьте его в очередь на шаге 1
  5. Вернитесь к шагу 1 и выполните цикл.

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

Основываясь на шаге 3, мы можем сказать, что (среди прочего)сканер превращает HTML в фрагменты результатов поиска.

На данный момент важно помнить, что краулеры используют HTML. Мы должны предоставить им HTML, если мы хотим, чтобы наша сторона сканировалась и индексировалась. Это может показаться очевидным, но с годами веб-разработка изменилась. Когда вы в последний раз писали HTML-файл? В наши дни большая часть нашей разработки выполняется с использованием библиотек Javascript, таких как React или Angular. Важно понимать, что потребуются некоторые дополнительные шаги для преобразования этого кода в HTML, который сможет прочитать сканер. Чтобы лучше понять этот факт, давайте совершим краткий экскурс в историю веб-разработки.

История веб-разработки: статические 90-е

В 90-х сайты были в основном статичными, и жизнь у всех была проще. Сайты обычно имели следующую структуру.

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

Боты и люди увидят один и тот же сайт. Не беспокойтесь о маскировке. Ботам давали HTML, так что они были счастливы. Помните, боты любят HTML.

История веб-разработки: динамичные 2000-е

Шло время, Интернет повзрослел, и люди стали использовать его для большего количества вещей (у него даже был катастрофический пузырь и крах!). Рост электронной коммерции и социальных сетей, таких как MySpace, означал, что сайтам необходимо было работать с динамическими данными, такими как имена пользователей, список продуктов, изображения профилей и т. д.

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

  1. Хранить данные в базе данных
  2. Используйте файлы PHP на сервере (index.php), чтобы отвечать на запросы, извлекать данные из БД, вставлять данные в HTML и возвращать их тому, кто их запросил.

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

История веб-разработки: Javascripting 2010-е. Делайте все на клиенте!

Со временем Javascript стал более мощным и распространенным. Такие достижения, как движок Google V8, означали, что Javascript стал более производительным. ES6 дал языку столь необходимое обновление, и такие библиотеки, как Angular и React, начали набирать обороты. JS был в центре внимания.

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

Обратите внимание, что вместо нескольких HTML-файлов сервер (или CDN) теперь будет возвращать один файл index.html (отсюда и термин «одностраничное приложение» — SPA). Этот файл был по большей части пустым — он содержал чуть больше тега «скрипт», указывающего на пакет JS для загрузки и выполнения. JS отвечал за извлечение данных из внешних API и выполнение соответствующих вызовов в DOM API браузера для создания HTML-структуры для отображения браузером на экране (помните, браузеры превращают ее в пиксели). Это Визуализация на стороне клиента (CSR). Это было здорово, но мы забыли о ком-то.

Боты любят HTML. Мы не возвращаем много контента в наш index.html. Возможно, мы нарушили SEO нашего сайта (мы это сделали).

История веб-разработки: с 2016 года. Вернуться на сервер!

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

Это означало, что во многих случаях для инженеров чистая корпоративная социальная ответственность была неприемлема. Нам нужно было получить хотя бы часть контента, отображаемого на стороне сервера. Но мы также привыкли использовать такие инструменты, как React и Angular. Отказ от них приведет к регрессу развития.

Как упоминалось ранее, Google V8 Engine улучшил производительность Javascript. Это также позволило JS работать вне браузера с помощью таких инструментов, как NodeJS. Это означало, что теперь JS можно спокойно запускать на сервере. Если мы можем запустить JS на сервере, то с помощью нескольких настроек мы также можем запустить на сервере немного React. Это означает, что мы все еще можем разрабатывать, используя инструменты, которые нам нравятся, и не полностью ломать SEO в процессе.

Если вам интересно, есть хорошая серия по основам SSR.

Успех! Мы можем остановиться сейчас, верно?

Не совсем. SSR может помочь с SEO, а также некоторыми другими показателями производительности, особенно в сочетании с некоторыми другими вещами. Стоит отметить, что все приложение не обязательно должно быть SSRd — много раз вы просто SSR критического начального контента для страницы, а затем позволяете браузеру позаботиться об остальном/гидрате по мере необходимости. Но у SSR есть пара недостатков (по состоянию на 2022 год):

  • Накладные расходы разработчика. Существуют дополнительные концепции, о которых ваша команда разработчиков должна знать, чтобы писать код React, который будет правильно отображаться на сервере.
  • Техническое обслуживание сервера. Вам потребуется настроить и поддерживать некоторые среды NodeJS для работы на стороне сервера. Это приведет к некоторой дополнительной разработке, мониторингу, отладке и т. д.
  • Стоимость: вы будете выполнять больше циклов на своих серверах вместо того, чтобы выполнять все в браузере вашего клиента — это может стоить дорого.
  • Веб-компоненты. Если ваше приложение использует что-то вроде веб-компонентов, они могут неправильно отображаться с использованием SSR без выполнения дополнительных действий. Ситуация улучшается, но имейте в виду, что вам могут понадобиться прокладки или полифиллы на стороне сервера.

Динамический рендеринг — делай все!

Динамический рендеринг был подходом, предложенным Google для использования гибридного подхода к рендерингу (больше не рекомендуется). Вы можете разработать приложение React с помощью CSR и поддерживать некоторую дополнительную инфраструктуру на бэкэнде для предварительного рендеринга контента с помощью таких инструментов, как Rendertron. Поскольку на нем работала безголовая версия Chrome, отображаемый контент будет очень похож на то, что будет создавать CSR (с дополнительным преимуществом, заключающимся в том, что веб-компоненты не ломаются). Однако запуск безголового Chrome для каждого входящего запроса был бы дорогостоящим, поэтому сайты обычно фильтруют запросы на основе User-Agent для обнаружения трафика ботов и предварительно обрабатывают только эти запросы. Опять же, все ради того, чтобы у наших ботов был статический HTML.

Прилежный GoogleBot

И последнее замечание: GoogleBot развивался с годами и теперь может довольно хорошо читать JS и индексировать сайты с помощью CSR.

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

Заключение

Современные инструменты SSR дают нам действительно хорошие решения для поддержки SEO, но при этом позволяют разрабатывать все, используя библиотеки JS, такие как React. Важно понять, как мы к этому пришли и какие проблемы решают эти инструменты. Спасибо за прочтение.

Полезные ресурсы