Скорость загрузки сайта и Core Web Vitals: полный гид

Что такое Core Web Vitals простыми словами

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

LCP — насколько быстро видно главное

LCP (Largest Contentful Paint) — это момент, когда в видимой части экрана отрисовался самый крупный элемент: обычно это обложка, заголовок или большая картинка. Пользователь считает страницу загруженной именно тогда, когда увидел этот блок, а не когда догрузился последний скрипт в футере. Хороший ориентир на 2026 год — уложиться примерно в 2,5 секунды на типичном мобильном соединении.

INP — насколько быстро сайт отвечает

INP (Interaction to Next Paint) пришёл на смену старому FID и измеряет отзывчивость: вы нажали кнопку, тапнули по меню, начали печатать — и сколько миллисекунд прошло до видимой реакции интерфейса. Если после клика ничего не происходит полсекунды, мозг уверен, что сайт завис. Комфортный диапазон — до 200 миллисекунд.

CLS — насколько стабильна вёрстка

CLS (Cumulative Layout Shift) ловит самый раздражающий баг: вы целитесь в кнопку, а сверху догрузилась картинка или баннер, всё уехало вниз, и вы нажали не туда. Это накопительный сдвиг макета, и чем он ближе к нулю, тем аккуратнее ощущается сайт. Здоровое значение — меньше 0,1.

Запомните простую формулу: LCP — про «увидел», INP — про «нажал», CLS — про «не дёргается». Все три метрики Google собирает у настоящих пользователей Chrome и учитывает при ранжировании как часть сигнала о качестве страницы.

Почему скорость влияет на SEO и конверсию

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

Скорость и позиции в поиске

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

Скорость и деньги

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

Есть и репутационный слой. Тормозящий сайт подсознательно считывается как ненадёжный: если тут всё лагает, можно ли доверять оплату? Скорость — это первое рукопожатие с брендом, и оно должно быть уверенным.

Как измерить скорость: лаборатория и поле

Прежде чем что-то чинить, надо честно измерить. И здесь важно различать два принципиально разных типа данных, потому что их постоянно путают.

Лабораторные данные (lab)

Лабораторные измерения делает инструмент в контролируемых условиях: фиксированный канал, заданное устройство, чистая среда. Это Lighthouse (встроен в Chrome DevTools) и лабораторная часть PageSpeed Insights. Плюс лаборатории — воспроизводимость: вы меняете код и сразу видите, стало лучше или хуже. Минус — это симуляция, а не живые люди.

Полевые данные (field)

Полевые данные — это метрики, собранные у настоящих пользователей Chrome (набор CrUX). Именно их Google учитывает при ранжировании. Они показывают, как сайт ведёт себя на реальных устройствах, сетях и в реальной географии. Полевые цифры считаются по 75-му перцентилю: важно, чтобы быстро было не «в среднем», а у трёх четвертей аудитории.

Практический порядок замера

1. Прогоните ключевые шаблоны (главная, категория, карточка, форма) через PageSpeed Insights — отдельно для мобильных и десктопа.
2. Смотрите в первую очередь на полевые Core Web Vitals, если они есть; лабораторный балл используйте как инструмент отладки.
3. Откройте вкладку Performance в DevTools и найдите, какой именно элемент отвечает за LCP и какие скрипты держат поток.

Золотое правило: оптимизируйте по полю, отлаживайте по лаборатории. Гонка за красивой сотней в Lighthouse без оглядки на реальных пользователей — это работа ради скриншота, а не ради бизнеса.

LCP: за что отвечает и как улучшить

LCP чаще всего и есть то, что люди называют «сайт долго грузится». Улучшить его — значит быстрее показать главный элемент первого экрана. Разложим на слагаемые.

Из чего складывается LCP

LCP состоит из четырёх частей: время ответа сервера (TTFB), задержка на загрузку ресурса, время самой загрузки ресурса и время отрисовки. Тормозить может любая из них, поэтому лечение начинается с диагностики, а не с угадывания.

Что реально ускоряет LCP

• Быстрый ответ сервера. Держите TTFB низким: кэш на стороне сервера, адекватный хостинг, минимум тяжёлых запросов к базе на генерацию первого экрана.
• Приоритет главному ресурсу. LCP-картинку или шрифт заголовка стоит загружать с высоким приоритетом (preload), а не в общей очереди.
• Никакой ленивой загрузки для первого экрана. Классическая ошибка — повесить lazy-load на баннер в самом верху. Ленивую загрузку оставляем тому, что ниже сгиба.
• Лёгкий и правильно сжатый LCP-элемент. Огромный PNG-герой на 2 МБ убьёт метрику даже на быстром сервере.

Отдельно про render-blocking. Если перед показом первого экрана браузер вынужден скачать и выполнить тяжёлый CSS и JavaScript, LCP откладывается ровно на это время. Поэтому критический CSS выносят инлайном, а второстепенные скрипты — вниз и в отложенную загрузку.

INP и CLS: отзывчивость и стабильность

Если LCP — про «увидел», то INP и CLS — про ощущение качества после загрузки. Их часто недооценивают, а зря: именно они формируют чувство, что сайт сделан аккуратно.

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

Плохой INP почти всегда означает, что главный поток браузера занят тяжёлым JavaScript. Пользователь нажал — а поток в этот момент считает аналитику, крутит слайдер или рендерит виджет, и реакция откладывается. Что помогает:

• Разбивать длинные задачи на короткие, отдавая браузеру паузы на обработку кликов.
• Убирать или откладывать сторонние скрипты, которые молотят в фоне.
• Не навешивать тяжёлые обработчики на каждое движение и ввод.
• Выносить необязательные вычисления из момента взаимодействия.

Как убрать сдвиги макета (CLS)

CLS лечится дисциплиной вёрстки. Главные правила:

1. Всегда задавайте ширину и высоту (или aspect-ratio) картинкам и видео, чтобы под них заранее резервировалось место.
2. Бронируйте место под баннеры, виджеты и рекламные блоки, а не позволяйте им раздвигать контент при появлении.
3. Подключайте шрифты так, чтобы подмена системного на кастомный не двигала текст (корректный font-display и запасные метрики).
4. Не вставляйте контент над тем, что пользователь уже видит, — только под ним.

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

Главные причины медленного сайта

Хорошая новость: причин у медленных сайтов немного, и они на удивление типовые. В 9 случаях из 10 виноват кто-то из этого списка.

Тяжёлые изображения

Абсолютный чемпион по весу страницы. Фотографии в исходном разрешении, скриншоты в PNG на несколько мегабайт, картинки, которые в браузере ужимаются до маленького размера, но качаются целиком. Часто именно изображение оказывается LCP-элементом, так что двойной удар.

Шрифты

Несколько начертаний в тяжёлых форматах, загрузка с внешнего домена, отсутствие preload — и текст либо мигает, либо появляется с задержкой, попутно двигая макет.

Блокирующие CSS и JavaScript

Гигантские бандлы, которые нужно скачать и выполнить до первой отрисовки. Особенно вредны тяжёлые фреймворки там, где хватило бы пары строк кода.

Сторонние скрипты

Чаты, пиксели, десяток счётчиков аналитики, виджеты соцсетей, A/B-тесты. Каждый по отдельности «лёгкий», но вместе они съедают главный поток и портят INP. Это самая недооценённая категория.

Медленный хостинг и высокий TTFB

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

Практический вывод: не бросайтесь чинить всё сразу. Сначала измерьте, найдите свой главный источник потерь — и бейте по нему.

Оптимизация изображений: форматы и ленивая загрузка

Раз картинки — чемпион по весу, начинать оптимизацию скорости почти всегда стоит с них. Здесь самый быстрый и заметный выигрыш при минимуме рисков.

Современные форматы

Переходите на WebP, а где возможно — на AVIF. При сопоставимом качестве они весят заметно меньше классических JPEG и PNG. Для иконок и простой графики используйте SVG: он векторный, невесомый и идеально резкий на любом экране.

Правильный размер и адаптивность

Не отдавайте картинку шире, чем она реально показывается. Готовьте несколько размеров и подключайте их через srcset, чтобы телефон получал компактную версию, а десктоп — крупную. Дизайнерский герой на 4000 пикселей в контейнере на 800 — это выброшенные мегабайты и секунды.

Ленивая загрузка — но с умом

• Ставьте loading="lazy" на изображения ниже первого экрана, чтобы они не мешали стартовой отрисовке.
• А вот LCP-картинку первого экрана грузите сразу и с приоритетом — ленивая загрузка здесь только навредит.
• Всегда указывайте размеры, чтобы ленивая подгрузка не вызывала сдвигов макета (тот самый CLS).

И не забывайте про сжатие. Прогон через нормальный оптимизатор часто срезает 40–70% веса без видимой потери качества. Для контентных сайтов это буквально бесплатные секунды.

Шрифты, критический CSS и лишний JavaScript

После картинок вторая по значимости зона — код, который браузер должен обработать до показа страницы. Здесь прячется большая часть render-blocking проблем.

Шрифты

• Оставьте минимум начертаний — часто хватает двух.
• Используйте woff2 и подгружайте шрифты со своего домена.
• Делайте preload ключевого шрифта первого экрана.
• Ставьте font-display: swap, чтобы текст был читаем сразу, а не ждал загрузки шрифта.

Критический CSS

Идея простая: стили, нужные для первого экрана, встраиваются инлайном прямо в HTML, а весь остальной CSS грузится отложенно. Так браузер рисует верх страницы, не дожидаясь всей таблицы стилей. Плюс уберите из проекта мёртвые правила — за годы жизни сайта их накапливается очень много.

Меньше JavaScript

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

Кэширование, CDN, HTTP/2 и хостинг

Фронтенд-оптимизация упирается в потолок, если фундамент — сервер и доставка — работает медленно. Эти вещи дают прирост сразу на всех страницах.

Кэширование

Работает на двух уровнях. Серверный кэш избавляет от повторной тяжёлой генерации страницы и напрямую снижает TTFB. Браузерный кэш (правильные заголовки Cache-Control для статики) означает, что при повторных визитах картинки, шрифты и скрипты не качаются заново.

CDN

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

HTTP/2, HTTP/3 и сжатие

• Включите современный протокол (HTTP/2 или HTTP/3) — он эффективнее грузит десятки мелких файлов параллельно.
• Включите сжатие текстовых ресурсов (Brotli или gzip) на сервере.
• Минифицируйте HTML, CSS и JS, убирая пробелы и комментарии.

Хостинг и TTFB

Адекватный сервер — это не роскошь, а база. На нагруженном проекте биржи фриланса 24freelance мы упирались именно в серверный слой: без кэша и оптимизации запросов первый байт полз, и никакая работа с картинками не давала целевых цифр, пока мы не привели в порядок бэкенд.

Скорость на мобильных устройствах

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

Почему мобильные жёстче

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

Что делать

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

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

Мониторинг и регулярный контроль

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

Как держать руку на пульсе

• Регулярно проверяйте полевые Core Web Vitals в Google Search Console — там виден реальный тренд по вашей аудитории.
• Настройте автоматические проверки ключевых шаблонов, чтобы ловить регрессии сразу после релиза, а не через месяц.
• Установите бюджет производительности — предельный вес страницы и число скриптов, который команда не имеет права превышать.
• Каждый новый сторонний скрипт проходите как отдельное решение: что он даёт бизнесу и сколько стоит по скорости.

Кто следит

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

Главная мысль: измеряйте до и после каждого крупного изменения. Цифра «стало быстрее» должна быть доказанной, а не ощущаемой.

Практический чек-лист ускорения сайта

Соберём всё в один прикладной список. Идите по нему сверху вниз — пункты примерно отсортированы по соотношению «эффект к усилию». Не обязательно делать всё сразу, но пройтись по каждому пункту стоит.

Замер и приоритеты

1. Измерьте ключевые шаблоны в PageSpeed Insights (мобильные и десктоп) и запишите текущие Core Web Vitals.
2. Найдите LCP-элемент каждого важного шаблона и его главный тормоз.

Изображения

1. Переведите картинки в WebP или AVIF, иконки — в SVG.
2. Отдавайте адаптивные размеры через srcset, не крупнее контейнера.
3. Включите ленивую загрузку ниже первого экрана; LCP-картинку грузите с приоритетом.
4. Пропишите размеры изображений, чтобы не было сдвигов макета.

Код и шрифты

1. Вынесите критический CSS инлайном, остальное грузите отложенно.
2. Сократите начертания шрифтов, добавьте preload и font-display: swap.
3. Отложите скрипты через defer/async, уберите неиспользуемый CSS и JS.
4. Проведите ревизию сторонних виджетов и удалите лишнее.

Сервер и доставка

1. Включите серверный кэш и снизьте TTFB.
2. Настройте браузерное кэширование статики и сжатие Brotli/gzip.
3. Подключите CDN и современный протокол HTTP/2 или HTTP/3.
4. Минифицируйте HTML, CSS и JS.

Контроль

1. Проверьте результат на эмуляции слабого мобильного устройства.
2. Настройте мониторинг полевых метрик и бюджет производительности.
3. Перемеряйте до и после — фиксируйте выигрыш в цифрах.

Пройдёте этот чек-лист честно — и получите не просто красивый балл, а более быстрый, стабильный и прибыльный сайт. А это, в конце концов, и есть цель.

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