Обновление Page Experience анонсировали в мае 2020 года, запускали поэтапно с июня по август 2021-го, и тогда казалось, что миллисекунды решат судьбу банков и клиник в выдаче. Спустя пять лет картина прояснилась. Для страниц YMYL (Your Money or Your Life), где речь о здоровье и деньгах, скорость остаётся вспомогательным сигналом: система сначала проверяет доверие и качество материала, и только потом сравнивает кандидатов по метрикам Core Web Vitals. Разница между 1,8 и 2,5 секунды не вытащит слабую статью на первое место, но способна склонить выбор, когда десять одинаково компетентных страниц делят одну позицию.
Обещания Page Experience и фактические приоритеты через пять лет
В набор сигналов вошли три метрики Core Web Vitals, мобильная адаптивность, HTTPS, Safe Browsing и требование не прятать контент за агрессивными межстраничными окнами. Google в ответах об опыте страниц формулирует прямо: единого сигнала page experience не существует, Core Web Vitals используются системами ранжирования, а остальные аспекты напрямую позиции не поднимают. Там же заявлен главный принцип: поиск стремится показать самый релевантный контент, даже если опыт страницы посредственный.
Практика последующих лет подтверждает иерархию. Общее обновление ядра в августе 2018 года, прозванное Medic, сильно тряхнуло медицинские и финансовые сайты без всяких скоростных метрик: работали сигналы качества и доверия. Система полезного контента, запущенная в 2022 году и встроенная в ядро ранжирования в марте 2024-го, тоже оценивает содержание, а не миллисекунды. Попытки выехать на одних метриках все эти годы заканчивались одинаково: быстрые страницы с пустым содержанием оставались вне выдачи. Для YMYL проекта Core Web Vitals это страховка сильного материала, а не спасение слабого.
Иерархия сигналов для YMYL страниц и реальная цена миллисекунд
Категория YMYL в руководстве для асессоров охватывает здоровье и медицину, лекарства, финансы, страхование, налоги, инвестиции, юридические и гражданские темы. К таким страницам применяется максимальная планка E-E-A-T: опыт, экспертиза, авторитетность и надёжность, причём надёжность (Trust) названа центральным критерием оценки. Статья о симптомах без рецензента-врача не выйдет в топ даже при LCP в 1,2 секунды. Обратный случай тоже реален: авторитетный материал удерживает позиции при неидеальных метриках, пока конкуренты не подтянулись.
Скорость подключается на этапе равных кандидатов. Google описывает это как вклад в успех по запросам, где полезного контента много и выбор между страницами близок. Оценка опыта ведётся постранично, но часть проверок захватывает проект целиком, поэтому систематически медленные шаблоны портят картину всего сайта. С июля 2024 года индексация полностью опирается на мобильную версию страниц, поэтому мобильные пороги и есть рабочие пороги проекта. Планируя бюджет, помните о пропорции: час работы над доверием обычно даёт YMYL проекту больше, чем час работы над миллисекундами. Типичный сценарий: клиника выкатывает новый шаблон с LCP 2,8 секунды, вкладывается в CDN и доводит метрику до 1,9, но страницы без имён врачей и пометки о проверке остаются вне топа, потому что рядом стоит более медленный конкурент с очевидной экспертизой и фамилиями под каждым материалом.
INP на уровне 200 миллисекунд, где финансовые калькуляторы теряют больше всего
Метрика INP с 12 марта 2024 года заменила FID. Пороги: до 200 миллисекунд хорошо, от 200 до 500 требует улучшений, свыше 500 плохо. Значение собирают по 75-му процентилю загрузок страниц, отдельно для мобильных устройств и десктопов. В отличие от FID, INP измеряет отклик на все взаимодействия за весь визит: клики, тапы, нажатия клавиш. Для длинных сессий есть послабление: худшее взаимодействие отбрасывают на каждые пятьдесят, остальные формируют честный 75-й процентиль.
Финансовые страницы уязвимы сильнее контентных: калькулятор ипотеки, ползунок суммы страхования, фильтры по ставкам, формы заявок. Каждый обработчик плюс сторонние скрипты аналитики, теги ретаргетинга, виджеты чатов и библиотеки эквайринга конкурируют за главный поток JavaScript. Задержка складывается из трёх частей: ожидание очереди обработчиков, исполнение кода и отрисовка следующего кадра. Задача длиннее 50 миллисекунд уже считается долгой, поэтому тяжёлые скрипты дробят, обработчики прокрутки помечают как passive, фоновые расчёты уводят в веб-воркеры. Схема выноса тяжёлого расчёта из интерактивной формы выглядит так:
const worker = new Worker('/js/calc-worker.js');
form.addEventListener('input', (event) => {
worker.postMessage({amount: event.target.value, rate: 9.9});
});
worker.onmessage = (msg) => renderSchedule(msg.data);Главный поток остаётся свободным для отрисовки, расчёт графика платежей идёт параллельно. Замер на реальных пользователях делается так:
import {onINP} from 'web-vitals';
onINP((metric) => {
console.log(metric.name, Math.round(metric.value), metric.rating);
});Свойство metric.rating вернёт "good", "needs-improvement" или "poor". Для разбора долгих задач используют панель производительности DevTools и Long Animation Frames API, сторонние теги подключают с задержкой или через режим согласия. Отдельный резерв экономии: отложенная инициализация виджетов чата до первого касания и отказ от счётчиков, которые не нужны решению задач бизнеса.
LCP до 2,5 секунды на первых экранах медицинских страниц
LCP обязан уложиться в 2,5 секунды, значения выше 4 секунд считаются плохими. Кандидатами на роль главного элемента становятся фото врача, снимок процедуры, крупный заголовок услуги. На медицинских сайтах крупнейший элемент почти всегда изображение, и разметка важнее качества сжатия:
<img src="/img/consult.avif" srcset="/img/consult.avif 1200w, /img/consult-m.avif 640w"
width="1200" height="600"
fetchpriority="high" alt="Консультация кардиолога">Атрибут fetchpriority подсказывает браузеру приоритет загрузки, width и height страхуют от сдвигов макета. Картинку первого экрана поднимают в очереди явно:
<link rel="preload" as="image" href="/img/consult.avif" fetchpriority="high">Дальше по списку: форматы AVIF и WebP вместо старого JPEG, preload для критичных шрифтов, раннее соединение с CDN, заголовок Cache-Control, протокол HTTP/3. TTFB держат ниже 800 миллисекунд, иначе прочие оптимизации стартуют с опозданием. Влияет и критический CSS: файл стилей, который браузер обязан скачать до первой отрисовки, сокращают до минимального набора, остальное грузят асинхронно. У шрифтов задают метрику size-adjust, чтобы при подмене системного шрифта на фирменный текст не прыгал по строкам. Для каруселей метрика берёт только первое изображение, последующие слайды не учитываются. Если главный элемент текстовый, критический CSS встраивают прямо в ответ сервера, чтобы заголовок отрисовывался без ожидания внешнего файла.
CLS от баннеров согласия и рекламы, тихие потери конверсии
CLS укладывается в 0,1, значения выше 0,25 считаются плохими. Метрика собирается по сессиям: сдвиги группируются в окно до 5 секунд с разрывом не короче секунды, зачёт идёт по худшей сумме. Источники сдвигов на YMYL проектах стандартные: баннер согласия на обработку персональных данных, всплывающие предложения, рекламные слоты без зарезервированных размеров, веб-шрифты с поздней подменой. Каждый сдвиг формы записи означает промах пальца по кнопке и повторное прицеливание, часть аудитории просто уходит. Типовая раскладка: баннер согласия поднимает контент на 120 пикселей, реклама догружается слотом на 250 пикселей, счёт подытоживает 0,28 и страница уходит в красную зону.
Правила простые: слотам задают фиксированные размеры, изображениям прописывают width и height, шрифты подключают с font-display: swap, попапы рисуют поверх контента, а не со сдвигом текста. Анимацию перемещения блоков заменяют на transform, под медленные виджеты рисуют скелетоны, пропорции контейнеров фиксируют стилем:
.banner-slot { aspect-ratio: 16 / 9; }Баннер согласия лучше показать нижней плашкой, которая не двигает основной материал. К слову, окна, обязательные по закону, от межстраничной политики не страдают: Google прямо исключает из нарушений баннеры согласия по требованию законодательства и окна входа, если они не занимают экран постоянно.
Доверительная инфраструктура от HTTPS до отказа от агрессивных окон
HTTPS стал сигналом ранжирования ещё в 2014 году, Safe Browsing отслеживает фишинг и вредоносный код, политика агрессивных межстраничных объявлений действует с 2017 года. Для YMYL тематики это не формальность. Предупреждение браузера на медицинской странице обнуляет клики, а банк с полноэкранным окном "оставьте телефон" до контента теряет и пользователей, и оценку опыта. Сюда же относятся сертификаты без смешанного контента, честные формы, отсутствие скрытых перенаправлений: надёжность стоит в центре руководства для асессоров, и техническая база её часть. Флаг Safe Browsing к тому же убирает страницу из результатов, поэтому единственная взломанная страница с перенаправлением на сомнительный ресурс способна обнулить месяцы работы над позициями. Техническую базу проверяют в отчётах Search Console: раздел безопасности показывает взломы и нежелательное ПО, отчёт HTTPS отдаёт список адресов со смешанным контентом.
Отдельный слой доверия редакционный. У медицинских статей это имя автора с регалиями и пометка о медицинской проверке материала, у банковских страниц ссылки на лицензии, документы и даты обновления ставок. Асессор при ручной оценке ищет именно такие маркеры, и их отсутствие не компенсирует идеальный отчёт Lighthouse.
Порядок внедрения и контроль полевых метрик для медицины и финансов
Полевые замеры собирает Chrome UX Report на реальных пользователях: отчёт Core Web Vitals в Search Console группирует адреса по статусам за 28 дней, PageSpeed Insights добавляет лабораторные тесты Lighthouse с конкретными рекомендациями. Лаборатория ищет причины, поле ставит диагноз, порог считается по 75-му процентилю. Оптимизируют шаблоны, а не отдельные URL: одна тяжёлая шапка услуг портит метрики сотен страниц. Для приоритизации выгружают группы отчёта, сортируют по количеству проблемных адресов и начинают с шаблонов, которые собирают больше трафика. Раз в месяц снимают контрольный срез по группам и выбирают следующий шаблон для работ. Для точной диагностики собирают атрибуцию:
import {onINP} from 'web-vitals/attribution';Атрибутируемая сборка показывает, какой элемент и какой скрипт ответственен за худшее взаимодействие, а лабораторный балл остаётся лишь подсказкой: красивая оценка на быстрой линии не спасает страницы, которые в час пик грузятся шесть секунд на телефоне в глубинке. Внешний срез даёт открытый набор CrUX: через его интерфейс сравнивают свои пороги с конкурентами по нише, а не с абстрактными идеалами. Эффект после релиза оценивают через три-четыре недели: скользящее окно в 28 дней обновляется постепенно, скачок за один день оно не покажет.
Для YMYL проекта порядок работ выглядит так:
1. перевести все страницы на HTTPS, закрыть смешанный контент и снять замечания Safe Browsing;
2. убрать полноэкранные окна, перекрывающие контент до первого экрана на мобильных;
3. вывести LCP на ключевых шаблонах услуг и статей в зону до 2,5 секунды;
4. довести INP до 200 миллисекунд на калькуляторах, фильтрах и формах записи;
5. удержать CLS в пределах 0,1 за счёт зарезервированных размеров баннеров;
6. выстроить регулярный мониторинг полевых метрик с приоритетом худших шаблонов;
7. закрыть пробелы доверия, от авторов и рецензентов до контактов и политики конфиденциальности.
Последний пункт списка по эффекту первый: для медицины и финансов репутационные сигналы решают больше, чем миллисекунды. Core Web Vitals это страховка сильного контента, а не его замена. Проект, где есть врач-рецензент, честные цены и отклик в 200 миллисекунд, выигрывает у обоих соседей сразу: у быстрого, но пустого, и у авторитетного, но медленного.