Индексируемость в Angular и React с универсальным JavaScript

1. Как работает фреймворк SPA без универсального JavaScript?
2. Как среда SPA пыталась быть индексируемой до универсального JavaScript?
3. Как сделать фреймворк SPA индексируемым с помощью универсального JavaScript?
4. заключение

После появления AJAX или, как его сейчас называют, API Fetch , появляются структуры SPA (одностраничное приложение) , которые с помощью запросов Fetch генерируют часть HTML в клиенте , что не позволяет паукам правильно индексировать весь контент и, прежде всего, отслеживать его , потому что, кроме того, этот тип Веб-сайты могут быть реализованы без отслеживаемых ссылок посредством использования URL-адресов с фрагментами (использование #) или напрямую без использования URL-адресов в ссылках (которые работают только для пользователя при нажатии на них).

С обозначением «SPA» приходит термин « многостраничное приложение» (MPA) , чтобы обозначать классические структуры, которые генерируют весь HTML на сервере , и именно это необходимо для того, чтобы пауки могли индексировать и отслеживать страницы без проблем.

Существует много фреймворков типа SPA: от Google у нас есть Angular (ранее назывался AngularJS), от Facebook, React и множество других открытых источников, таких как Vue, Meteor, Loop, Rendr, Ember, Aurelia, Backbone, Knockout, Mercury. и т. д. Эти структуры изначально могли быть выполнены только на клиенте, но позже мы увидим, что лучшим решением является то, что это не так.

Как работает фреймворк SPA без универсального JavaScript?

Как я уже упоминал, платформы SPA основаны на использовании API Fetch, поскольку они работают путем загрузки в браузере рядом с оболочкой, которая содержит части, которые не изменяются во время навигации , в дополнение к серии шаблонов HTML, это будет заполнено ответами запросов Fetch, которые будут отправлены на сервер . Мы должны различать, как это происходит в первом запросе к Интернету и при навигации по ссылкам после его загрузки, поскольку операция отличается:

• Первый запрос : оболочка отправляется по сети. Затем, с помощью одного или нескольких запросов Fetch (которые также передаются по сети), получают данные для генерации HTML основного содержимого страницы. Следовательно, первая загрузка становится медленнее из-за передачи запросов по сети, что обычно занимает больше времени. Следовательно, при первой загрузке быстрее отправлять весь HTML, сгенерированный на сервере, в одном запросе, как это делают платформы MPA.
• Загрузите следующие страницы после первого запроса : в средах SPA загрузка намного более плавная и быстрая , поскольку не нужно генерировать весь HTML. Кроме того, вы можете добавлять переходы или полосы загрузки между отображением одной страницы и другой, что дает ощущение большей скорости. Тем не менее, у нас есть большая дополнительная проблема: при создании части HTML-кода в клиенте с помощью JavaScript после запроса Fetch, который выполняется с помощью JavaScript, пауки не могут индексировать эти страницы , особенно когда пользователь может перейти на страницы, где у паука даже нет URL, который он может индексировать.

Как среда SPA пыталась быть индексируемой до универсального JavaScript?

Первоначально возникает идея использовать инструмент на сервере, который действует как браузер . Этот браузер на сервере вступит в действие по просьбе паука. Это будет работать следующим образом: сначала мы обнаружим, что запрос исходит от паука, фильтрующего его тем же пользовательским агентом (например, «Googlebot»), а затем мы передаем его в своего рода браузер внутри самого сервера. Это, в свою очередь, будет запрашивать этот URL для веб-службы, также на том же сервере. Затем при получении ответа на запрос к веб-службе он будет выполнять JavaScript, который будет выполнять запросы Fetch и генерировать весь HTML-код, чтобы мы могли вернуть его пауку и кэшировать его. Таким образом, следующий запрос паука на этот URL-адрес будет возвращен из кэша и, следовательно, будет работать быстрее.

Для этого в ссылках, запускающих запросы Fetch, должны быть удобные URL-адреса (устаревшие методы, такие как URL-адреса с хэш-бангом «#!» Не должны использоваться), и когда пользователь нажимает на ссылку, разработчик должен нарисовать тот же URL-адрес. с JavaScript, используя историю API. Таким образом, мы гарантируем, что пользователь может поделиться и сохранить этот URL в избранном. Этот URL должен возвращать полную страницу по запросу паука на сервер.

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

• Мы занимаемся синхронизацией , поэтому наш веб-сайт будет проиндексирован только теми пауками, которых мы отфильтровали.
• Если у нас нет кэшированного HTML, паук будет воспринимать, что время загрузки очень медленное .
• Если мы хотим, чтобы паук воспринимал более быстрое время загрузки, нам нужно сгенерировать кэш с HTML-кодом всех URL-адресов , что подразумевает наличие политики аннулирования кэша. Это может быть невозможно по следующим причинам:
  • Что информация должна постоянно обновляться .
  • Что время для генерации всего кэша недоступно.
  • Что у нас нет места на сервере для хранения всех страниц в кеше.
  • То, что у нас нет вычислительной мощности, чтобы иметь возможность генерировать кэш и одновременно поддерживать страницу в сети.
  • Имейте в виду, что проблема аннулирования кэша очень сложна , поскольку кэш должен обновляться, когда что-то меняется в базе данных. Однако в кеше нелегко стереть именно те данные, которые были обновлены, поскольку не будучи базой данных, а чем-то более простым и быстрым, мы не можем легко выбрать то, что хотим восстановить, поэтому мы следуем стратегии, которые стирают больше, чем необходимо, или оставляют противоречивые данные. В зависимости от случая эти проблемы могут помешать выбрать это решение.
  • И наконец: инструменты, которые выполняют роль браузера на сервере, оплачиваются ( Prerender.io, SEO4Ajax, Brombone, ...).

Как сделать фреймворк SPA индексируемым с помощью универсального JavaScript?

Универсальный JavaScript может быть запущен как на клиенте, так и на сервере.

Идея универсального JavaScript или JavaScript, изоморфного (как он изначально назывался), возникает в рамках SPA в Facebook ( React ) и состоит в использовании универсального API, который использует клиентские API-интерфейсы JavaScript снизу, или серверных API-интерфейсов JavaScript. с Node.JS, в зависимости от того, выполняется ли этот универсальный API на клиенте или на сервере, соответственно. Таким образом, при написании кода JavaScript с использованием этого API мы можем выполнить его как на клиенте, так и на сервере. Если мы присоединяем это к платформе SPA, которая предназначена для работы только на клиенте, у нас есть универсальная платформа, которая может работать как на клиенте, так и на сервере следующим образом:

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

1. Только в клиенте .
2. Только на сервере , хотя этот JavaScript можно заменить любым языком сервера, например PHP.
3. Как на клиенте, так и на сервере (универсальный JavaScript) .

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

При использовании Universal JavaScript у нас есть часть кода, повторно используемая на клиенте и на сервере.

Как и в случае, когда у нас не было универсального JavaScript, поведение будет отличаться для первого запроса и следующих :

• Первый запрос : независимо от того, поступил ли запрос от паука или от пользователя, весь HTML будет сгенерирован на сервере с помощью блока Universal JavaScript, который выбрасывает запросы Fetch в JavaScript, который выполняется только на сервере. Эта операция аналогична использованию универсального JavaScript, но с той разницей, что запросы Fetch отправляются с сервера на себя, а не с клиента, сохраняя первоначальную передачу запросов по сети.
• Загрузите следующие страницы после первого запроса : если вы являетесь пользователем и нажимаете на ссылку, JavaScript, который запускается только на клиенте, будет перехватывать щелчок и передавать запрос в Universal JavaScript (так же, как в предыдущем пункте). Это сделает запрос Fetch к JavaScript, который выполняется только на сервере, с запрошенным URL, а при получении данных с сервера он покажет новую страницу пользователю. В этом случае запрос Fetch передается от клиента к серверу , предотвращая перезагрузку всей страницы.

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

заключение

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

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

Похожие

Комментарии