Почему Core Web Vitals важны не только для SEO, но и для заявок

В большинстве компаний Core Web Vitals живут в зоне ответственности SEO-специалиста. На планёрках это звучит так: «у нас красные показатели в PageSpeed, надо подкрутить, чтобы Google не пессимизировал». Через месяц разработчик «подкрутил», PageSpeed показывает 92, в отчёте поставили галочку, и тема закрывается. Параллельно отдел продаж жалуется на низкое количество заявок при растущем рекламном бюджете, маркетинг говорит «контекст подорожал», а собственник смотрит на CPL и не понимает, почему он растёт. Связь между этими двумя сюжетами не очевидна, но она прямая: те же самые LCP, INP и CLS, которые сеошник чинит ради ранжирования, на каждом замере отжимают часть заявок ещё до того, как пользователь дошёл до формы.

В статье разбираем, почему Core Web Vitals — это не «SEO-метрики», а метрики поведения посетителя на странице, которые буквально определяют, дойдёт ли он до кнопки «Отправить заявку». Покажем, что именно теряется на каждой из трёх метрик в деньгах, как один и тот же сайт может одновременно ранжироваться нормально и сливать рекламный трафик из-за плохого INP, как мерить вклад CWV в CR и CPL и почему «оптимизация под Lighthouse» в кабинете разработчика чаще всего не двигает бизнес-метрики. Все цифры — в BYN, ориентир — рынок Беларуси и СНГ.

Опираемся на A/B-исследование Vodafone Italia с web.dev по влиянию LCP на продажи,^[1] кейс Rakuten 24 с измеренным эффектом CWV на конверсию и выручку,^[2] отчёт Google и Deloitte «Milliseconds Make Millions» по влиянию скорости мобильного сайта на доход бренда,^[3] официальный анонс перехода на INP как Core Web Vital в марте 2024,^[4] данные HTTP Archive Web Almanac 2024 по реальному состоянию CWV в индустрии,^[5] объяснение Google Search Central по INP и поисковому опыту,^[6] а также сводный материал web.dev про бизнес-эффект Core Web Vitals.^[7]

Почему «CWV — это про SEO» давно устарело

Тезис «Core Web Vitals — это история про ранжирование» был верен в 2020–2021 годах, когда Google только анонсировал page experience update, и комьюнити горячо спорило, будет ли это серьёзным фактором ранжирования. Через четыре года картина выглядит иначе: документально измеренные эффекты CWV на ранжирование оказались скромными — это слабый тай-брейкер при равной релевантности контента, а не основной фактор. Зато эффекты на конверсию и выручку оказались тяжёлыми. На том же трафике, без правок в кампании и без новых офферов, оптимизация LCP даёт прирост продаж, который сеошное продвижение не даст и за квартал.^[1]

Vodafone Italia провёл чистый A/B-тест: одна и та же страница в двух версиях, одинаковый трафик из платных каналов, единственная разница — оптимизация под Web Vitals. Версия с улучшенным на 31% LCP показала на 8% больше продаж, на 15% лучше lead-to-visit и на 11% лучше cart-to-visit. Никаких изменений в офферах, в дизайне, в воронке. Только скорость прорисовки основного контента — и плюс 8% к деньгам.^[1] Это единственная корректная рамка, в которой стоит обсуждать CWV: как метрики, напрямую конвертирующиеся в заявки и выручку, а не как тех. долг сеошника.

Rakuten 24 повторил эту логику в e-commerce. На своём A/B-тесте они получили +33,1% к конверсии, +53,4% к выручке на посетителя, +15,2% к среднему чеку и -35,1% к exit rate — за счёт системной работы с Web Vitals. На фоне этих цифр любой разговор «нужно ли вообще заниматься CWV для маленького b2b-сайта» становится бессмысленным: если у вас идёт платный трафик, медленная и нестабильная страница — это самая большая дыра в воронке после слабого оффера.^[2]

Отдельный аргумент дают данные Web Almanac 2024. По состоянию на 2024 год только 43% сайтов проходят CWV целиком с учётом INP, а LCP остаётся главным узким местом — у большинства сайтов он не дотягивает до 2,5 секунд на медианном пользователе. Это значит, что больше половины конкурентов в любой нише сейчас сжигают часть рекламного бюджета на медленной посадочной — и оптимизация CWV сегодня даёт реальное конкурентное преимущество, которое в 2027 году станет гигиеническим минимумом.^[5]

LCP, INP и CLS на языке заявок, а не Lighthouse

Чтобы CWV перестали быть «тремя цветными цифрами в PageSpeed», их нужно перевести с языка инженерных метрик на язык поведения посетителя. Каждая из трёх метрик отвечает за конкретный момент в опыте пользователя, и каждый момент имеет своё прямое отношение к заявке. С марта 2024 набор окончательно зафиксирован: LCP отвечает за «успел ли я увидеть оффер», INP — за «реагирует ли страница, когда я с ней взаимодействую», CLS — за «не уехала ли кнопка из-под пальца за секунду до клика». INP заменил старый FID именно потому, что FID измерял только первое взаимодействие, а реальные заявки теряются на всех взаимодействиях после, в том числе на формах и фильтрах.^[4]

LCP (Largest Contentful Paint) — это про первое впечатление и решение «остаться или уйти». Если самый крупный значимый блок страницы — заголовок, баннер, главное изображение или продуктовая карточка — рисуется дольше 2,5 секунд, часть пользователей просто не дожидается. Особенно это бьёт по мобильному платному трафику: пользователь пришёл с рекламы, у него нет инвестированного интереса, он легко закрывает вкладку. На быстро загружающихся страницах продуктов конверсия в e-commerce может быть в 1,4–1,5 раза выше, чем на медленных, при равном трафике.^[7]

INP (Interaction to Next Paint) — это про честность взаимодействия. Когда пользователь нажимает кнопку, открывает выпадающий список, кликает по карточке, разворачивает FAQ — он ждёт визуальную реакцию. Если страница «думает» 300–500 мс, человек ощущает это как лаг, а если она задумалась на секунду — как «сайт сломался». INP напрямую попадает в формы заявки: если кнопка отправки не реагирует мгновенно, часть пользователей жмёт ещё раз, потом ещё, потом закрывает.^[4]

CLS (Cumulative Layout Shift) — это про доверие к интерфейсу. Когда пользователь читает страницу, и текст вдруг сдвигается, баннер «прыгает», или кнопка появляется на новом месте — у него возникает ощущение нестабильности и дешевизны. На посадочных с высокой ставкой решения (медицина, юридические услуги, B2B, ремонт) такой опыт ломает доверие за 2–3 секунды и тянет за собой просадку CR на 5–15%.^[7]

LCP: первый экран и стоимость заявки в BYN

LCP — это самая дорогая метрика в денежном выражении, потому что она работает на самом узком участке воронки: между «кликнул по рекламе» и «увидел оффер». Любые потери здесь не компенсируются ничем дальше — пользователь даже не доходит до точки, где можно прочитать ваш заголовок, посмотреть кейсы и принять решение. Deloitte и Google в исследовании «Milliseconds Make Millions» показали, что улучшение скорости мобильного сайта всего на 0,1 секунды поднимает retail-конверсию на 8,4% и travel-конверсию на 10,1%. То есть десятые доли секунды на LCP реально кратно меняют деньги в кассе.^[3]

Чтобы это стало ощутимо, переведём в воронку. Возьмём типичную для Беларуси платную кампанию для услуг: 1000 кликов в месяц, средняя ставка 1,80 BYN, бюджет 1800 BYN. Если LCP на посадочной — 4,2 секунды, мы заранее теряем часть пользователей до прокрутки. Допустим, эта потеря составляет 25% (это типичное значение для медленного мобильного LCP по данным RUM-замеров на холодном трафике). Из 1000 кликов до контента доходит только 750 человек. Дальше работают оффер и trust-блоки, например, на CR 3% — это 22–23 заявки. CPL получается ~80 BYN. Если LCP ужать до 1,9 секунды, до контента доходит, скажем, 920 человек, при том же CR 3% — это 27–28 заявок и CPL около 64 BYN. Один технический параметр сдвинул CPL на 20% без изменений в оффере и кампании.^[3]

Самое неприятное в LCP — то, что он не виден маркетологу напрямую. В Google Analytics не видно, что 25% сессий ушло до того, как страница успела отрисовать заголовок. Эти пользователи попадают в bounce, и их интерпретируют как «нерелевантный трафик» или «слабый оффер». На самом деле трафик был релевантный, оффер был нормальный — просто посадочная физически не успела показать его до закрытия вкладки. Это стандартный сценарий, который команда Ontop разбирает на аудитах: маркетолог годами оптимизирует ставки и креативы, не зная, что главный CRO-резерв сидит на этапе LCP.^[7]

Третий слой эффекта — каскадный. LCP коррелирует с TTFB и медленным CSS/JS, и если посадочная медленная сейчас — она будет медленной и через полгода, потому что причины LCP лежат в архитектуре (тяжёлый шаблон, рендер-блокирующий код, неоптимизированные изображения, отсутствие preconnect и preload). Это значит, что без структурных изменений медленный LCP сжигает часть бюджета каждый месяц, и за год накапливается сумма, на которую можно полностью переделать фронтенд посадочной.^[5]

Расчёт показывает, что LCP — это не «техническая» метрика, а точка прямой потери заявок. Похожий по структуре эффект Deloitte зафиксировал в реальных RUM-данных по 37 брендам.^[1]

INP: почему лагающая форма теряет готового клиента

INP — самая «коварная» из CWV, потому что она бьёт уже не по холодному пользователю, а по тёплому, который принял решение что-то нажать. На LCP мы теряем тех, кто не дождался отрисовки. На INP мы теряем тех, кто дождался, прочитал, заинтересовался, кликнул на «Отправить заявку» — и ничего не произошло. Это самый дорогой класс потерь: вы заплатили за клик, посадочная отработала весь путь, человек уже принял решение оставить заявку, и в этот момент интерфейс молчит 600 мс. Часть аудитории на этом моменте просто закрывает вкладку, особенно мобильные пользователи.^[4]

В реальных проектах INP-проблемы концентрируются в нескольких типичных местах. Первое — сама форма заявки: тяжёлый JS-валидатор, синхронный аналитический пиксель, лишний вызов антибот-сервиса. Кнопка «Отправить» нажимается, на странице 800 мс ничего не меняется, пользователь думает, что не сработало, и нажимает ещё раз — это видно по логам как «двойные» заявки или сразу как закрытие вкладки. Второе — фильтры и выпадающие списки в каталогах и калькуляторах: каждый чекбокс пересчитывает огромный JS-объект, и интерфейс «зажёвывает» клики. Третье — модальные окна попапов и онлайн-чатов, которые сами по себе тяжёлые и съедают main thread.^[6]

В отличие от LCP, INP не «лечится» оптимизацией изображений или подключением CDN. INP лечится разумной архитектурой клиентского JavaScript: разделением больших обработчиков на части, асинхронной загрузкой того, что не нужно для первого взаимодействия, отказом от ненужных синхронных подключений сторонних скриптов, грамотной работой с web workers. Это работа разработчика, не верстальщика, и её нельзя «закрыть быстро на коленке» — но именно она снимает потери на самом важном этапе воронки.^[4]

Бизнес-смысл INP проще всего показать на классе «дорогих» сайтов: медицина, юридические услуги, недвижимость, B2B-услуги. Здесь стоимость одной заявки может быть 80–250 BYN, и потеря 10–15% форм из-за лагающего интерфейса выливается в десятки заявок и тысячи рублей в месяц. Команда Ontop регулярно видит, как тяжёлый клиентский JS на форме съедает 20–30% реальных отправок — они не доходят до CRM, и менеджер по продажам про них даже не узнаёт.^[5]

CLS: как прыгающий макет убивает доверие за 2 секунды

CLS — самая тонкая из CWV, потому что её эффект на конверсию проходит не через скорость, а через доверие. Когда пользователь читает первый экран, и через секунду шрифт меняет размер, баннер прыгает вниз, кнопка «Заказать» уезжает на новое место, и появляется блок куки — у человека формируется ощущение «здесь что-то не доделано». На сайтах с высокой ставкой решения это ощущение мгновенно конвертируется в недоверие к самой компании, особенно в нишах, где пользователь и так осторожен: услуги, медицина, B2B, дорогие покупки.^[7]

Самый грубый сценарий — это «прыгающая кнопка». Пользователь видит на первом экране CTA, прицеливается, нажимает — и в момент клика кнопка уходит вниз, потому что сверху отгрузился ленивый баннер или подгрузилась реклама. Пользователь нажимает не туда, попадает в неожиданное место, у него ломается доверие к интерфейсу. На картах кликов это видно как кластер «промахов» в одной зоне страницы. На замерах конверсии это даёт просадку 5–10% по холодному трафику и до 20% на мобайле, где экран меньше и шифты чувствительнее.^[5]

Менее очевидный сценарий — это шрифты и иконки. Когда страница рисует контент в фоллбэк-шрифте, а через секунду подгружает основной шрифт, длина строк меняется, и весь макет «передёргивает». Технически это не критично, но психологически читается как нестабильность. У пользователя возникает короткое ощущение «сайт ещё не готов», и это снижает готовность отдать персональные данные в форму заявки. CLS эту проблему ловит и оцифровывает — но решается она не маркетологом, а разработчиком: правильным font-display, резервированием пространства под медиа, отказом от поздних JS-инъекций в DOM.^[7]

Третий слой CLS — рекламные блоки и попапы согласия на куки. Это технически объяснимый «прыжок», но пользователь не разделяет «объяснимый» и «не объяснимый» CLS — он просто видит дёрганье. По данным Web Almanac 2024 CLS в большинстве сайтов в основном «выправили», но именно на тех проектах, которые активно используют сторонние скрипты, CLS остаётся проблемой. И именно эти проекты часто и есть лидогенерационные сайты с большой рекламной нагрузкой — то есть там, где CLS бьёт по самой больной точке: по форме заявки.^[5]

SEO-эффект против бизнес-эффекта: что весит больше

В дискуссиях про CWV почти всегда смешивают две истории: как они влияют на ранжирование и как они влияют на конверсию. Это два разных эффекта с разной математикой, и сравнивать их нужно отдельно. SEO-эффект CWV, по подтверждённой позиции Google, существует, но это слабый сигнал, который работает как тай-брейкер при равной релевантности контента. Если у вас слабый контент, идеальный CWV не вытащит вас в топ. Если у вас сильный контент и средний CWV — вы выиграете у конкурентов с сильным контентом и плохим CWV, но скромно.^[6]

Бизнес-эффект CWV работает совсем иначе: он не зависит от позиции в выдаче и от того, ранжируетесь ли вы вообще. Он работает на каждом пользователе, который попал на сайт — из любого канала. Платный трафик из Google Ads, Yandex.Direct, таргета в соцсетях, SEO, прямой трафик с визиток и буклетов, переходы из почтовых рассылок — все эти посетители одинаково сталкиваются с медленным LCP, лагающим INP и прыгающим CLS, и одинаково теряют часть конверсий. Поэтому экономический вес CWV кратно больше, чем SEO-вес: первый работает на 100% трафика, второй — только на ту его часть, которая приходит из органики и борется за позиции с близким конкурентом.^[2]

Третья деталь — скорость отдачи. SEO-эффект CWV, если он есть, проявляется через недели и месяцы переиндексации и пересчёта сигналов. Конверсионный эффект виден через 7–14 дней после деплоя оптимизаций — ровно столько нужно, чтобы накопилась статистическая база для сравнения CR и CPL до и после. Поэтому в плане окупаемости работа с CWV ради заявок отбивается раньше и стабильнее, чем работа с CWV ради SEO.^[3]

Главный практический вывод: ставить вопрос «нужно ли нам заниматься Core Web Vitals для SEO» — значит изначально занижать ожидания и неверно бюджетировать задачу. Корректная постановка — «сколько мы теряем заявок и денег из-за плохих CWV сейчас, и сколько из этого мы вернём при оптимизации». Тогда задача попадает в зону ответственности маркетинга и продукта, а не остаётся в углу у одного SEO-специалиста, и под неё выделяется время разработчиков, а не «остаточный» час в спринте.^[5]

Как мерить CWV в связке с CR и CPL

Чтобы CWV перестали быть «лабораторными цифрами из PageSpeed» и превратились в управляемую бизнес-метрику, нужно собирать их в связке с реальным поведением и воронкой. Сам по себе балл Lighthouse 92 ничего не говорит о заявках: он показывает, как ведёт себя страница на синтетическом замере с конкретного устройства и сети. Реальные пользователи приходят с других устройств, по другому интернету, с другим набором установленных расширений, и у них CWV могут быть совсем не такими, как в отчёте разработчика. Поэтому первый шаг — переход с lab-замеров на field-данные.^[5]

Field-данные — это то, что собирает Chrome User Experience Report (CrUX) и любая RUM-система (Real User Monitoring). RUM пишет реальные LCP, INP, CLS на каждом сеансе и позволяет сегментировать их по устройствам, странам, страницам и каналам трафика. На этом этапе появляется первая полезная картина: какой LCP у мобильных пользователей, пришедших с Google Ads на лендинг услуги, и насколько он отличается от LCP десктопа на главной. Дальше эту картину нужно скрестить с воронкой — сегмент с плохим LCP сравнить с сегментом с хорошим LCP по конверсии и CPL.^[4]

Когда сегментная картина готова, появляется управленческое решение: куда направить разработчика. Если CR на сегменте с LCP > 4 сек на 40% ниже, чем на сегменте с LCP < 2 сек, и платного трафика на этот сегмент идёт половина — значит, оптимизация LCP принесёт измеримый эффект на CPL. Если разница есть, но небольшая, или сегментов с плохим LCP мало — приоритет надо смещать на INP или CLS. Это и есть нормальная работа продуктового аналитика поверх CWV: не «улучшать всё», а закрывать те метрики, где сидят основные потери заявок.^[5]

Финальный этап — A/B-тестирование оптимизаций. Vodafone и Rakuten построили свои известные кейсы именно на A/B: половина трафика на старую страницу, половина — на оптимизированную, разница только в Web Vitals, измеряются продажи и конверсия. Это золотой стандарт, который позволяет точно сказать «оптимизация LCP принесла +8% продаж» вместо обтекаемого «мы стали быстрее, и вроде бы продажи подросли». Без A/B многие изменения легко списать на сезонность или другие маркетинговые факторы.^[1]

Почему «оптимизация под Lighthouse» не двигает заявки

Самая частая ошибка в работе с CWV — это «оптимизация под балл Lighthouse». Команда видит в PageSpeed красные цифры и ставит задачу «поднять до 90». Разработчик гасит самые видные предупреждения: переписывает картинки на webp, добавляет lazy-loading, удаляет несколько ненужных скриптов. Балл синтетического Lighthouse поднимается с 60 до 90, в отчёте ставят галочку, тема закрывается. Через месяц маркетолог не видит изменений в CR, и команда делает вывод «CWV не работают для нашей ниши». Проблема не в CWV, а в том, что оптимизировали не то, что теряет заявки.^[7]

Lighthouse — это синтетическая оценка с фиксированными параметрами устройства и сети. Реальные пользователи на холодном мобильном LTE-соединении видят страницу совсем иначе, и LCP у них может быть не 1,8 сек как в отчёте, а 4,5 сек. Балл 92 в Lighthouse при этом легко уживается с реальным p75 LCP в 4,2 сек на мобайле, и именно этот реальный LCP управляет конверсией. Поэтому работа должна вестись не по lab-баллу, а по field-метрике, и обычно первый честный замер RUM-данных у компании выглядит как холодный душ.^[5]

Вторая ошибка — оптимизация ради «зелёного значка», а не ради заявок. Команда чинит то, что проще починить, а не то, что приносит максимум CR. Например, ужимает CSS, чтобы поднять Speed Index, но не трогает тяжёлый сторонний скрипт чата, который убивает INP на форме. По метрике становится лучше, по заявкам — нет. Чтобы это не происходило, оптимизация CWV должна планироваться с маркетологом и аналитиком, а не отдельно в команде разработчиков. У команды Ontop этот разрыв — самая частая причина «не сработавших» оптимизаций, которые мы видим на старте проектов.^[7]

Третья ошибка — разовая оптимизация без поддержки. CWV — это живая метрика, она деградирует с каждой новой фичей, новым рекламным скриптом, новой партнёрской интеграцией. Сайт, который показывал хорошие CWV в январе, к маю может скатиться в красную зону просто потому, что добавили чат, поставили новый аналитический пиксель и расширили шапку. Без процесса регулярного RUM-мониторинга и блокировки релизов с просадкой CWV любые однократные улучшения откатываются назад. И тогда снова появляется иллюзия, что «CWV не работают» — хотя на самом деле никто не контролировал, чтобы они оставались на достигнутом уровне.^[4]

С чего начать, чтобы CWV отбили рекламный бюджет

Если вы только начинаете работать с CWV в логике заявок, важно не пытаться «починить всё сразу», а пройти короткой последовательностью, которая быстро выводит на видимый эффект. Эта последовательность одинаково работает для лендинга услуги, B2B-сайта, корпоративного сайта и среднего интернет-магазина. Она не заменяет глубокую техническую оптимизацию, но даёт первый виток с измеримым результатом и оправдывает дальнейший бюджет на разработку.^[5]

Сначала фиксируем точку отсчёта. Снимаем CrUX или RUM-данные за последние 28 дней, разделяем по устройствам и ключевым шаблонам страниц (главная, лендинг услуги, форма заявки, каталог). Получаем p75 для LCP, INP и CLS на каждом сегменте. Это и есть то, что мы будем двигать. Параллельно фиксируем текущие CR и CPL по каждому сегменту — без них любая оптимизация останется без бизнес-обоснования.^[3] Дальше выбираем точку приложения — обычно это 1–2 шаблона страницы, на которых сходится больше всего платного трафика и где p75 LCP или INP хуже всего. Не нужно сначала чинить главную, если 80% рекламного трафика идёт на лендинги услуг.^[1]

Третий шаг — разделение работ на «быстрые» и «архитектурные». Быстрые — это оптимизация изображений и шрифтов, удаление мусорных сторонних скриптов, lazy-loading офф-скрин контента, preconnect к критичным доменам. Эти работы дают 30–50% эффекта и закрываются за 2–3 недели. Архитектурные — это переработка тяжёлого клиентского JS, отказ от рендер-блокирующих библиотек, серверный рендеринг критичных частей, переход на современные форматы доставки. Это уже месяц–два разработки, но именно они снимают INP и тяжёлые сценарии LCP.^[4] Финальный шаг — встроить CWV в процесс: RUM-мониторинг, алерты на просадку, проверка релизов на регрессии. Без этого всё, что вы починили, медленно деградирует обратно.^[5]

Параллельно с технической работой важно подключить аналитика, чтобы он каждые две недели сводил отчёт «как изменились CR и CPL по сегментам с улучшенным CWV». Это превращает CWV из IT-задачи в бизнес-задачу с понятным ROI и снимает тот самый разрыв между командами, из-за которого многие компании годами не могут довести оптимизацию до конца. Когда этот цикл закрыт, CWV становятся не разовым проектом, а постоянным каналом снижения CPL — таким же, как работа с офферами и trust-блоками.^[7]

Как это решает Ontop

В проектах Ontop работа с Core Web Vitals не лежит на одном специалисте — она встроена в стык SEO, разработки, аналитики и performance-маркетинга. Мы стартуем не с PageSpeed-отчёта, а с разреза реальных полевых данных по каналам трафика и шаблонам страниц. Сначала видим, где сидят основные потери: на каком шаблоне и каком устройстве плохой LCP вырезает часть платного трафика, какая форма заявки тормозит из-за тяжёлого клиентского JS и в каких разделах CLS прыгает достаточно, чтобы это било по доверию.

Дальше мы не «оптимизируем сайт вообще». Мы выделяем 1–2 страницы, через которые идёт основной поток заявок и платного трафика, и приоритезируем работы по ожидаемому эффекту на CR и CPL, а не по баллу Lighthouse. Часть задач закрываем быстро — это работа со статикой, скриптами, изображениями, шрифтами. Часть требует архитектурной переработки фронтенда, и в этих случаях команда разработки Ontop ведёт её как отдельный спринт с измеримой целью по p75 LCP и INP. После этого всё закрывается RUM-мониторингом и регламентом релизов, чтобы достигнутый уровень не сполз через два месяца.

Для собственника бизнеса это значит, что CWV перестают быть «галочкой в SEO-аудите» и становятся отдельным каналом снижения стоимости заявки. Мы показываем потери и эффекты в BYN, а не в баллах, и привязываем оптимизацию к конкретным цифрам в воронке. Это позволяет планировать бюджет на разработку как инвестицию с понятным окном окупаемости — а не как очередную «техничку», которую делают потому, что так положено.

Частые вопросы

Выводы

Core Web Vitals давно перестали быть исключительно SEO-историей. Их прямой эффект на ранжирование — слабый тай-брейкер, и сравнивать с этим эффектом нечего серьёзного. А вот прямой эффект на CR и CPL — измеримый, повторяемый и лежит в коридоре +8–53% к выручке и заявкам по подтверждённым A/B-кейсам Vodafone и Rakuten. Это означает, что любая компания, которая ведёт платный трафик, уже сегодня платит реальными деньгами за плохие LCP, INP и CLS — просто эта плата маскируется в графе «CPL вырос» и редко атрибутируется на технические метрики.^[1]

Корректное обращение с CWV — это не разовая оптимизация ради зелёного значка в Lighthouse, а постоянный процесс на стыке маркетинга, разработки и аналитики. Field-данные вместо lab-замеров, сегментация трафика по CWV, привязка к воронке, A/B-тесты на ключевых правках, RUM-мониторинг и регламент релизов. Когда этот цикл выстроен, Web Vitals становятся отдельным каналом снижения стоимости заявки — таким же управляемым, как работа с офферами, trust-блоками и рекламными кампаниями. Когда этот цикл не выстроен, бизнес продолжает терять часть заявок молча и непрерывно, год за годом.^[3]

Источники

1. Vodafone — A 31% improvement in LCP increased sales by 8% — A/B-тест Vodafone Italia: 31% улучшение LCP дало +8% продаж, +15% lead-to-visit, +11% cart-to-visit при идентичном трафике и оффере. Главное доказательство, что CWV двигают деньги, а не только SEO.: https://web.dev/case-studies/vodafone
2. How Rakuten 24's investment in Core Web Vitals increased revenue per visitor by 53.37% and conversion rate by 33.13% — A/B-тест Rakuten 24: оптимизация Web Vitals дала +33,1% к CR, +53,4% к выручке на посетителя, +15,2% к среднему чеку, −35,1% к exit rate. Подтверждает эффект CWV в e-commerce.: https://web.dev/case-studies/rakuten
3. Milliseconds make millions — How improvements in mobile site speed positively affect a brand's bottom line — Исследование Google и Deloitte по 37 брендам и 30+ млн сессий: 0,1 сек улучшения скорости даёт +8,4% к retail-конверсии, +10,1% к travel-конверсии, −8,3% к bounce rate в lead gen.: https://web.dev/case-studies/milliseconds-make-millions
4. Interaction to Next Paint is officially a Core Web Vital — Официальный анонс web.dev / Chrome о замене FID на INP в марте 2024 как Core Web Vital. Подтверждает, что взаимодействия (формы, фильтры, попапы) теперь напрямую попадают в page experience.: https://web.dev/blog/inp-cwv-launch
5. Performance — The 2024 Web Almanac by HTTP Archive — Отраслевые данные HTTP Archive за 2024: 43–48% сайтов проходят все CWV целиком, LCP остаётся главным узким горлом, тренды по INP и CLS на мобайле и десктопе.: https://almanac.httparchive.org/en/2024/performance
6. Introducing INP to Core Web Vitals — Google Search Central Blog — Объяснение Google Search Central про INP, его пороги (200 мс — хорошо, 500 мс — плохо) и роль page experience сигнала в поиске. База для рассуждений о SEO-эффекте CWV.: https://developers.google.com/search/blog/2023/05/introducing-inp
7. The business impact of Core Web Vitals — Сводный обзор web.dev по бизнес-эффектам CWV: рост CR на быстрых страницах, типичные сценарии потерь на медленном LCP и INP, разница между lab- и field-замерами.: https://web.dev/case-studies/vitals-business-impact