SEO: где мы с управлением JavaScript? (Часть 2)

1. Оптимизировать поиск сайтов
2. Как это работает?
3. Без изоморфизма
4. С изоморфизмом
5. Предварительная визуализация:
6. Рендеринг на стороне сервера
7. Улучшить время отклика
8. Добавить мета

Исторически сканеры поисковых систем для синтаксического анализа содержимого страниц не интерпретировали JavaScript, концентрируясь в основном на HTML. Тем не менее, менее чем за 10 лет Google изменил игру и расширяет ее возможности, пытаясь анализировать все файлы, включая JavaScript и CSS. Но каковы последствия с точки зрения естественных ссылок? Откройте для себя 2-ю часть нашего исследования.

Оптимизировать поиск сайтов

Я беру продолжение статья Стива Майенобе который рисует современное состояние ссылок на полноценные JavaScript-сайты для привлечения технического освещения.
Напомним, что даже если некоторые индексирующие боты теперь теоретически способны запускать JavaScript и, таким образом, сканировать сайты на основе JS-фреймворков (Angular, React, Vue ...), рендеринг на стороне сервера остается важным:

• Более быстрая и более детерминированная индексация
  Страница, сгенерированная серверной частью, объединена из разных потоков, которые могут занять некоторое время. Он приходит из блока, когда все готово, бот имеет только парсер. Легко. С другой стороны, для страницы JS, сгенерированной в браузере, боту трудно узнать, когда страница действительно завершена. А бот не любит работу слишком сложную ...
• Мета-контекстные данные, необходимые для обмена в социальных сетях
  Сети читают метаданные (заголовок, описание, OG) для иллюстрации общего ресурса. Если они генерируются спереди, сеть их не видит.
• Больше комфорта для интернет-пользователей
  Помимо SEO, это существенный критерий: первая страница, которую посетил пользователь, приходит уже построенной, и это позволяет избежать ожидания в течение нескольких секунд, пока JavaScript завершит работу впереди.

На самом деле мы всегда остаемся на этом принципе Белая Шляпа SEO : поисковые системы всегда будут стараться отдать предпочтение тому, что лучше для пользователя: время загрузки, согласованность контента, доступность.

Как это работает?

Возьмите пример Angular, который часто используется в FABERNOVEL CODE. Это изначально изоморфно начиная с v2, и действительно в момент начиная с v4 на рендеринге на стороне сервера. Эта тема выдвинута проектом Универсальный угловой - Универсальный, чтобы подчеркнуть, что этот код может быть выполнен в другом месте, чем в браузере.

Примечание: каждый URL создает чистую страницу, которую может сканировать бот, но для пользователя создается только первая страница его навигации, остальная часть его посещения продолжается в Angular Front.

Давайте быстро протестируем запуск простого углового стартера, затем того же изоморфного углового стартера, чтобы сравнить исходный код страницы. Вот краткое изложение хорошо задокументированной воздушной заслонки Узел / угловой стартер универсальный github :

Предварительные условия: убедитесь, что на вашем компьютере установлены nNode> = 6.9.x и npm> = 3.xx, в противном случае перейдите на страницу установка nodeJS это просто и быстро.

Клон репо

git clone https://github.com/angular/universal-starter.git

Без изоморфизма

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

Npm Run Start

Вы можете получить доступ к минималистичному сайту по URL http: // localhost: 4200

В исходном коде страницы мы видим зверя:

<App корень> </ приложение-корень>

... который, очевидно, не предоставляет никакой информации для бота, это просто тег, на котором висит генерация страницы.

С изоморфизмом

Существует 2 способа создания серверной страницы:

• В предварительном рендеринге, т. Е. Генерируя каждую страницу статически во время сборки
• В рендеринге на стороне сервера (SSR), т. Е. Предложение серверной части, которая динамически генерирует страницы.

Предварительная визуализация:

Притворный произведет все страницы в каталоге dist / browser.

npm run build: prerender && npm run serve: prerender

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

<app-root ng-version = "5.0.0"> <h1> Универсальная демонстрационная программа с использованием углового и углового интерфейса командной строки </ h1> <a routerlink="/" href="/"> Главная страница </a> <routerlink = "/ lazy" href = "/ lazy"> Lazy </a> <a routerlink="/lazy/nested" href="/lazy/nested"> Lazy_Nested </a> <router-outlet> </ router-outlet <lazy-view> я ленивый </ h3> </ lazy-view> </ app-root>

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

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

При вызове страницы сайта сервер (узел в целом, но версия также существует для asp.net и скоро будет также доступен загрузчик Java), который может запускать тот же код Angular JavaScript, что и браузер. Поэтому он может выполнять удаленные вызовы API, воспроизводить сложные сценарии, чтобы сделать страницу на лету, и отправить ее в браузер.

Давайте проверим:

npm run build: ssr && npm run serve: ssr

Затем мы можем обойти сайт, и исходный код каждой страницы содержит DOM-объект, который можно сканировать. Если мы посмотрим на каталог dist, содержащий сборку, то увидим, что он сильно отличается от prerender: в случае ssr мы находим файл server.js, выполняемый сервером nodeJS, и простой файл js, скомпилированный в каталог / server, тот же js, который отправляется в браузер. В файле server.ts мы видим, что вызовы перенаправляются на маршруты Express, которые затем выполняют Angular.

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

Улучшить время отклика

Давайте подведем итоги, чтобы увидеть проблему:

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

Вызов API выполняется дважды, сервером и браузером.

Как успокоить игру?

# Управление кешем на сервере API

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

# Перенести данные, уже полученные сервером, в браузер

На стороне сервера достаточно сериализовать в DOM данные, восстановленные потоками. Спереди мы проверяем наличие этих данных перед запросами, что позволяет избежать ненужного вызова. Это реализуется из Angular5 посредством State Transfer, то есть отправки состояния приложения сервером с сгенерированным DOM. вид это очень хороший учебник Легко реализовать на вышеупомянутой основе, добавив менее 10 строк кода в дроссель.

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

# Настройка nodeJS серверного кэша

Данные API могут поддерживаться на этом уровне до истечения срока годности, чтобы сохранять обращения сервера к API при каждом вызове страницы. На стороне сервера это обычно включает перехват запросов для прозрачного управления кешем в коде. Модуль HTTPClient док https://angular.io/guide/http#caching дает очень хороший пример этой техники.

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

Добавить мета

Angular обычно ограничивается периметром своего тега <app-root>. Чтобы повлиять на мета в <head> страницы, Angular должен иметь возможность влиять на DOM на стороне сервера. Поскольку многие элементы отсутствуют (нет оконного объекта, документа, события готовности DOM ...), мы не можем практиковать классические вызовы внешнего интерфейса. Однако Angular объединяет изоморфные средства для воздействия на DOM, которые можно использовать для изменения части страницы. Пакет "родная платформа-браузер" предлагает прямые манипуляции с Title и Meta. Смотрите этот хороший учебник , который объединяет это управление в несколько строк на основе стартера.

Я собрал все эти практики в этом скромном вилка универсального стартера ,

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

Похожие

Комментарии