{"id":13654,"url":"\/distributions\/13654\/click?bit=1&hash=7a7aa21667aefd656b6233efba962ecbef616dfd5ac100a493b4b5899b23ff1f","title":"\u041c\u044b \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u043b\u0438 \u0440\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u0442\u044c, \u043a\u0442\u043e \u0442\u0430\u043a\u0438\u0435 \u00ab\u043a\u0440\u0435\u0430\u0442\u043e\u0440\u00bb \u0438 \u00ab\u043f\u0440\u043e\u0434\u0430\u043a\u0442\u00bb","buttonText":"\u0421\u043c\u043e\u0442\u0440\u0435\u0442\u044c","imageUuid":"32086418-934b-5de5-a4ef-6425a84c490a","isPaidAndBannersEnabled":false}
SEO
Николай Фетюхин

Как не потерять поисковый трафик, внедряя технологии SPA

Одностраничные приложения (SPA, single page application) быстро становятся стандартом веб-разработки. На эту технологию переводят свои ресурсы такие техногиганты, как Facebook, Google, Яндекс, Mozilla, Netflix. Она подходит для интернет-магазинов, СМИ, корпоративных порталов и большинства других типов сайтов. От лица агентства-интегратора MST сегодня расскажем про достоинства и недостатки этой технологии и разберем несколько кейсов.

Достоинства и недостатки

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

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

Конечно, идеальных технологий не существует, и у SPA есть свои минусы.

  • Одностраничные приложения уязвимы для хакерских атак с использованием XSS (межсайтового скриптинга)
  • В основе SPA -- JavaScript, если пользователь отключил его в браузере, он не сможет взаимодействовать с сайтом. Впрочем, отключает его незначительная доля пользователей (около 1%).
  • Пользователи с устаревшими версиями браузера увидят вместо сайта пустой экран. В некоторых нишах (например, бухгалтерия, финансы или банки) процент пользователей со старым оборудованием или ПО достигает 30-35%.
  • В первый раз сайт может открываться дольше, чем хотелось бы: для начала работы в браузере пользователя должны загрузиться объёмные и «тяжёлые» фреймворки.

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

Progressive Web Application: полезная надстройка над SPA

Ещё один весомый плюс SPA -- возможность использования PWA. Это плагин плюс набор параметров на сервере, которые добавляют сайту дополнительные функции. Главные из них -- продвинутое кеширование и возможность сохранить сайт как приложение на смартфоне.

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

Еще одной важной фишкой является работа форм офлайн. Введенные в форму данные сохраняются и отправляются на сервер при подключении к интернету. Больше не будет обрывов конверсионной воронки из-за слепой зоны в метро или в лифте.

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

Потенциально критичная проблема

Самая главная проблема SPA, из-за которой при неправильной реализации можно потерять большую долю органического трафика на сайт, состоит в том, что одностраничные JS-приложения не индексируются большинством поисковых систем. Роботы Яндекса работают на основе устаревшего движка Chromium 41, который не поддерживает технологию CSR (Client-Side Rendering, рендеринг на клиенте). Именно эта технология обеспечивает «сбор» страницы в браузере пользователя. Заходя на сайт, робот поисковой системы видит лишь белый экран.

Выход в том, чтобы проводить рендеринг заранее, до обращения браузера к серверу, напрямую на сервере. Для этого используется технология SSR: Server-Side Rendering, (серверный рендеринг). На сервере эмулируется браузер, поддерживающий CSR, в нём рендерится HTML-страница и отдается в браузер пользователю, а также индексирующему роботу.

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

Как можно оптимизировать работу SPA

«Тяжелые» динамичные блоки дизайна можно оставить рендериться на стороне клиента, а самые важные блоки с текстовым контентом и инфографикой нужно максимально облегчить и рендерить на сервере. Внешние скрипты тоже придётся оптимизировать: часть запускать асинхронно, часть кешировать на сервере, какие-то объединить по возможности.

CSS-стили разносятся по разным файлам в зависимости от важности и выстраиваются в очередь загрузки. Для подгрузки изображений первого экрана и другого мультимедиа-контента лучше использовать CDN (сontent delivery network, распределённая сетевая инфраструктура для доставки контента, которая берет на себя оптимизацию доставки файлов), а также подключить сервисы автоматического сжатия изображений по форматам, размерам, качеству и весу.

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

В некоторых случаях можно отдавать пользователям CSR-версию сайта, а роботам поисковых систем -- SSR-версию. Но для использования этого метода нужно провести анализ рисков: мы теряем пользователей устаревших браузеров, пользователей некоторых мобильных приложений; при долгой загрузке сайта в сетях edge или 3g пользователь будет какое-то время видеть пустую страницу. Наконец, могут появиться проблемы с некорректным определением user-agent’ов, в результате чего уже перед поисковым роботом откроется пустая страница.

Рекомендации поисковых систем

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

Сотрудники Яндекса не скрывают, что их поисковые роботы пока так и не подружились с SPA.

Общение с сотрудниками Яндекса на тему поддержки SPA

Кейс «Уралсиб»: возврат поискового трафика и рост на 70%

Заказчик, представляющий банк «Уралсиб», пришёл к нам с жалобой на падение трафика из поисковых систем почти вдвое после работы предыдущего подрядчика. Их SPA-сайт вообще не индексировался Яндексом, а Google индексировал его с задержками и не полностью. В первую очередь мы настроили серверный рендеринг страниц, продумав баланс между количеством индексируемого контента и скоростью рендеринга.Затем исправили ошибки HTML и CSS-кода, устранили все битые ссылки и 301-редиректы, навели порядок в мета-тегах. Выстроили систему rel=«canonical» на всех html страницах (закрыв дублирующиеся разделы сайта). Настроили главное зеркало сайта и убрали дубли главной страницы. Мы составили семантическое ядро и разработали на основе него новую структуру сайта в виде гигантской mind-карты. Тексты оптимизировали под продвигаемые запросы. Проверили внешние ссылки, избавились от некачественных, договорились о гостевых постах с авторитетными новостными ресурсами. Уже в течение первого месяца работы, после устранения основных проблем удалось не только остановить падение трафика на сайт, но и получить получить рост. Дальнейшие работы вывели сайт на лучшие показатели за все время существования.

Кейс Дом.ru: KPI по поисковому трафику выполнен на 115%

У провайдера Дом.ru сложная сеть сайтов и сервисов: 2 основных домена, 54 региональных поддомена и множество технических ресурсов. Сеть построена на нескольких самописных движках на нескольких языках программирования. В ней множество независимых элементов управления, связанных между собой с помощью микросервисов.

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

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

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

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

Работа над скоростью загрузки оказалась крайне затруднена из-за объема внешних интеграций, JS и CSS, которые необходимы для поддержания всей инфраструктуры проекта. Совместно с разработчиками мы максимально оптимизировали работу сайтов на SPA, сократили структуру DOM, закешировали большую часть внешних скриптов, интеграций и т.д.

При очередном обновлении на сайте выключился серверный рендеринг SPA-разделов, что привело к резкому падению органического трафика. Повторная настройка серверного рендеринга на таком огромном количестве страниц заняла бы много времени, поэтому мы решили срочно поднять AMP-версию наиболее трафиковых и конверсионных страниц (по ним уже велись разработки ранее), тем самым спасти контент хотя бы для мобильной версии, закешировав его в ПС. AMP, Accelerated mobile pages -- технология создания облегчённых веб-страниц, которые быстро открываются на мобильном устройстве из кеша Google. Параллельно с работами по возвращению и доработке SSR мы начали разработку инструмента автоматического тестирования корректности рендеринга.

KPI по объему трафика, привлекаемого из органического поиска, был выполнен на 115%. Поисковый трафик вырос на 20% по сравнению с аналогичным периодом прошлого года, при снижении частотности брендовых запросов.

0
16 комментариев
Написать комментарий...
Igor Vasilev

Отличная статья! Спасибо

Ответить
Развернуть ветку
Николай Фетюхин
Автор

Спасибо! Мы старались!

Ответить
Развернуть ветку
Алексей из LOADING.express

AMP загружается же только с выдачи из Гугл? Вы считали конверсии с платного трафика?

Отлично, что конверсию измерили. Если сейчас конверсия так выросла, то что будет у ДОМ.РУ, если их основная версия сайта будет загружаться чуть быстрее, чем 15,7 секунд до полной интерактивности страницы!))

Ответить
Развернуть ветку
Алексей из LOADING.express

Банк Уралсиб.

Скорость загрузки с июля 2020 увеличилась в среднем на секунду.
Минимально 4.504 сек.
Максимально 6.282 сек.

Из самых топовых банков, Уралсиб на 21 месте по скорости загрузки сайта.
(https://loading.express/banks.html)

По скорости отображения и интерактивности  —  совсем грустно. В следующем комментарии видео (в одно сообщение нельзя).
Результат хороший, тот же банк Возрождение загружается до 60 секунд на 4х тротлинге (как средний андроид в 3G) и под 20 секунд на 2х тротлинге (средний айфон на 3G)... 

Ответить
Развернуть ветку
Николай Фетюхин
Автор

Спасибо за замечание. Это комплексный вопрос, на проекте много интеграций с внутренними системами, совместно с клиентом работаем над улучшением показателей.

Ответить
Развернуть ветку
Алексей из LOADING.express

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

Ответить
Развернуть ветку
Алексей из LOADING.express

Сайт агентства MST довольно отзывчивый и красивый. Можно сделать его шустрее, точно.

Ответить
Развернуть ветку
Александр Косарчук

Статья 10% реклама 90% сразу видно, что писал не разработчик, а SEO специалист. Не уверен, что все так плохо в 2020 с SPA, но вам виднее

Ответить
Развернуть ветку
Сергей Игоревич

Про поисковый трафик для SPA-сайтов и должен писать SEOшник, нет?

Ответить
Развернуть ветку
Александр Косарчук

Про трафик да, но про технологии SPA хотелось бы почитать от разработчика, с примерами и описанием конкретных кейсов, вроде SSR, как написал автор. 

Ответить
Развернуть ветку
Николай Фетюхин
Автор

Спасибо за мнение! Мы хотели описать и показать кейсы с точки зрения SEO, указать ошибки и решения на наших реальных проектах. 

Техническую статью, возможно, сделаем позже отдельно и на другой площадке (Хабр).

Ответить
Развернуть ветку
eeeMan.rg Rori

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

Ответить
Развернуть ветку
Николай Фетюхин
Автор

В статье, основной проблемой мы выделили - потерю поискового трафика, а не скорость загрузки.

Ответить
Развернуть ветку
Vladimir Osipov

По-моему, оптимальный вариант это преобразовывать SPA в набор статических html+css страниц каждый раз при загрузке скомпилированного проекта на сервер, и при этом делать их hydration уже в js коде. Тогда поисковый робот видит сайт как человек, а у человека визуально всё загружается мгновенно. И все довольны. Вот, как пример: https://xroom.app

Ответить
Развернуть ветку
Alexey Novoricev

Я если правильно понял, то SPA загружается отдельной иконкой прям в мобилку и из приложения открывает url ? Я просто не совсем понимаю, как это связано с АМР ?) 
На счёт преобразования статики хтмл и цсс можешь посмотреть, как мы реализовали это на практике: проект
Стоит отдать должное, это решение работает) 

Ответить
Развернуть ветку
Николай Фетюхин
Автор

Добрый вечер, Алексей!
Это не совсем связанные вещи, если вы упоминаете технологию относительно статьи, то это была экстренная мера :)

Ответить
Развернуть ветку
Читать все 16 комментариев
null