Перевод статьи с портала MOZ.
Сегодня лишь небольшая часть URL-адресов проходит двойное препятствие, установленное Core Web Vitals для получения высокого рейтинга в выдаче Google:
- Превышение пороговых значений по всем трем показателям Core Web Vitals.
- Возможность отправить данные CrUX в Google, чтобы уведомить систему об этих показателях.
К маю, когда изначально планировалось запустить обновление, лишь 9% URL-адресов могли бы преодолеть установленную планку. К августу 2021 года их количество составило уже 14%.
В предыдущей статье автора можно посмотреть графики и гистограммы, показывающие, что лишь малая часть сайтов смогла преодолеть все пороговые значения Core Web Vitals. (Примеч. Ant-team.ru)
Уже одного этого было достаточно, чтобы Google отложил свое обновление или хотя бы сделал его менее радикальным. Но есть еще одна важная проблема, которая, как я полагаю, могла предостеречь Google от использования Page Experience в качестве основного фактора ранжирования. Речь идет о ненадежных показателях.
Ненадежные метрики
Очень сложно выразить пользовательский опыт миллионов людей с помощью нескольких простых метрик. В любом случае, решение Google вызывает множество вопросов. Мое главное обвинение состоит в том, новый алгоритм не только игнорирует многие раздражающие действия сайтов, но и активно стимулирует их.
Позвольте внести ясность: я уверен, что пользовательский опыт, измеренный с помощью Core Web Vitals (CWV), во многом коррелирует с хорошим восприятием страницы. Однако слишком большие возможности для маневра и достаточно размытые критерии по сути сводят на нет роль восприятия страницы как фактора ранжирования. На мой взгляд, в определенной степени Google сам стал заложником созданной им ситуации.
Largest contentful paint (LCP)
Это, пожалуй, наименее противоречивый из трех новых показателей, поскольку является по сути косвенной характеристикой скорости загрузки страницы. В частности, LCP измеряет время, необходимое для загрузки самого большого элемента. Однако именно этот «самый большой элемент» и вызывает множество вопросов.
Взгляните, например, на домашнюю страницу блога Moz. Вот скриншот, который мы сделали практически в тот самый день, когда первоначально планировался запуск CWV:
Рисунок 1. Домашняя страница блога Moz
Какой элемент, на ваш взгляд, здесь самый большой? Возможно, изображения? А может, заголовки статей или аннотации?
Кроме того, в наборе данных CrUX самый большой элемент может варьироваться в зависимости от типа устройства. Так, для стандартного мобильного пользовательского агента (Moz Pro использует Moto G4) таким элементом будут верхние строчки («Лучшие специалисты, врачи и другие эксперты…»). На компьютере это могут быть заголовки страниц — в зависимости от их длины. В этом и заключается загвоздка: всегда важно учитывать устройство, с которого выполняется загрузка. Но даже в этом случае не совсем очевидно, какой элемент будет считаться самым большим.
Если хотите убедиться самостоятельно, вы можете настроить кампанию для Moz.com в Moz Pro и проверить показатели в инструменте Site Crawl.
Существует две причины, по которым LCP оказывается особенно бесполезным при сравнении.
1. Страницы имеют очень разную структуру
К тому же, важность «самого большого элемента» сильно варьируется. Иногда это несущественный текстовый блок, как в описанном выше случае с Moz. Иногда это действительно главный компонент страницы. А очень часто речь идет о простом уведомлении о cookie, как в примере от Ebuyer:
Рисунок 2. Пример от Ebuyer
Такой подход многим кажется несправедливым (с тем же успехом можно сравнивать яблоки с апельсинами) и в ряде случаях вынуждает сосредоточиться на произвольных элементах.
2. Легкая манипуляция
Когда несколько самых больших элементов имеют одинаковый размер (как в случае с Moz), есть большой соблазн увеличить тот из них, который загружается наиболее быстро. Это мало повлияет на пользовательский опыт, но улучшит LCP.
First Input Delay (FID)
First Input Delay — это гораздо более сложный для понимания показатель. Он фиксирует количество времени, необходимое для обработки первого действия пользователя (считаются клики по интерактивным элементам, но не прокрутка или увеличение) с момента, когда браузер начинает обработку этого действия. Таким образом, фактическое время, необходимое для завершения обработки, не имеет значения — это просто задержка между действием пользователя и началом обработки.
Естественно, если пользователь пытается нажать на какой-либо элемент, пока страница все еще загружается, то это отставание будет значительным. С другой стороны, если взаимодействие произойдет намного позже, скорее всего, страница достаточно быстро отреагирует
Таким образом, у многих возникнет желание любыми средствами отложить первый клик пользователя. Звучит парадоксально, на самом деле это может защитить пользователя от всплывающих окон и других элементов, блокирующих доступ к контенту. Однако, проявив значительную долю цинизма, мы могли бы оптимизировать эту метрику, максимально усложнив нажатие на элементы и снизив их интерактивность. Затрудненная навигация помогает нам выиграть время, пока страница не загрузится.
Кроме того, стоит помнить, что FID нельзя измерить в лабораторных условиях, поскольку здесь очень важен человеческий фактор. Вместо этого Moz Pro и другие инструменты (в том числе предоставленные Google) используют метрику Total Blocking Time, которая имитирует ситуацию, как если бы пользователь немедленно попытался на что-либо нажать.
В целом, если сравнивать этот показатель с Largest Contentful Paint, то FID, на мой взгляд, — более справедливая метрика. Ведь здесь игра с системой может обернуться крупным поражением. Однако, определенный дисбаланс все-таки прослеживается. Так, у страниц навигации будет меньше шансов добиться хороших результатов, чем у страниц с контентом. Дело в том, что на странице навигации, хаба или категории пользователи, как правило, стремятся совершить действие как можно быстрее. Однако можно привести довольно логичный контраргумент — страницы навигации сами по себе являются достаточно плохим результатом поиска. Так что вполне может быть, что все это — преднамеренная задумка Google.
Cumulative layout shift (CLS)
И, наконец, Cumulative Layout Shift — еще один показатель, который многими был хорошо воспринят. Никто не любит неожиданные сдвиги страницы, особенно когда мы уже читаем текст или пытаемся нажать на какой-либо элемент страницы. Но дьявол кроется в деталях — CLS фиксирует максимальное изменение за «сеанс», продолжительность которого составляет 5 секунд.
Если упустить из виду, что в данном контексте Google использует слово «сеанс» в очень нетипичном значении, то главная проблема заключается в следующем — CLS не регистрирует самых злостных нарушителей.
А именно:
1. Реклама в середине статьи, встраивание в социальные сети и прочее часто находятся в нижней части страницы, поэтому не фиксируются метрикой.
2. Всплывающие окна и другие раздражающие пользователей вещи часто появляются с определенной задержкой, минуя 5-секундное «окно». (К тому же, все это можно настроить так, чтобы не засчитывать сдвиг макета!)
В этом году на MozCon я поделился следующим примером от Guardian. Причем это никак не повлияло на их показатели CLS (следует отметить, довольно хорошие):
Рисунок 3. Пример от Guardian
Таким образом, в лучшем случае эта метрика не замечает злостных нарушителей, которых она, несомненно, пытается выявить. В худшем случае, это вновь стимулирует недобросовестное поведение владельцев сайтов. Например, я могу отложить загрузку какого-нибудь надоедливого элемента на моей странице, чтобы он появился после того, как пройдут указанные 5 секунд. Это будет еще сильнее раздражать пользователей, но улучшит мои результаты.
Что дальше?
Мы помним, что Google несколько нерешительно относился к развертыванию Core Web Vitals в качестве фактора ранжирования, откладывая выход обновления. Вероятно, причиной тому были перечисленные выше проблемы. Мы ожидаем, что в будущем Google продолжит настройку этих показателей и добавит новые.
Ведь как представители Google заявили в мае прошлого года, они планируют ежегодно вводить новые сигналы, а также открыто обсуждают улучшение метрики Responsiveness («Отзывчивость»). В конечном итоге, не следует чрезмерно оптимизировать или цинично манипулировать текущими показателями — скорее всего, вы сами пострадаете от этого в будущем.
В следующей статье мы рассмотрим влияние Core Web Vitals на позиции в органической выдаче.
Автор: Том Кэппер
P.s. подписывайтесь на наш телеграм-канал t.me/seoantteam. Мы публикуем только полезные материалы. Например, руководство по Google Alerts: как настроить оповещения для построения ссылок. Или статья о том, как Google использует отличительные характеристики сайтов для классификации по параметрам E-A-T.
