Заказ звонка

Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности

Главная
/
Инструкции
/
Как ускорить сайт на основе Core Web Vitals

Как ускорить сайт на основе Core Web Vitals

Core Web Vitals = как Google «чувствует» сайт с точки зрения реального пользователя.

Это 3 метрики, которые отвечают на вопросы:

Когда страница реально загрузилась? → LCP
Не прыгает ли интерфейс? → CLS
Насколько сайт отзывчив? → INP

1️⃣ LCP — Largest Contentful Paint «Когда появилось главное на экране»
Простыми словамиLCP — это время, за которое самый крупный видимый элемент (баннер, фото, заголовок, видео) появился на экране. Пользователь думает: «А, сайт загрузился»

Нормы Google✅ до 2.5 сек — хорошо
⚠️ 2.5–4 сек — надо улучшать
❌ больше 4 сек — плохо

Где смотреть

Google PageSpeed Insights
Google Search Console → Основные интернет-показатели
Lighthouse (в Chrome DevTools)

Типичные причины плохого LCPТяжёлые изображения

Медленный сервер (TTFB)
Рендер блокируется CSS / JS
LCP-элемент грузится слишком поздно
Что делатьОптимизировать изображения (WebP, AVIF)
Загружать LCP-картинку без lazy
Inline critical CSS
Убрать лишний JS в <head>
Использовать CDN

2️⃣ CLS — Cumulative Layout Shift «Ничего не прыгает?»
Простыми словамиCLS — это когда ты хочешь нажать кнопку, а контент внезапно сдвинулся 😡

Нормы Google✅ до 0.1 — отлично
⚠️ 0.1–0.25 — терпимо
❌ больше 0.25 — плохо

Где смотретьPageSpeed Insights

Search Console
Chrome DevTools → Performance → Layout Shifts

Типичные причины

Картинки без width и height
Реклама, которая догружается позже
Web-шрифты без font-display
Динамически вставляемые блоки
Что делатьЗадавать размеры изображениям и iframe
Резервировать место под баннеры
font-display: swap
Не вставлять новые блоки сверху страницы

3️⃣ INP — Interaction to Next Paint «Сайт быстро реагирует?»
INP заменил FID — сейчас это главная метрика интерактивности
Простыми словамиINP — сколько времени проходит между действием пользователя (клик, ввод) и реакцией сайта

Нормы Google✅ до 200 мс — хорошо
⚠️ 200–500 мс — так себе
❌ больше 500 мс — плохо

Где смотретьPageSpeed Insights

Search Console
Chrome DevTools → Performance

Типичные причины

Длинные JS-таски
Тяжёлые фреймворки
Много сторонних скриптов
Плохая работа с событиями
Что делатьРазбивать длинный JS (code splitting)
Убирать лишние библиотеки
Откладывать сторонние скрипты
Использовать Web Workers
Оптимизировать обработчики событий

📊 Где смотреть ВСЕ СРАЗУ (коротко)
🔹 Google Search Console - Отчёт по реальным пользователям

Данные за 28 дней
Важно для SEO
Показывает группы проблемных URL

🔹 PageSpeed Insights - Реальные данные (CrUX) + лабораторные

Конкретные рекомендации
Можно проверить любую страницу

🔹 Lighthouse - Для разработчиков

Лабораторные замеры
Удобно для отладки

🔬 Как анализировать (алгоритм)

Сначала Search Console — понять масштаб проблемы
PageSpeed Insights — посмотреть конкретные причины
DevTools / Lighthouse — подтвердить технически

🛠️ Исправлять по приоритету:

📌 Что делать с выводами

Если всё зелёное → отлично, ничего не ломаем
Если жёлтое → план улучшений
Если красное → срочно в техработы (SEO реально страдает)

Важно: изменения видны в Search Console через 2–4 недели, не сразу.

Алгоритм ускорения сайта

Ниже — практический алгоритм, который помогает улучшить Core Web Vitals: LCP (загрузка главного), CLS (стабильность) и INP (отзывчивость).

Шаг 1. Зафиксируйте «что болит» по реальным пользователям

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

Откройте Search Console → Основные интернет‑показатели и посмотрите группы URL со статусом «Плохо» / «Нужно улучшить».
Запишите, какая метрика падает: LCP, CLS или INP.
Выберите 1–2 шаблона страниц с максимальным трафиком для первичного исправления.

📌 Рекомендации: чините сначала шаблонные страницы (одна правка → десятки/сотни URL), так прогресс увидите быстрее.

Шаг 2. Найдите причины на конкретной странице

Теперь берём по одному URL из проблемной группы и уточняем причины через PageSpeed/Lighthouse — они быстро показывают, что именно мешает скорости.

Откройте PageSpeed Insights и посмотрите, что отмечено как LCP‑элемент, источники CLS и причины задержек.
В Chrome DevTools → Performance проверьте: длинные задачи JS, Layout Shifts, загрузку ресурсов.
Зафиксируйте 2–3 главные причины (не пытайтесь исправить всё сразу).

📌 Рекомендации: ускоряем не «сайт в целом», а конкретную метрику и её конкретный источник.

Шаг 3. Ускорьте LCP (главное на первом экране)

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

Оптимизируйте LCP‑изображение: WebP/AVIF, правильный размер под экран, сжатие без потери читаемости.
Не ставьте lazy‑load на LCP‑картинку — она должна грузиться одной из первых.
Уберите лишний CSS/JS из <head>, важные стили первого экрана отдайте раньше (critical CSS).
Снизьте время ответа сервера (TTFB): кэширование, оптимизация «тяжёлых» запросов, CDN.

📌 Рекомендации: если LCP «плавает», проверяйте несколько раз и сравнивайте с данными реальных пользователей — лабораторный тест не всегда совпадает с реальностью.

Шаг 4. Уберите CLS (всё должно быть стабильно)

CLS — это «прыжки» интерфейса. Чаще всего виноваты картинки без размеров, догружаемая реклама/виджеты и шрифты.

Задайте width и height для изображений и iframe (или фиксируйте соотношение сторон).
Резервируйте место под баннеры и виджеты, чтобы блок был сразу, даже если содержимое появится позже.
Для шрифтов включите font-display: swap, чтобы текст отображался сразу и не «прыгал».
Не вставляйте новые блоки сверху страницы после загрузки.

📌 Рекомендации: CLS часто чинится быстро — начните с шаблонов, где есть баннеры, поп‑апы и «липкие» панели.

Шаг 5. Улучшите INP (сайт должен реагировать быстро)

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

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

📌 Рекомендации: если INP плохой на большинстве страниц — почти всегда виноваты общие скрипты и сторонние сервисы. Начните с ревизии именно их.

Шаг 6. Перемерьте результат и дайте данным обновиться

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

После релиза проверьте 3–5 ключевых страниц через PageSpeed/Lighthouse.
Смотрите, как меняются группы проблемных URL в Search Console.
Если стало лучше в тестах, но в Search Console ещё «красное», просто подождите накопления новой статистики.

📌 Рекомендации: ведите мини‑лог изменений (дата → что сделали → какие шаблоны затронули) — так проще понять, что реально сработало.

Шаг 7. Введите «регламент скорости», чтобы не откатываться

Сайт часто замедляется снова: добавили виджет, баннер, шрифт — и метрики поехали.

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

📌 Рекомендации: скорость — это процесс. Один раз «ускорить» можно, но без правил вы будете регулярно возвращаться к тем же проблемам.

🔵 Узнайте, что мешает вашему сайту расти в поиске и получать больше заявок

Записаться на бесплатный аудит