Скорость загрузки сайта и Core Web Vitals: как проверить и ускорить

Скорость загрузки сайта — это то, насколько быстро человек видит основной контент страницы и может с ней взаимодействовать. Для Google она формализована в метриках Core Web Vitals, для Яндекса важна прежде всего через поведение пользователей: медленный сайт чаще закрывают, не дождавшись загрузки. Разберём по порядку, что означают LCP, INP и CLS, какие значения считаются хорошими, как правильно измерять скорость и какие исправления дают эффект на практике. Материал для владельцев сайтов, маркетологов и разработчиков, которым нужно не «зелёное число в отчёте», а быстрый сайт для клиентов.

Влияет ли скорость загрузки на позиции в Яндексе и Google

Короткий ответ — да, но не так прямолинейно, как кажется.

Google официально учитывает Core Web Vitals как часть сигналов «удобства страницы». При этом сам Google подчёркивает, что релевантность и полезность контента важнее: быстрая, но бесполезная страница не обгонит медленную, но лучше отвечающую на запрос.
Яндекс не публикует Core Web Vitals как фактор ранжирования, но скорость напрямую влияет на поведенческие сигналы: отказы, глубину просмотра, возвраты в выдачу. Если конкуренты открываются мгновенно, а ваш сайт думает несколько секунд на мобильном интернете, часть пользователей просто уйдёт к ним.

Поэтому мы рассматриваем скорость не как «галочку для SEO», а как часть конверсии: быстрый сайт получает больше заявок с того же трафика. Если сайт медленный и непонятно почему, это одна из задач, которые решает технический аудит сайта.

Что такое Core Web Vitals

Core Web Vitals — набор из трёх метрик Google, которые описывают реальный пользовательский опыт: как быстро загружается главное, как быстро страница реагирует и не прыгает ли вёрстка.

Метрика	Что измеряет	Хорошо	Требует улучшения	Плохо
LCP (Largest Contentful Paint)	Время отрисовки самого крупного элемента на первом экране — обычно главного изображения или заголовка	до 2,5 с	2,5–4 с	более 4 с
INP (Interaction to Next Paint)	Задержка между действием пользователя (клик, тап, ввод) и визуальной реакцией страницы	до 200 мс	200–500 мс	более 500 мс
CLS (Cumulative Layout Shift)	Сдвиги вёрстки во время загрузки: кнопка «уезжает» из-под пальца, текст прыгает	до 0,1	0,1–0,25	более 0,25

INP заменил старую метрику FID в марте 2024 года. Если вы видите в старых статьях упоминание FID как основного показателя отзывчивости — информация устарела.

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

Лабораторные и полевые данные: в чём разница

Самая частая путаница при проверке скорости — смешение двух типов данных.

Полевые данные собираются с реальных пользователей браузера Chrome (отчёт CrUX) за последние 28 дней. Именно их Google использует для оценки. Для небольших сайтов с малым трафиком полевых данных может не быть вовсе.
Лабораторные данные — это разовый тест в симулированных условиях (Lighthouse). Он удобен для поиска причин и проверки исправлений, но не отражает реальность полностью. Метрику INP в лаборатории измерить нельзя, вместо неё Lighthouse показывает косвенный показатель TBT (общее время блокировки).

Балл Lighthouse от 0 до 100 — это не фактор ранжирования, а сводная оценка лабораторного теста. Гнаться за «100 из 100» ради цифры не нужно: важнее, чтобы три метрики Core Web Vitals были в зелёной зоне на реальных пользователях.

Как проверить скорость загрузки сайта

PageSpeed Insights. Показывает и полевые данные (если они есть), и лабораторный тест с рекомендациями. Проверяйте в первую очередь мобильную версию и не одну главную, а ключевые шаблоны: страницу услуги, категорию, карточку товара, статью.
Google Search Console. Отчёт «Основные интернет-показатели» группирует страницы сайта по статусу и показывает, какие шаблоны проблемные.
Яндекс Метрика. В разделе «Мониторинг» есть отчёт о времени загрузки страниц по реальным визитам. Он полезен, чтобы увидеть скорость глазами вашей аудитории, включая тех, кто приходит из Яндекса.
Инструменты разработчика в браузере. Вкладки Performance и Network показывают, какие файлы грузятся дольше всего и что блокирует отрисовку. Включите замедление сети и процессора — так вы увидите сайт глазами пользователя с бюджетным телефоном.

Базовые пункты проверки скорости есть и в нашем чек-листе технического аудита, а про особенности мобильных сетей подробнее — в статье мобильная версия сайта и SEO.

Как улучшить показатели Core Web Vitals

Каждая метрика портится по своим причинам, поэтому и лечить их нужно по-разному. Разберём по порядку.

Как улучшить LCP

LCP чаще всего портят тяжёлое главное изображение, медленный сервер и блокирующие ресурсы. Что помогает:

Сжатие и современные форматы изображений. WebP и AVIF при том же качестве весят заметно меньше JPEG и PNG. Баннер первого экрана на несколько мегабайт — классическая причина плохого LCP.
Правильные размеры. Не отдавайте картинку 3000 пикселей шириной на экран телефона. Используйте адаптивные изображения с разными размерами под разные экраны.
Приоритет для главного изображения. Картинку первого экрана не нужно откладывать через lazy-load — наоборот, ей стоит дать высокий приоритет загрузки (атрибут fetchpriority со значением high или предзагрузка).
Быстрый ответ сервера. Время до первого байта (TTFB) — фундамент для всех метрик. Ориентир — до 0,8 секунды. Помогают кэширование страниц, нормальный хостинг вместо самого дешёвого тарифа, CDN для статики.
Меньше блокирующих ресурсов. CSS и шрифты, без которых страница не может отрисоваться, должны быть компактными; всё остальное — загружаться позже.

Как улучшить INP

INP — про отзывчивость, и его главный враг — JavaScript. Каждый скрипт, который долго выполняется в основном потоке браузера, задерживает реакцию на клик.

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

Как улучшить CLS

Сдвиги вёрстки раздражают пользователей сильнее, чем кажется: человек целится в кнопку, а она уезжает вниз из-за подгрузившегося баннера.

Указывайте размеры (ширину и высоту или пропорции) для всех изображений, видео и iframe, чтобы браузер заранее резервировал место.
Не вставляйте баннеры, плашки cookie и уведомления поверх уже отрисованного контента со сдвигом вниз — лучше выделить им место заранее или показывать поверх, не сдвигая текст.
Настройте загрузку веб-шрифтов так, чтобы подмена шрифта не меняла высоту блоков: предзагрузка основного шрифта, близкий по метрикам запасной шрифт.
Резервируйте место под рекламные блоки и виджеты, которые подгружаются асинхронно.

Типичные причины медленного сайта: таблица для диагностики

Симптом	Вероятная причина	Что делать
Долго белый экран на любой странице	Медленный сервер, нет кэширования	Проверить TTFB, включить кэш, сменить тариф или хостинг
Текст появился, а главная картинка — через несколько секунд	Тяжёлое изображение первого экрана, lazy-load на нём	Сжать, конвертировать в WebP или AVIF, убрать отложенную загрузку, дать приоритет
Страница загрузилась, но кнопки не реагируют	Много JavaScript, сторонние виджеты	Убрать лишние скрипты, отложить загрузку оставшихся
Контент прыгает при загрузке	Нет размеров у медиа, баннеры и шрифты	Задать размеры, зарезервировать место, настроить шрифты
Быстро на компьютере, медленно на телефоне	Тяжёлый код и картинки, рассчитанные на десктоп	Адаптивные изображения, облегчение мобильной версии

Скорость и платформа сайта

Возможности ускорения сильно зависят от того, на чём сделан сайт. На конструкторах вроде Tilda вы ограничены тем, что позволяет платформа: можно сжать изображения, убрать лишние блоки и сторонние скрипты, но серверную часть не изменить. Про эти ограничения подробнее — в статье SEO на Тильде. На CMS вроде 1С-Битрикс или WordPress многое решают настройки кэширования и качество шаблона, а на современном стеке с серверным рендерингом скорость закладывается ещё на этапе разработки.

Если сайт работает на CMS и с ним регулярно что-то происходит — обновления, новые модули, плагины, — скорость может деградировать постепенно. Поэтому мы включаем контроль Core Web Vitals в техническую поддержку сайтов: проверяем ключевые шаблоны после каждого заметного изменения.

Сколько времени и денег занимает ускорение сайта

Однозначного ответа нет: всё зависит от того, что именно тормозит. По нашему опыту работы можно выделить три сценария.

Быстрые исправления. Сжать изображения, убрать пару лишних виджетов, включить кэширование — это часы работы, а не недели. Часть можно сделать самостоятельно через админку.
Доработки шаблона. Переделать загрузку скриптов и шрифтов, задать размеры медиа, облегчить первый экран — задача для разработчика на несколько дней. Мы оцениваем её почасово, час разработчика у нас стоит 3 500 ₽.
Системные проблемы. Тяжёлая тема с десятками плагинов, устаревшая версия CMS, слабый сервер. Здесь иногда дешевле и надёжнее переделать шаблон или сменить хостинг, чем бесконечно латать.

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

С чего начать ускорение: план по приоритетам

Проверьте 3–5 ключевых шаблонов страниц в PageSpeed Insights на мобильном профиле.
Посмотрите, какая из трёх метрик в красной или жёлтой зоне, и начните с неё.
Уберите лишние сторонние скрипты — это часто самый быстрый выигрыш без участия разработчика.
Сожмите и конвертируйте изображения первого экрана.
Проверьте время ответа сервера и кэширование.
Передайте разработчику задачи по JavaScript, шрифтам и вёрстке с конкретными страницами и цифрами из отчёта.
Через 4 недели сверьте полевые данные — они обновляются с задержкой.

Три метрики, которые стоит держать в норме

Скорость загрузки сайта — это не абстрактный балл, а три конкретные метрики: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 у большинства реальных пользователей. Для Google это прямой сигнал, для Яндекса — косвенный через поведение людей, но в обоих случаях быстрый сайт получает больше заявок. Начинайте с измерений на мобильном профиле, устраняйте самые грубые причины — тяжёлые картинки, лишние скрипты, медленный сервер — и проверяйте результат по полевым данным.

Сайт медленный, а причины не очевидны? Закажите технический аудит: проверим скорость ключевых шаблонов, найдём, что тормозит, и дадим разработчику конкретный план исправлений с приоритетами.