Как не потерять поисковый трафик, внедряя технологии 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.
Кейс «Уралсиб»: возврат поискового трафика и рост на 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% по сравнению с аналогичным периодом прошлого года, при снижении частотности брендовых запросов.
Отличная статья! Спасибо
Спасибо! Мы старались!
AMP загружается же только с выдачи из Гугл? Вы считали конверсии с платного трафика?
Отлично, что конверсию измерили. Если сейчас конверсия так выросла, то что будет у ДОМ.РУ, если их основная версия сайта будет загружаться чуть быстрее, чем 15,7 секунд до полной интерактивности страницы!))
Банк Уралсиб.
Скорость загрузки с июля 2020 увеличилась в среднем на секунду.
Минимально 4.504 сек.
Максимально 6.282 сек.
Из самых топовых банков, Уралсиб на 21 месте по скорости загрузки сайта.
(https://loading.express/banks.html)
По скорости отображения и интерактивности — совсем грустно. В следующем комментарии видео (в одно сообщение нельзя).
Результат хороший, тот же банк Возрождение загружается до 60 секунд на 4х тротлинге (как средний андроид в 3G) и под 20 секунд на 2х тротлинге (средний айфон на 3G)...
Спасибо за замечание. Это комплексный вопрос, на проекте много интеграций с внутренними системами, совместно с клиентом работаем над улучшением показателей.
Первая отрисовка быстрая, но до интерактивности слишком далеко. Тут не спасет даже предложение установить приложение, потому что страница не интерактивна из-за блокировки основного потока загрузки.
Сайт агентства MST довольно отзывчивый и красивый. Можно сделать его шустрее, точно.
Статья 10% реклама 90% сразу видно, что писал не разработчик, а SEO специалист. Не уверен, что все так плохо в 2020 с SPA, но вам виднее
Про поисковый трафик для SPA-сайтов и должен писать SEOшник, нет?
Про трафик да, но про технологии SPA хотелось бы почитать от разработчика, с примерами и описанием конкретных кейсов, вроде SSR, как написал автор.
Спасибо за мнение! Мы хотели описать и показать кейсы с точки зрения SEO, указать ошибки и решения на наших реальных проектах.
Техническую статью, возможно, сделаем позже отдельно и на другой площадке (Хабр).
писал какой-то нуб, сейчас уже куча вариантов есть, чтобы отдача с сервера была быстрой, файлы на чанки разделяются и загружаются по мере открытия страниц
В статье, основной проблемой мы выделили - потерю поискового трафика, а не скорость загрузки.
По-моему, оптимальный вариант это преобразовывать SPA в набор статических html+css страниц каждый раз при загрузке скомпилированного проекта на сервер, и при этом делать их hydration уже в js коде. Тогда поисковый робот видит сайт как человек, а у человека визуально всё загружается мгновенно. И все довольны. Вот, как пример: https://xroom.app
Я если правильно понял, то SPA загружается отдельной иконкой прям в мобилку и из приложения открывает url ? Я просто не совсем понимаю, как это связано с АМР ?)
На счёт преобразования статики хтмл и цсс можешь посмотреть, как мы реализовали это на практике: проект
Стоит отдать должное, это решение работает)
Добрый вечер, Алексей!
Это не совсем связанные вещи, если вы упоминаете технологию относительно статьи, то это была экстренная мера :)