Привет! Прежде всего хочу сказать, что я не из тех, кто гонится за SEO или специально подстраивается под требования предпочтения Google относительно того, как должен выглядеть и работать мой сайт. Однако стоит знать, что Google только что прислал мне письмо о необходимости улучшить показатель «Core Web Vital» на моём сайте, который скоро будет сильно влиять на ранжирование:
Вот отчёт по Discourse Meta, где показатели INP немного хуже, чем на моём собственном сайте (372 мс против 208 мс):
Учитывая, что Discourse — это по сути веб-приложение на JavaScript, я предполагаю, что улучшить эти показатели будет непросто. Но с другой стороны, Google, похоже, строит своё ранжирование на версии без JavaScript, которую видят его веб-краулеры, несмотря на заявления об эмуляции телефона Moto G Power…
…поэтому я не особенно верю в то, что определяют их алгоритмы и ранжирование, и не придаю этому большого значения. Но стоит предупредить разработчиков и администраторов сайтов, чтобы они были в курсе.
Привет @rahim123! Улучшение показателя INP — одна из причин перехода анимации навигации по страницам в Discourse с полноэкранного «спиннера» на слайдер. Мы внедрили это изменение в Meta только на прошлой неделе, поэтому пока рано ожидать его отражения в данных опроса веб-метрик Google.
Но будьте уверены: мы внимательно следим за данными и при необходимости внесём дополнительные корректировки.
Огромное спасибо за ответ. Рад слышать, что вы в курсе ситуации.
Я использовал инструмент тестирования живых URL-адресов Google https://pagespeed.web.dev, так что разве это не должно уже учитываться в рейтинге? И поскольку Google видит версию без JavaScript, я не уверен, как он учитывает разницу между спиннером и слайдером? Разве INP не связан с переходом с одной страницы на другую в рамках одного сайта? В таком случае я не совсем понимаю, как он оценивает этот показатель для отдельного URL. Извините за незнание, я далеко не эксперт в этих тонкостях, касающихся архитектуры страниц и последних капризов Google.
Да, ‘PagesSpeed Insights’ и поисковый краулер Google загружают базовую HTML-версию Discourse. К сожалению, эти инструменты по запросу не очень полезны для нас.
Для ранжирования в поиске Google использует реальные данные, собранные от пользователей Chrome на настольных компьютерах и Android. Эти данные доступны публично по адресу Overview of CrUX | Chrome UX Report | Chrome for Developers. К сожалению, между сбором и публикацией данных проходит 1–2 месяца, поэтому нам нужно подождать некоторое время, прежде чем мы сможем увидеть реальное влияние этого нового ползунка загрузки.
Чтобы увидеть данные Google для вашего собственного сайта (или для Meta), перейдите сюда и введите домен: CrUX Dashboard | Chrome UX Report | Chrome for Developers. После загрузки отчета слева появится вкладка INP. Насколько я помню, Google фокусируется на данных «мобильных устройств» для поискового ранжирования, поэтому вам нужно использовать фильтр устройств, чтобы детально изучить их.
Цель — достичь хотя бы 75% оценок «хорошо»: это означает, что значение P75 INP, которое Google использует для поискового ранжирования, будет меньше 200 мс.
В качестве примера могу сказать, что я использую исключительно компонент темы discourse-loading-slider с момента запуска моего сайта. Я всё ещё нахожусь в зоне «требует улучшения».
В частности, страницы, к которым в основном обращаются анонимные пользователи, пришедшие из Google, работают хуже всего. Возможно, это специфично для моего форума, но я подумал, что стоит поделиться этим.
Дэвид, это действительно кажется огромным улучшением, хотя мне нравится старый спиннер Можешь напомнить, какое высокоуровневое техническое изменение подхода здесь позволяет достичь этого улучшения? Где-то это задокументировано?
Со старым спиннером последовательность была следующей:
Щелчок по ссылке
Ember разбирает весь DOM и очищает компоненты от старого маршрута
Спиннер отображается на экране
После завершения сетевого запроса новый маршрут отображается в DOM
Слайдер позволяет пропустить шаг 2. Слайдер отображается сразу, без необходимости ждать дорогостоящего процесса разборки.
Стоит уточнить: основной мотивацией для нас при смене настроек по умолчанию является улучшение пользовательского опыта (UX). Улучшение метрики INP тоже приятно, но это не главная причина изменений.
Очень важно отметить, что INP повлияет на ранжирование сайта только в марте 2024 года, поэтому улучшения, над которыми мы работаем сегодня, успеют пройти несколько итераций до того, как они начнут влиять на Google.
Для данных вашего собственного домена, например meta.discourse.org, в Google Search Console всегда есть актуальный отчёт, скрытый внутри раздела «Опыт» → «Основные веб-показатели» → «Мобильные устройства (открыть отчёт)». Прокрутите вниз до пункта «Проблема INP: дольше 200 мс (мобильные устройства)».
Редакция: Это относится скорее к категории событий с низкой вероятностью, но высоким воздействием. INP учитывает только 75-й перцентиль (p75).
На показатель INP могут влиять процедуры «приготовления» постов (= функциональные улучшения через JS при загрузке) в ядре Matomo или плагинах, которые выполняют «тяжелые» задачи на JavaScript, вызывая значительное «блокирование рендеринга».
Особенно когда пользователь переключается на другую тему, одновременно «обрабатывается» около 10–20 постов.
В таких случаях всегда полезно разделять задачи для отдельных постов на отдельные вызовы setTimeout(), чтобы браузер мог выполнять перерисовку между отдельными задачами, а не ждать завершения всего процесса.
Например, что-то вроде этого:
var initializeSliderSlickItem = function (item) {
/* здесь выполняется фактическая инициализация */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
Вы уверены в этом? При переходе от одной темы к другой следующая отрисовка будет отображать загрузчик в верхней страницы, который запускается сразу же.
Редакция: Это относится к категории маловероятных, но высокоэффективных событий. INP учитывает только 75-й процентиль (p75).
… а затем начинается процесс «приготовления». Если пользователь кликает по чему-либо во время выполнения задачи «приготовления» в Discourse, Google измеряет INP как время до следующей отрисовки. Следующая отрисовка может произойти не ранее завершения выполняемой задачи «приготовления».
«Жизненный цикл взаимодействия. Задержка ввода возникает до начала выполнения обработчиков событий, что может быть вызвано такими факторами, как длительные задачи в основном потоке [например, «приготовление»]. Затем выполняются обработчики событий взаимодействия, после чего возникает задержка до отображения следующего кадра».
Google учитывает наибольшее время блокировки отрисовки для INP, если есть несколько блокирующих событий «на протяжении всего жизненного цикла страницы». Жизненный цикл, например:
Поток URL «A» открывается
Показывается спиннер
«Приготовление» постов в потоке «A»
Клик 1: пользователь кликает по ссылке на поток «B»
Показывается спиннер
Загрузка потока «B»
«Приготовление» постов в потоке «B»
Клик 2: пользователь кликает по ссылке на поток «C», пока поток «B» всё ещё находится в процессе «приготовления»
Завершается выполняемое действие «приготовления» в потоке «B» (<-- учитывается в INP для Клика 2)
«INP вычисляется, когда пользователь покидает страницу, и представляет собой единое значение, отражающее общую отзывчивость страницы на протяжении всего её жизненного цикла».
Хорошо, что использование p75 метрики означает, что никому не нужно действительно беспокоиться о сценарии, который вы описали, и он явно не отражает нормальное взаимодействие с Discourse.
Можешь напомнить, какое высокоуровневое техническое изменение подхода здесь позволяет достичь этого улучшения? Где-то это задокументировано?
