Скорость сайта и Core Web Vitals: что чинить, а что косметика
Три метрики Google, оценка Яндекса и честные пороги. Какие правки реально ускоряют сайт, какие бесполезны и что показал наш собственный замер.
В статье 10 разделов
«Сайт тормозит» — это про деньги, а не про баллы
Разговор о скорости почти всегда начинается одинаково: кто-то показал отчёт PageSpeed Insights, там красное число, и теперь надо что-то делать. Связать это число с бизнесом при этом не может никто — ни с заявками, ни с позициями, ни с выручкой.
Связь есть, но она не в баллах. Медленная страница теряет людей до того, как они увидят предложение: посетитель с телефона в дороге не ждёт пять секунд — он возвращается в выдачу и открывает следующий результат. Для рекламного трафика это особенно обидно: клик оплачен, а страница показаться не успела. Для органики хуже вдвойне — быстрый возврат в выдачу и выбор другого результата поисковик видит.
Поэтому у скорости два разных эффекта, и путать их не стоит. Первый — прямой: сколько посетителей вообще дождались загрузки и дошли до формы. Он измеряется в вашей аналитике и в деньгах. Второй — косвенный, через ранжирование. Он существует, но его величина — предмет догадок даже у специалистов, и ниже видно, почему.
Оценка от 0 до 100 в PageSpeed Insights — это результат синтетического теста на одном условном устройстве с искусственно замедленной сетью. Она полезна как индикатор и как список подсказок, но сама по себе не является ни фактором ранжирования, ни бизнес-метрикой. Гнаться за сотней экономически бессмысленно: последние двадцать баллов обычно стоят дороже, чем весь предшествующий путь, и не меняют ни конверсию, ни позиции.
Три метрики, из которых складывается оценка
Core Web Vitals — набор из трёх показателей Google, и каждый отвечает за свой тип раздражения: долго не появляется содержимое, страница не отвечает на нажатие, содержимое прыгает под пальцем. В 2024 году состав набора изменился: метрику отзывчивости FID заменили на INP, которая учитывает не первое взаимодействие, а все за визит.
| Метрика | Что измеряет | Порог «хорошо» | Типичная причина провала |
|---|---|---|---|
| LCP | когда появился самый крупный видимый элемент — обычно баннер первого экрана или заголовок | до 2,5 секунды | тяжёлые изображения, медленный ответ сервера, блокирующие скрипты и шрифты |
| INP | насколько быстро страница отвечает на нажатия и клики — по всем взаимодействиям за визит | до 200 миллисекунд | объёмный JavaScript, который занимает основной поток и не даёт браузеру перерисовать экран |
| CLS | насколько содержимое смещается во время загрузки | не больше 0,1 | изображения, баннеры и виджеты без заданных размеров, подгружаемые шрифты |
Порог — не среднее, а 75-й перцентиль
Самая частая ошибка чтения этих чисел — усреднение. Google оценивает не среднее время, а 75-й перцентиль: в порог должны укладываться три четверти загрузок страницы. Причём мобильные и десктопные показатели считаются раздельно.
Разница принципиальная. Среднее прячет хвост: если у половины посетителей страница открывается за секунду, а у четверти — за восемь, среднее выглядит терпимо, а перцентиль честно показывает, что каждый четвёртый ждёт слишком долго. Этот хвост состоит из людей на мобильном интернете в регионах, на старых телефонах, в поездке — то есть из вполне платёжеспособной аудитории.
Практический вывод простой: смотреть надо мобильные показатели. Десктопные почти всегда выглядят лучше и почти всегда не отражают то, как сайт видит большинство.
Что поисковики говорят про скорость на самом деле
Вокруг темы много мифов, поэтому проще опереться на то, что написано в документации, а не на пересказы.
Google формулирует осторожно: единого «сигнала скорости» не существует, ранжирующие системы смотрят на набор сигналов, связанных с общим удобством страницы, и Core Web Vitals в этот набор входят. Но там же сказано прямо: поиск всё равно стремится показать самое релевантное содержимое, даже если удобство страницы оставляет желать лучшего, а хорошие показатели сами по себе роста позиций не гарантируют. Скорость работает как аргумент при прочих равных — когда по запросу есть много одинаково полезных страниц.
Яндекс закрыт сильнее. В Вебмастере есть показатель «скорость сайта»: он считается по обезличенным данным о переходах пользователей Яндекс.Браузера из выдачи и выражается по шкале от 1 до 5. То есть это полевые данные, а не лабораторный тест. Формулу расчёта Яндекс не раскрывает, конкретных рекомендаций по улучшению на её основе не даёт и влияние отдельных факторов на ранжирование не комментирует. Практическая деталь: показатель считается только для сайтов с достаточным трафиком — у молодого сайта его может просто не быть.
Отсюда честный вывод, с которым мы работаем на проектах: ускорение сайта — в первую очередь инвестиция в конверсию, которую видно в собственной аналитике, и только во вторую — в позиции, где эффект есть, но не гарантирован и не измерим напрямую. Обещать «ускорим — и вырастете в топ» некорректно; обещать «перестанете терять тех, кто не дождался» — можно.
Лаборатория и поле: почему два числа не сходятся
Открыв PageSpeed Insights, вы видите два блока данных. Это разные измерения, а не дубли одного и того же — и именно их путаница порождает споры вида «у нас же зелёный, а вы говорите медленно».
Реальные измерения у настоящих посетителей, собранные браузером Chrome. Именно они определяют, пройдена оценка Core Web Vitals или нет. Чтобы страница вообще попала в этот отчёт, она должна быть публично доступна для индексации и иметь достаточное число посещений — точный порог Google не раскрывает. У малопосещаемых страниц полевых данных не будет, и это нормально, а не поломка.
Синтетический прогон на эмулируемом устройстве с ограниченной сетью. Отсюда берётся балл от 0 до 100 и список рекомендаций. Результат воспроизводим и удобен для отладки, но одно устройство и один канал связи не описывают вашу аудиторию.
Лаборатория не знает ваших посетителей: их устройств, их сетей, их поведения. Сайт с аудиторией на быстрых десктопах может показывать приличное поле при плохой лаборатории — и наоборот, вылизанный под тест лендинг проваливает поле, если реальные люди приходят на него с телефонов в метро.
Мы наблюдали это на собственном сайте: CLS одной и той же страницы в разных прогонах прыгал от нуля до долей единицы, потому что зависел от того, успел ли за этот раз подгрузиться шрифт со стороннего CDN. Один замер одной страницы — не факт, а один бросок кубика. Выводы делаются по серии замеров или по полевым данным.
Из чего складывается LCP
LCP — самая полезная метрика для разбора, потому что она раскладывается на четыре последовательных отрезка, и по ним сразу видно, где именно теряется время: сервер долго думает, браузер поздно узнал о картинке, картинка тяжёлая или всё уже готово, но рисовать мешает скрипт. Google приводит ориентировочные доли этих отрезков.
Что даёт эффект, а что косметика
Список рекомендаций в отчёте длинный и не отсортирован по отдаче: анализатор не знает, что для вас дорого, а что дёшево. По нашему опыту порядок примерно такой.
Самый крупный и самый неприятный рычаг. Скрипты скачиваются, разбираются и выполняются, занимая тот же поток, который рисует страницу, — поэтому вес JS бьёт одновременно по LCP и по INP. Сюда же относится код, нужный на одной странице, но загружаемый на всех.
Современные форматы, реальный размер вместо огромного оригинала, отложенная загрузка всего, что ниже первого экрана, — и наоборот, повышенный приоритет для картинки первого экрана, если именно она является главным элементом.
Кеширование, адекватный хостинг, отдача статики через CDN. Если сервер думает секунду, никакая оптимизация фронтенда эту секунду не вернёт: она стоит в самом начале цепочки.
Заданные размеры изображений и блоков, место под баннеры и виджеты, аккуратная подмена шрифта. Правка дешёвая, а CLS лечит почти полностью.
Правки ради последних пунктов отчёта — повторное сжатие уже сжатого, микрооптимизации, которых не видит ни одна полевая метрика. Стоят времени, не меняют ни конверсию, ни позиции.
Ускорять надо то, куда приходят люди и откуда идут заявки. Разгон раздела, куда заходят два человека в месяц, не изменит ни оценку в поле, ни выручку.
Под нож регулярно попадают счётчики, коллтрекинг и код форм. Сайт становится быстрее, а измерять его больше нечем: цели не срабатывают, источник заявки теряется. Проверка тестовой заявкой после таких работ обязательна.
Наш собственный замер: что дало результат, а что нет
Чтобы не пересказывать чужие проценты, покажем свой сайт — с той частью результата, которую обычно не показывают.
Исходное состояние было плохим: мобильная оценка PageSpeed 57 из 100 при бандле JavaScript в 8,1 МБ. Что сделали: вынесли из основного бандла данные, которые нужны не на каждой странице — тела статей блога, содержимое городских страниц — и стали подгружать их только там, где они действительно требуются. Отдельно отложили загрузку библиотеки, блокировавшей разбор страницы. Магии здесь нет: мы просто перестали заставлять посетителя главной скачивать содержимое всего блога.
Честная часть: LCP при этом улучшился только с 8,7 до 6,3 секунды, то есть в зелёную зону по нему мы до сих пор не вошли. Дальнейший прогресс упирается не в мелкие правки, а в смену способа сборки проекта, чтобы каждая страница грузила только свой код. Это отдельная крупная работа, она у нас в плане — а не закрашенный зелёным отчёт.
Отчёт состоит из мелких рекомендаций, потому что автоматический анализатор видит только следствия. Причина обычно одна и та же: страница тащит код и данные, которые ей не нужны. Пока это не исправлено, отдельные оптимизации дают единицы баллов и быстро упираются в потолок. Поэтому решение о работе со скоростью правильнее принимать вместе с решением о платформе и сборке сайта, а не после того, как сайт уже собран.
Порядок работ, который не превращается в бесконечную оптимизацию
У скорости должен быть критерий остановки. Без него команда оптимизирует бесконечно, потому что в отчёте всегда остаётся что-нибудь жёлтое.
Последовательность, по которой мы разбираем скорость на проекте.
Не балл из лаборатории, а полевые данные по трём метрикам отдельно для мобильных, плюс собственные цифры из аналитики: доля отказов и глубина просмотра на ключевых страницах. Без точки отсчёта эффект работ потом невозможно ни доказать, ни опровергнуть.
Главная, ключевые услуги, посадочные под рекламу, самые посещаемые статьи. Остальное — не сейчас: скорость оптимизируют там, где есть трафик и заявки.
Понять, где именно уходит время: сервер думает, ресурс запрашивается поздно, ресурс тяжёлый или всё готово, но мешает скрипт. Для каждого из четырёх случаев дальнейшие действия разные, и без этого шага работы идут наугад.
Лишний код на страницах, вес и формат изображений, кеширование и ответ сервера. Эти три пункта закрывают большую часть отставания: в отчёте они выглядят скучно, а в измерениях дают почти весь эффект.
Размеры под изображения, виджеты и баннеры, корректная подмена шрифта. Дёшево, быстро и заметно для посетителя: прыгающая под пальцем страница раздражает сильнее, чем лишняя секунда ожидания.
После любых работ со скриптами — тестовая заявка руками: дошла ли она в CRM, сработала ли цель, сохранился ли источник. Ускоренный сайт с неработающими формами хуже медленного.
Полевые данные накапливаются по реальным визитам и обновляются с задержкой. Оценивать результат сразу после релиза бессмысленно: в лаборатории он виден мгновенно, в поле проявляется через недели.
Критерий остановки: три метрики в зелёной зоне на приоритетных страницах у мобильных пользователей. Дальше работа переходит в режим контроля — следить, чтобы новые баннеры, виджеты и внешние скрипты не съели достигнутое обратно.
С чего начать и когда это вопрос уже не скорости
Если сайт живой и в целом устраивает, начинать надо с измерения, а не с правок: снять полевые данные по трём метрикам, разложить LCP на отрезки и сопоставить с поведением посетителей в Яндекс.Метрике — где именно люди уходят, не дождавшись. Часто выясняется, что медленные страницы и страницы с низкой конверсией — это разные страницы, и деньги надо вкладывать в другое.
Есть граница, за которой скорость перестаёт быть отдельной задачей. Если любая правка требует разработчика, платформа не даёт управлять кодом, а сайт собран так, что каждая страница тянет весь проект целиком, — оптимизировать нечего, вопрос переходит в плоскость пересборки. Как отличить одно от другого, разбирали в статье «Редизайн сайта: когда он нужен, а когда роняет трафик»; что входит в саму разработку сайтов — в материалах «Разработка корпоративного сайта для B2B» и «Разработка лендинга».
Скорость связана и с видимостью. Для SEO-продвижения она работает как аргумент при прочих равных, но куда важнее прозаичное: медленная страница теряет посетителей, которые до содержания просто не добрались. Для генеративных ответов нейропоиска критична доступность и структурированность содержания — механику разбирали в статье «GEO: оптимизация под нейропоиск». А что из технической работы сегодня разумно поручить ИИ, а что он делает плохо, — в материале «ИИ в разработке сайтов».
Если непонятно, ваша проблема в скорости или в чём-то другом, цепочку целиком смотрит аудит маркетинга: трафик, страница, обработка обращения. Он честнее отвечает на вопрос «почему мало заявок», чем любой отчёт с баллами.
Частые вопросы
Не готовы к большому контракту?
Начните с экспресс-старта
Связка «лендинг + оффер + первичная реклама» под ключ за 10–14 дней. Проверьте нишу и наш подход на одном оффере — фиксированная цена, без абонемента.