Во имя SEO: рендеринг на стороне сервера для одностраничных приложений

1. Одностраничные приложения
2. SEO-дружественный SPA
3. SEO для веб-сканеров
4. Решение
5. Рендеринг на стороне сервера (SSR)
6. Вам нужен ССР или нет?
7. Фокус вашей деятельности
8. Аутентификация
9. Большая загрузка первой страницы
10. Ключевые слова и социальный обмен
11. Инструменты БСО
12. Ember Fastboot 1.0
13. ReactDOMServer
14. Vue.js & Nuxt.js
15. Угловой универсальный
16. Takeaways

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

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

Одностраничные приложения

Мобильный UX полагается на переходы в реальном времени и анимации для иллюстрации ввода пользователя. Традиционное обновление / перезагрузка страницы, которая является атрибутом опыта веб-сайта, должна была пройти, чтобы создать непрерывное бесшовное взаимодействие. В результате заметное количество веб-сайтов начали работать как одностраничные приложения (SPA).

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

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

SEO-дружественный SPA

Стандартное поведение робота поисковой системы (он же веб-сканер) не имеет значения для SPA, поскольку отсутствует весь контент, на который опирается SEO. Он генерируется, извлекается и отображается по требованию на стороне клиента. Для этого многие веб-сайты используют асинхронные вызовы AJAX, которые в основном являются JavaScript-кодами, которые вводят новый код контента из хранилища сервера на определенную страницу без перезагрузки всего сайта в браузере.

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

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

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

SEO для веб-сканеров

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

Так что, если ваша страница контента была изменена с помощью JavaScript, Google сделал инструмент называется «Получить как Google», чтобы показать вам, что он видит на странице. Оказывается, Googlebot может работать с асинхронным JavaScript.

Робот Googlebot предоставит веб-странице не менее 20 секунд для выполнения асинхронных вызовов.

В то же время, хотя рендеринг контента на стороне клиента довольно безопасен для робота Googlebot, его можно увидеть:

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

Чтобы быть актуальным, робот Google работает как браузер. Как заявил в 2017 году GoogleBot использует Chrome v.41 для сканирования в Интернете, но он еще не обновлен. Текущая версия Chrome - 66, что означает, что бот не видит все, что видит последняя версия Chrome при сканировании Интернета. Кроме того, с 41 года было выпущено много новых API, и якобы, робот Googlebot не может отображать и индексировать страницы, основанные на этих API.

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

Решение

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

Соглашения SPA хороши для UX, но могут работать неправильно, если не настроены правильно. Одним из таких изменений является рендеринг на стороне сервера .

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

Принцип SSR основан на архитектуре SPA рендеринга страницы на веб-серверной части во время обмена запросами и ответами. Обычно это достигается путем запуска веб-приложения через объектную модель виртуального документа (VDOM).

Когда состояние приложения изменяется, VDOM преобразуется в строку кода HTML, которая затем внедряется в страницу и отправляется в ответ клиенту. На стороне клиента JavaScript распределяет полученные данные по существующей оболочке.

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

В то же время SSR может иметь некоторые недостатки:

• Расходы . Реализация SSR требует намного больше времени и, следовательно, денег.
• Ограниченная внутренняя среда . SSR работает только с Node.js. Функциональность бэкэндов среды, отличной от Node (например, V8 Javascript Engine для PHP или React предварительного рендеринга через RPC ) функционален, но все же достаточно минимален.
• Громоздкий код . Код SPA должен быть способен работать как в клиентском браузере, так и в серверной среде JavaScript с точки зрения API и объектов.
• Сложные взаимодействия пользовательского интерфейса . Объем кода JavaScript, необходимый для соблюдения современных принципов пользовательского интерфейса, практически сводит на нет преимущества SSR. Лучше использовать статическую оболочку приложения.
• «Шесть из полутора десятков других» . SPA будет иметь дополнительную нагрузку на запросы, которая в зависимости от типа содержимого может замедлить ответы, по крайней мере, при начальной загрузке кэша.

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

Вам нужен ССР или нет?

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

Чтобы определить ваши дальнейшие действия в отношении SSR, рассмотрите следующее:

Фокус вашей деятельности

Ценность вашего SPA должна быть основана на текстовом содержании или производительности. Другими словами, ориентировано ли ваше приложение на контент или на действия.

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

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

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

Аутентификация

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

Благодаря многолетнему опыту работы в Интернете, мы привыкли к определенным вещам, таким как ситуация запрос-ответ. Мы не ожидаем немедленной реакции от человека. Вот почему у нас есть это? Точно так же мы можем допустить перезагрузку страницы, если сделаем правильный ввод. Войдите или войдите в систему с таким входом.

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

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

Большая загрузка первой страницы

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

СПА, использующее глубокую связь для продвижения, может выиграть от SSR .

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

Ключевые слова и социальный обмен

Как мы уже говорили, Googlebot может выполнять JavaScript, анализировать и ранжировать SPA. Не все веб-сканеры способны сделать это, но все они могут работать с ответами на контент от сервера.

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

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

Инструменты БСО

Из-за большого спектра переменных SPA, где можно использовать SSR или частичную SSR, нет лучшего способа настроить SSR, чем вручную. Большая часть SSR выполняется в таких средах JavaScript, как Ember, React или Angular. Как мы знаем, SSR важен для одностраничных приложений, полагающихся на такие структуры, когда поисковая оптимизация важна для бизнеса, или первоначальный рендеринг контента имеет значение.

Ember Fastboot 1.0

FastBoot запускает ваше веб-приложение Ember через Node.js и отвечает исходным HTML, который затем запускается в браузере.

ReactDOMServer

ReactDOMServer является частью React API. Его целью является рендеринг компонентов в строки HTML. Будучи все еще в работе, этот инструмент требует большой ручной работы с библиотеками React Router и Redux, чтобы заставить их работать в условиях частичного рендеринга серверных / клиентских приложений.

Vue.js & Nuxt.js

Vue.js работает как связующее звено между сервером Node.js и кодом SPA. Процесс загрузки приложения VueJS в браузер называется гидратацией . Nuxt является основой для создания универсальных приложений с Vue.js проще. Он направлен на решение задачи по настройке использования SSR с Vue.js.

Угловой универсальный

Угловой универсальный это промежуточное ПО, которое живет между Angular и Node.js. Проще говоря, AU - это «Рендеринг на стороне сервера для приложений Angular», который объединяет в себе высокую производительность и UX SPA, а также SEO-оптимизацию статического веб-сайта.

Takeaways

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

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

В 2017 году мы стали свидетелями растущего интереса разработчиков к состоянию SSR в различных средах, не только в JavaScript. Основные структуры, такие как Ember и Angular, которые охватывают всю архитектуру SPA, заинтересованы в интеграции в них жизнеспособного решения по БСО.

В то же время существуют многообещающие сторонние проекты, такие как Next.js и Nuxt.js, которые стремятся создать прочную структуру БСО в существующих рамках.

Похожие

Комментарии