Медленный сайт теряет деньги: Core Web Vitals и конверсия

Сначала про деньги: сколько стоит каждая лишняя секунда

Две цифры, которые давно ходят по индустрии и на которые опираются практически все обсуждения скорости: задержка загрузки в одну секунду снижает конверсию примерно на 7%, и 53% пользователей мобильных устройств покидают страницу, если она грузится дольше трёх секунд. Это отраслевые данные, а не наши собственные измерения, и относиться к ним стоит как к порядку величины, а не как к константе для вашего сайта.

Порядок величины при этом легко превратить в собственную цифру. Возьмите месячную выручку с органического и рекламного трафика, посмотрите долю мобильных визитов и текущее время загрузки на мобильных. Если у вас 4 секунды вместо 2,5 и мобильных 70% — вы уже знаете, о каком проценте выручки идёт речь. Именно так разговор о скорости перестаёт быть техническим и становится разговором о бюджете.

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

LCP, INP и CLS глазами пользователя

LCP отвечает на вопрос «когда я увидел то, ради чего пришёл». Это момент отрисовки самого крупного элемента в видимой области: обычно главное изображение, заголовок или видео. Хороший результат — до 2,5 секунды, плохой — больше 4. Именно эту метрику пользователь ощущает как «сайт грузится»: пока LCP не наступил, человек смотрит на пустое место или на заглушку и решает, ждать ли дальше.

INP отвечает на вопрос «сайт реагирует, когда я нажимаю». Метрика измеряет задержку между действием пользователя и видимым откликом интерфейса на протяжении всего визита. Хороший результат — до 200 мс, плохой — больше 500. Это то самое ощущение «нажал и ничего не произошло, нажму ещё раз», которое приводит к дублям заказов и к тому, что человек уходит, решив, что сайт сломан. INP заменил прежнюю метрику первой задержки ввода и оценивает страницу строже.

CLS отвечает на вопрос «страница прыгает под пальцем». Метрика фиксирует неожиданные сдвиги вёрстки: подгрузилось изображение без заданных размеров, встал рекламный блок, подключился шрифт и переверстал текст. Хороший результат — до 0,1. Практическая цена плохого CLS выше, чем кажется: человек нажимает не на ту кнопку, попадает не туда, куда хотел, и это напрямую бьёт по конверсии в формах и корзине.

Про поисковые системы важна одна деталь, которую часто путают. Google использует Core Web Vitals как фактор ранжирования с 2021 года, то есть влияние прямое и заявленное. Яндекс отдельной метрики скорости в ранжировании не декларирует, но учитывает её косвенно, через поведенческие факторы: медленная страница даёт отказы и короткие визиты, а это уже прямой сигнал качества. Результат для владельца сайта одинаковый — просто механизм разный.

Лабораторные данные против полевых: почему 98 из 100 ничего не значат

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

Отсюда классическая ситуация: в отчёте PageSpeed Insights красуется 98 баллов, а блок с данными реальных пользователей красный. Балл — это лабораторная оценка одного запуска на условном устройстве; красный блок — это то, что происходит с вашей аудиторией на самом деле. Приоритет всегда за полевыми данными: они собираются с реальных браузеров и учитывают устройства, сети и географию вашей конкретной аудитории.

Для российского трафика к этому набору обязательно добавляется Яндекс.Метрика. Она даёт отчёты по времени загрузки в разрезе устройств, регионов и источников, а вебвизор показывает, как выглядит визит целиком — включая моменты, когда человек несколько раз нажимает на неотзывчивую кнопку. Комбинация «полевые данные браузера плюс Метрика плюс лабораторный прогон для отладки» закрывает картину полностью и не даёт оптимизировать выдуманную проблему.

• Полевые данные — приоритет: это ваша реальная аудитория, а не тестовое устройство.
• Лабораторный прогон нужен для отладки и сравнения «до и после», а не для отчёта.
• Смотрите отдельно мобильные и десктоп — усреднённая цифра скрывает проблему.
• Метрика показывает скорость в разрезе регионов — для России это часто ключевой срез.

Диагностика: как найти настоящую причину

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

Дальше найдите сам элемент LCP — инструменты подсвечивают его прямо на странице. Дальнейшие действия зависят от того, что это. Если картинка, вопрос сводится к её весу, формату, размерам и к тому, не стоит ли на ней ленивая загрузка, которой там быть не должно. Если текстовый блок — почти наверняка виноват шрифт, который блокирует отрисовку. Если элемент появляется после выполнения скрипта, значит контент рендерится на клиенте и ждёт JavaScript.

Блокирующие ресурсы вычисляются просто: любой стиль или скрипт, подключённый в шапке без атрибутов отложенной загрузки, задерживает первую отрисовку. Отдельно проверьте сторонние подключения — счётчики аналитики, чат поддержки, пиксели рекламных систем, виджеты обратного звонка. Практика показывает, что именно они чаще всего и составляют половину времени загрузки, при этом их обычно ставит маркетинг, а не разработка, и никто не пересматривает список годами.

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

Что чинить в первую очередь: список по отдаче на час работы

Изображения дают самую высокую отдачу почти всегда. Современные форматы вроде WebP и AVIF весят на 25–50% меньше при том же качестве, а правильные размеры под конкретный экран экономят ещё больше: отдавать картинку шириной 2000 пикселей на телефон с шириной экрана 390 — самая распространённая и самая дорогая ошибка. Отдельное правило: главное изображение первого экрана никогда не грузится лениво, а всё, что ниже сгиба, лениво грузиться должно.

Сторонние скрипты — второй по отдаче пункт и первый по недооценённости. Аналитика, чаты, пиксели, виджеты соцсетей и системы обратного звонка суммарно способны отнимать секунды. Работа здесь состоит из двух шагов: сначала ревизия — выяснить, что из этого списка вообще используется и кем; потом отложенная загрузка всего, что не нужно в первую секунду. Чат поддержки, который подключается через три секунды после загрузки страницы, не потерял ни одного обращения, но вернул секунду в LCP.

Шрифты и критический CSS дают заметный эффект при небольших затратах. Подключение шрифта без указания поведения при загрузке приводит к тому, что текст либо не отображается, либо перерисовывается со сдвигом. Ограничьте количество начертаний, подключайте современные форматы, задайте поведение отображения и предзагрузите то, что нужно на первом экране. Критический CSS — стили только видимой части, встроенные в страницу, — убирает блокировку отрисовки на старте.

Серверная часть, кеширование и CDN закрывают оставшееся. Время до первого байта выше 600 мс означает, что оптимизировать фронтенд бессмысленно, пока не разобрались с сервером: тяжёлые запросы к базе, отсутствие кеширования страниц, слабый хостинг. CDN критичен для аудитории, распределённой по стране: разница между Москвой и Владивостоком при отдаче с одного сервера измеряется сотнями миллисекунд, и это чистая потеря, которая лечится настройкой.

Что реально можно исправить на вашей платформе

На Tilda и подобных конструкторах доступны сжатие изображений, сокращение числа блоков, отказ от фоновых видео и удаление лишних встроенных скриптов. Недоступны критический CSS, тонкое управление порядком загрузки ресурсов и структура итогового HTML. Практический потолок обычно таков: с плохих показателей до приемлемых дойти можно, до отличных — нет. Если скорость критична для вашего трафика, это аргумент в пользу смены платформы, а не бесконечной оптимизации.

На WordPress исправить можно почти всё, и главная работа — не добавление кеширующего плагина, а ревизия существующих. Типичный сайт несёт три десятка плагинов, каждый из которых подключает свои стили и скрипты на всех страницах, включая те, где он не используется. Отключение половины неиспользуемых плагинов обычно даёт больший эффект, чем любая тонкая настройка кеша. Дальше — кеширование страниц, оптимизация изображений на лету, отложенная загрузка скриптов и, при необходимости, CDN.

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

На Next.js и подобных решениях потолок самый высокий: серверный рендеринг, автоматическая оптимизация изображений, разделение кода по маршрутам, статическая генерация страниц, которые редко меняются. Здесь плохие показатели скорости — это почти всегда следствие конкретных решений в коде: избыточные клиентские компоненты, тяжёлые библиотеки в общем бандле, отсутствие кеширования запросов. Всё это чинится, и чинится предсказуемо.

С каких страниц начинать: не с главной

Инстинктивно оптимизацию начинают с главной страницы, и это почти всегда неправильный приоритет. Возьмите отчёт по посадочным страницам, отсортируйте по трафику и по вкладу в выручку, наложите на это показатели скорости — и вы получите список, где первые три-четыре позиции дадут больше эффекта, чем месяц работы по всему сайту. Обычно это карточки товаров, страницы услуг под рекламный трафик и результаты поиска по каталогу.

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

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

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

Услуги по теме

• Доработка и поддержка сайтаНе каждый проект нужно переписывать. Часто дешевле починить скорость, исправить технические SEO-ошибки, добавить недостающие разделы и интеграции — и получить рабочий сайт без бюджета на новую разработку.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• SEO и GEO продвижение сайтаПоисковый трафик — единственный канал, который не выключается вместе с рекламным бюджетом. Мы ведём сразу два направления: классическое SEO под Яндекс и Google и GEO — подготовку страниц к цитированию в ответах AI Overviews, Нейро, ChatGPT и Perplexity, где всё чаще заканчивается путь пользователя. Начинаем с аудита, а не с закупки ссылок.

Читать дальше

• На чём делать сайт в 2026: Tilda, WordPress, Битрикс или Next.jsКонструктор, CMS или собственная разработка — выбор зависит не от вкуса, а от сценария и горизонта планирования. Разбираем стоимость владения за три года, потолки платформ и цену переезда, если вы ошиблись на старте.
• SEO в Яндексе в 2026: что изменилось и что больше не работаетСсылочное обесценено, тексты «для роботов» уводят страницы в малоценные, а накрутка ПФ стала не серой тактикой, а риском потерять сайт. Разбираем, на чём держится ранжирование в Яндексе в 2026 году и с чего начать.
• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.