Урок 11: Поведение пользователей и технические параметры (24 мин.)

КОНСПЕКТ УРОКА:

Добрый день. На прошлом уроке мы с вами начали говорить о пользовательском поведении и учёте его поисковыми системами.

Пользовательское поведение во многом зависит от того, насколько удобно посетителю пользоваться сайтом, насколько сайт быстро загружается, насколько всё видно и понятно. Эти вопросы не зависят от содержания сайт: контента, информации, товаров и цен на сайте. Это связано с технической реализацийей сайта и учетом удобства пользователя при проектировании сайта: UX (User Experience) и UX (User Interface).

Поисковые системы оценивают технические моменты сайта и учитывают при ранжировании. Две основные темы, над которыми поисковой системы работают последние годы:
1. Удобство для пользователей мобильных устройств (Mobile Friendly).
2. Скорость загрузки (в первую очередь на мобильных устройствах).

Google и Яндекс - инструменты и показатели

В Яндекс-Вебмастер есть специальный инструмент "Проверка мобильных страниц" - насколько сайт адаптирован под мобильные. Он проверяет ряд параметров и выдает результат - удобно здесь будет посетителея или нет.

В Яндекс-Вебмастер ещё есть инструмент, который контролирует "Индекс скорости сайта". Если скорость сайта хорошая, то такого сообщения не будет. Если со скоростью загрузки проблемы - будет показано подобное сообщение в "Сводке" при заходе в Яндекс-Вебмастер.

Что такое "хорошая скорость загрузки" для Яндекса? Здесь указано, что ориентиром по скорости загрузки страницы на мобильное устройство является 2 секунды. По клику на "Проверьте" можно посмотреть предложения Яндекса поускорению сайта.

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

У Google есть свой инструмент для тестирования mobile friendly - насколько сайт оптимизирован под мобильные устройства. Вот адрес этого инструмента: search.google.com/test/mobile-friendly.

В показанном примере страница не оптимизирована под мобильные устройства. Сразу указаны ошибки, которые привели к такому выводу:
- слишком мелкий шрифт, неудобно для прочтения;
- интерактивные элементы (ссылки, кнопки) расположены слишком близко, в них будет не удобно попадать пальцем.

В разделе "Удобство для мобильных" Google Search Console есть расширенная информация по состоянию оптимизации сайта под мобильные устройства. На экране вы видите:
- количество страниц сайта (зеленым - оптимизированы, красным - не оптимизированы);
- ошибки, которой встречаются (можно кликнуть по строке ошибки и там будет полный список неоптимизированных страниц с этой проблемой).

Перейдем в инструмент "Основные интернет показатели" Google Search Console. Здесь мы видим скорость загрузки страниц, отдельно на мобильных и отдельно на десктопных устройствах. Перед вами временной график, показывающий как менялось количество страниц с проблемами скорости загрузки и ниже - список обнаруженных проблем по скорости загрузки.

У Google очень серьезное отношение к скорости загрузки. Вместо одного показателя у Яндекса, Google прказывает несколько параметров:

LCP (Largest Contentful Paint) - время до момента, когда на экране отрисована большая часть контента страницы и пользователь уже видят, с чем он имеет дело.

FID (First Input Delay) - время после начала загрузки, через которое пользователь может начать взаимодействовать со страницей, т.е. будут кликабельны кнопки и ссылки.

CLS (Cumulative Layout Shift) - движение элементов по экрану во время отрисовки. Т.е. время, когда элементы перестанут двигаться по экрану и займут положенные места.

В этом столбце комментариев указано, с каким из трех показателей связана проблема.

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

Пример: раздел "Основные интернет показатели", график скорости страниц. Показано: "зеленым" - сколько страниц с высокой скоростью загрузки; "жёлтым" - средняя скорость, недостаточная; "красным" - совсем плохо.

В начале мая я обнаружил появление проблемы с загрузкой ряда страниц. Выяснил, что проблема оказалась связана с переполнением лога поведения посетителей на сайте. Это увеличивало время обращения к базе данных и, соответственно, время до загрузки контента в браузер. Проблему устранил. Для основных посадочных страниц получилось поднятие на две позиции в Google (примерно с пятой на третью). А страницы, которые находились по запросам на второй странице выдачи - поднялись в низ первой страницы.

У Google есть ещё несколько отдельных инструментов, которые глубоко анализируют скорость загрузки.

Первый - Google PageSpeed Insights. Он доступен вам не только для ваших сайтов. Вы можете протестировать любую страницу на любом сайте для сравнения с конкурентами. В Google PageSpeed Insights очень подробно расписан каждый этап загрузки и отрисовки страницы: от появления первых элементов на экране (FCP) до отрисовки полностью работоспособной страницы. Внизу в виде вот таких превьюшек показаны все этапы отрисовки страницы.

Время по скорости отрисовки отдельных этапов Google PageSpeed Insights получает из браузера Google Chrome - т.е. это время у реальных пользователей вашего сайта.

Вот здесь вы видите пример, статистику за последние 30 дней - с какой скоростью происходила загрузка у различных пользователей. Вы видите что первая отрисовка контента у 50% пользователей прошла замечательно; для 40% пользователей - хотелось бы побыстрее; у 10% пользователей процесс шел непозволительно медленно.

Эта техническая проблема у 10% пользователей, кроме SEO, имеет последствие для эффективности продаж.

10% привлеченных потенциальных покупателей могли не дождаться загрузки и уйти с сайта не совершив покупку. Вполне возможно, что для роста продаж компании на 10% достаточно устранить узкие места в загрузке сайта. И это обойдется существенно дешевле, чем расширить ЦА на 10% за счет рекламы или обеспечить рост на 10% эффективности отдела продаж.

Аналогично относительно остальных показателей скорости загрузки. Очень важен вот этот показатель "Первая задержка ввода" (FID). Как только на экране появляется изображения элементов страницы, пользователь пытается начать с ними взаимодействовать, кликать (помните про порог в 2 секунды от Яндекса?).

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

Как вы видите в этом примере - 81% пользователей не слишком удовлетворён скоростью появления кликабельности интерфейса. Пользователи будут кликать, и если сайт не реагирует - могут уходить с него не дожидаясь. Это прямые потери для продаж.

Чем дольше идет загрузка страницы - тем больше отказов пользователей.

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

Следующий инструмент Google Chrome LightHouse, которые встраивается в браузер Google Chrome.
Google Chrome LightHouse можно вызвать нажав клавишу F12. Вот в верхнем меню пункт LightHouse.

С помощью Google Chrome LightHouse вы можете протестировать любой сайт на ряд параметров.
Основные возможности Google Chrome LightHouse повторяют возможности Google PageSpeed Insights, но также в нем есть и дополнительные параметры, такие, как: общий показатель скорости, показатель доступности элементов и даже пункт seo (насколько страница seo оптимизирована).

Есть и важное откличие: Google PageSpeed Insights показывает параметры, полученные на основе статистики от реальных пользователей браузеров - а Google Chrome LightHouse показывает параметры, программно рассчитанные на основе модели загрузки.

В 2020 году Google анонсировал, что вводит новый важный параметр ранжирования PageExperience (пользовательский опыт, пользовательское поведение), который будет определять ранжирование наряду с релевантностью запросу. PageExpirience будет характеристикой конкретной страницы, которая ранжируются. PageExpirience включает в себя:
- защищенный протокол доступа https;
- адаптированность сайта к мобильным устройствам;
- и Core Web Vitals, который рассчитывается по скорости загрузки, по трем показателям, о которых мы говорили раньше.

Особенности технологий разработки сайтов и SEO

Почему именно сейчас стало так актуально выделение нескольких уровней по времени загрузки странице?

Это связано с неприятными особенностями современной технологии web-разработки.

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

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

Как из кирпичиков, браузер собирает страницу для пользователя из многих блоков кода, получаемых от многих серверов. Причем, делает это не за один раз, а за несколько проходов:
- В первом коде с "сервера 1" указано подгрузить "кирпичик 2" с "сервера 2".
- В "кирпичике 2" может быть указано подгрузить "кирпичик 3" с "сервера 3", и т.д.
Вы можете посмотреть этот процесс для любой страницы в Google Chrome, нажав F12 и выбрав в открывшемся окне пункт Network (и перезагрузить страницу по Ctrl+F5).

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

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

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

Сейчас я покажу вам пару примеров, как такие проблемы загрузки могут выглядеть.
Вот сайт компании. У них есть форма заводим имя, телефон и нажимаем "отправить". И ничего не происходит - форма не отправляется.
Еще пример: сайт другой компании. Их продукт - для поискового продвижения. Здесь есть кнопка "связаться с нами". Нажимаем - и ничего не происходит.

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

Что важно знать сеошнику о проблемах процесса разработки сайта

Чаще всего сайты делаются на типовом программном обеспечении CMS - Content Management System, которые производится специализирующимися компаниями (а не самими веб-студиями) и в коробочным виде продаются всем желающим. Таких популярных CMS - несколько десятков. На основе CMS веб-студии проводят разработку и собирает сайт для клиента силами своих программистов.

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

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

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

Вот в примере team leader одной из веб-студии рассказывает, что после того, как проверен код и выявлено, что его нужно оптимизировать (как он пишет "еще недельку на полировку кода"); но поскольку, как отдельную работу клиент это не оплачивает, в веб-студии исправляют только самые актуальные проблемы. И отдают сайт клиенту без оптимизации.

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

Недавно ко мне обратился старый приятель-предприниматель. Ему сделали уже третью сборку сайта, утверждая, что на всё более новых технологиях. И технологий и движков, действительно, напичкано в сайт всё больше. Но Google LightHouse показывает, что каждая из трех вариаций сайта - заметно тормознее предидущей. Приятель этого не понимает, поскольку разработчики сдавали ему работу на быстром оборудовании. И у него, как у заказчика, смартфон и ноутбук дорогие и быстрые.

Ещё пример на экране: коллеги пишут о том, сколько времени занимает тестирование сайта. Вот в этом диалоге менеджер веб-студии, который организует работу, пишет что составление ТЗ (технического задания) и тестирование сайта после разработчиков, может занимать в несколько раз больше времени, чем, собственно работа программистов. Это если делать качественно и если заказчик готов платить за качество.

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

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

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

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

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

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

Вот здесь - это эмуляция вида сайта на мобильном телефоне в стандартном Google Chrome (простейшая проверка). А здесь фотографии на моих двух смартфонах для тестирования.
Как вы видите, дизайн и меркетинг разрушаются программными ошибками:
- полностью съезжает логотип, не читабелен;
- вообще не видно их основного товарного предложения (УТП) с их конкурентными преимуществами.

Какое будет поведение у пользователей, которые перейдут сюда из поиска?
Они перейдут ничего не поймут и закроют браузер. Сайт получит много отказов и будет понижен в мобильной выдаче.

SEO и CMS Content Management System

Кроме проблем с некачественной разработкой без тестирования, на скорость загрузки страниц сильно влияет выбор CMS, на которой строится сайт.

Здесь приведены два графика. Первый - сравнения средней скорости загрузки страниц на различных CMS из исследования компании Pixel Plus. Вот здесь:
- название популярной CMS;
- "зеленым" - процент сайтов, которые были достаточно быстрыми;
- "желтым" - удовлетворительная скорость загрузки;
- "красным" - неудовлетворительная скорость.

Самая популярная на рынке разработки - бесплатная CMS WordPress показала худшие показатели по скорости загрузки!

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

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

А если вам достается в продвижении уже готовый сайт, то вот вы будете серьезно ограниченными возможностями Content Management System и хостинг-провайдера.

Быстродействие сайта на всех этапах

Главное, что вам нужно знать, как будущим оптимизаторам, о быстродействии сайтов. Это от чего будет зависеть финальное быстродействие сайта. Повторим:

1. Первичный код генерируются на сервере, на хостинге. На быстродействие этого этапа влияет:
1.1. Какая CMS используется для сайта.
1.2. Насколько быстро работает хостинг.
1.3. Насколько качественно и добросовестно поработали разработчики серверного программного обеспечения.

2. Данные с сервера передаются через интернет. Здесь на скорость влияет:

2.1. Через какие каналы пойдут данные - как далеко взаиморасположены сервер хостера и устройство, на котором пользователь будет смотреть сайт. Здесь "далеко", не в километрах, а в качестве каналов в цепочке серверов между ними. Последнее время, для ускорения процесса передачи данных для сайтов, используются CDN сети. На серверах CDN сети, расположеных в разных частях мира, дублируют исходный контент. Теоретически, пользователю подгружают картинки или скрипты с ближайшего к нему сервера. Быстрота получения данных должна вырасти. На практике, если такая сеть оказывается медленной для конкретного пользователя, лучше было бы этой технологией не пользоваться.

2.2. Следующий этап, конечный канал, по которому передаются данные клиенту. Wi-Fi в целом, быстрее мобильной связи. Мобильная связь может быть формально очень быстрой. Но если смартфон или модем расположен через несколько высотных домов от вышки сотовой связи, то сквозь бетонные стены скорость передачи будет весьма медленной. Также провайдеры мобильной связи могут понижать скорость интернет-соединения в зависимости от нагруженности (перегруженности) конкретной вышки сотовой связи.

3. Полученные данные "превращаются" в сайт на конкретном клиентском устройстве и в конкретном браузере.

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

3.2. На последнем этапе влияет еще и быстродействие конкретного браузера, о чем, обычно, забывают.

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

Как вы видите, быстродействие этих браузеров отличается почти в 7 раз (между Яндекс-Браузером и Firefox).

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

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

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

Недоступная страница

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

Для того, чтобы убирать подобные ошибки, достаточно пользоваться Google Search Console. Идем в раздел "Покрытие", в котором представлены все страницы, которые исключены из индекса. И указано - по какой причине. Например, есть ошибка сканирования. Мы сюда нажимаем и получаем список страниц. Разбираемся с каждой конкретной страницей.

Получить информацию о недоступных страницах, а также о скорости загрузки первичного кода от сервера (т.е. еще до генерации контента браузером) вы можете с помощью инструментов, о которых мы уже раньше говорили. Это класс инструментов, которые сканируют ваш сайт и делают запросы ко всем страницам сайта. Например, вот это коммерческий инструмент NetPeak. У него есть в интерфейсе блок, посвященный различным проблемам и ошибкам при обращении к страницам. Также здесь есть колоночка с кодом и временем ответа сервера. Или бесплатный Site-Analyzer, него есть такие же показатели для каждой страницы.