Core Web Vitals оценивают не абстрактную «скорость сайта», а важные элементы пользовательского опыта: насколько быстро появляется основной контент, насколько отзывчив интерфейс и насколько стабильно расположены элементы страницы. Для практической работы нужно понимать три метрики — LCP, INP и CLS.
Что означают LCP, INP и CLS
| Метрика | Что измеряет | Что обычно мешает |
|---|---|---|
| LCP | Скорость появления крупнейшего значимого элемента | Тяжёлое изображение, медленный сервер, блокирующий CSS/JS |
| INP | Отзывчивость страницы на действия пользователя | Долгие задачи JavaScript, тяжёлые обработчики |
| CLS | Визуальную стабильность | Изображения без размеров, поздние баннеры, смена шрифтов |
Как улучшить LCP
Сначала определите LCP-элемент. На главной странице им часто становится hero-изображение или крупный заголовочный блок, в статье — основная картинка. Если браузер узнаёт о важном изображении поздно, даже хороший сервер не спасёт показатель.
- Используйте WebP/AVIF там, где это даёт реальную экономию.
- Не загружайте изображение значительно крупнее размера отображения.
- Не ставьте lazy-load на изображение первого экрана, если оно является LCP.
- Сократите цепочку CSS и JS, блокирующую первый рендер.
- Проверьте TTFB и кэширование HTML/ресурсов.
Как улучшить INP
INP ухудшается, когда после клика, ввода или другого действия главный поток занят JavaScript. Типичный пример — один большой обработчик, который синхронно перерабатывает DOM, запускает несколько вычислений и только потом позволяет браузеру отрисовать результат.
Разбивайте большие задачи, уменьшайте объём JavaScript на странице, откладывайте необязательные виджеты и проверяйте сторонние скрипты аналитики, чатов и рекламы. Если интерфейс использует живой поиск, фильтр или корзину, измеряйте отзывчивость именно этих сценариев.
Как уменьшить CLS
CLS — это неожиданные сдвиги. Чаще всего они появляются, когда изображение или iframe загружается без заранее зарезервированного места, либо когда сверху вставляется поздний баннер.
- Задавайте width/height или aspect-ratio для изображений.
- Резервируйте место под iframe, рекламу и виджеты.
- Не вставляйте новый контент над уже показанным блоком без действия пользователя.
- Настройте загрузку веб-шрифтов так, чтобы замена шрифта не разрушала геометрию.
Лабораторные и полевые данные
Лабораторный тест полезен для диагностики конкретной загрузки, но реальные пользователи могут иметь другие устройства, сеть и поведение. Поэтому не стоит оптимизировать сайт только ради одной оценки в тесте. Важнее найти повторяющиеся причины и проверить, как изменения влияют на реальные страницы.
Что проверять на MODX-сайте
На MODX часто полезно начать с шаблона: какие CSS и JavaScript подключаются на всех страницах, действительно ли они нужны, нет ли дублирующихся библиотек, как формируются изображения и кэшируются сниппеты. Для каталога и блога отдельно проверьте карточки, изображения, фильтры и динамические компоненты.
Практический план оптимизации
- Выберите 3–5 наиболее важных шаблонов страниц.
- Измерьте исходное состояние.
- Определите LCP-элемент и самые долгие main-thread задачи.
- Оптимизируйте изображения и критические ресурсы.
- Уберите ненужный JavaScript первого экрана.
- Зарезервируйте размеры динамических блоков.
- Повторите тест на мобильном профиле.
- После публикации контролируйте реальные данные.
Не гонитесь за 100 баллами любой ценой
Высокий балл сам по себе не является бизнес-целью. Иногда полезный виджет, карта или аналитика добавляют нагрузку, но помогают пользователю. Задача оптимизации — убрать неоправданные задержки и нестабильность, сохранив нужный функционал.
Связанные материалы
FAQ
Core Web Vitals — это единственный фактор SEO?
Нет. Технические показатели важны, но не заменяют релевантный контент, нормальную индексацию, ссылки и соответствие поисковому интенту.
Что исправлять первым?
Исправляйте очевидные тяжёлые ресурсы и проблемы первого экрана, затем JavaScript и стабильность макета. Приоритет определяйте по наиболее важным страницам сайта.
Как измерять Core Web Vitals правильно
Лабораторный тест Lighthouse полезен для диагностики, но оценивать эффект нужно и по полевым данным реальных пользователей. Один быстрый запуск на мощном компьютере не показывает, как страница ведёт себя на мобильной сети, старом устройстве или при загрузке сторонних виджетов.
LCP: ищем реальный главный элемент
Частая причина плохого LCP — крупное hero-изображение, которое загружается поздно, фон через CSS, тяжёлый шрифт или серверный TTFB. Сначала определите конкретный LCP-элемент, затем оптимизируйте его загрузку: размер изображения, формат, preload, серверный ответ и критический CSS.
INP: проблема не только в одном JavaScript-файле
Высокий INP появляется, когда главный поток занят длинными задачами. Проверьте обработчики кликов, сторонние скрипты, тяжёлые рендеры, большие JSON-данные и повторные DOM-операции. Разбивайте долгие задачи и откладывайте то, что не нужно для первого взаимодействия.
CLS: резервируйте место заранее
Размеры изображений, баннеров, iframe и динамических блоков должны быть известны до загрузки. Не вставляйте новые элементы над уже прочитанным контентом без зарезервированного места. Отдельно проверьте webfonts: смена метрик шрифта также может сдвигать интерфейс.
Что проверять после оптимизации
После изменений сравните не только балл, но и TTFB, LCP-элемент, объём JavaScript, количество long tasks и реальные сценарии пользователя. Цель — не «100/100», а стабильная быстрая страница, которая не ломается после подключения аналитики, чата или рекламы.
Метрика → что обычно тормозит
| Метрика | Частые причины |
|---|---|
| LCP | медленный TTFB, hero image, CSS/font blocking |
| INP | тяжёлый JS, длинные tasks, сторонние виджеты |
| CLS | изображения без размеров, поздние баннеры, шрифты |
| TTFB | backend/БД/API/cache |
Начинайте с реальных пользователей, а не только Lighthouse
Лабораторный тест нужен для диагностики, но оценивать улучшение полезно по полевым данным и сегментам устройств. Один мощный ноутбук не показывает опыт мобильного пользователя.
Найти тяжёлые ресурсы через Performance API
performance.getEntriesByType('resource')
.sort((a, b) => b.duration - a.duration)
.slice(0, 20)
.map(x => ({
name: x.name,
duration: Math.round(x.duration),
size: x.transferSize
}));Практический порядок
| Шаг | Действие |
|---|---|
| 1 | измерить URL и шаблон |
| 2 | исправить TTFB/LCP resource |
| 3 | убрать длинные JS tasks |
| 4 | задать размеры media |
| 5 | повторить измерение |
| 6 | |
| удшились соседние страницы |
Как проверить результат
После изменений повторите исходный сценарий, зафиксируйте результат и убедитесь, что соседние функции работают так же, как до правки. Если проблема проявляется не всегда, проведите несколько повторов в одинаковых условиях и сохраните диагностические данные.