На прошлой неделе мне позвонил клиент — владелец интернет-магазина на WooCommerce. Трафик упал на 30% за месяц, хотя контент тот же, ссылки растут, бюджет на рекламу не менялся. Первое, что я проверил — Google Search Console. В отчёте Core Web Vitals на мобильных красным горело: INP — 620ms. Шестьсот двадцать. При пороге «хорошо» в 200ms.
Это не единичный случай. В 2026 году INP (Interaction to Next Paint) стал метрикой, которая систематически топит WordPress-сайты в выдаче. LCP и CLS мы научились чинить — сжал картинки, добавил ширину/высоту, включил кеш — и готово. Но INP требует совсем другого подхода. Причём подхода, который в 90% случаев означает работу с JavaScript, а не с сервером.
В этой статье я разберу, что такое INP на самом деле, почему WordPress-сайты так уязвимы, и — главное — покажу конкретные шаги, которые я применяю на своих проектах, чтобы вытащить INP из красной зоны.
Что такое Core Web Vitals в 2026 году: короткая сводка
Core Web Vitals — это три метрики, которые Google использует для оценки пользовательского опыта на сайте. В 2026 году они уже не просто «фактор ранжирования» — это фундамент. Сайты, которые не проходят CWV, не просто теряют небольшой бонус — они систематически пессимизируются.
Три метрики:
- LCP (Largest Contentful Paint) — скорость загрузки основного контента. Порог «хорошо»: до 2,5 секунд.
- INP (Interaction to Next Paint) — отзывчивость страницы на действия пользователя. Порог «хорошо»: до 200ms.
- CLS (Cumulative Layout Shift) — визуальная стабильность. Порог «хорошо»: до 0,1.
INP заменил FID (First Input Delay) в марте 2024 года. Ключевое отличие: FID измерял только первую интеракцию, а INP измеряет все взаимодействия пользователя со страницей за весь визит. Это меняет всё. Сайт мог показывать идеальный FID и при этом иметь ужасный INP — потому что третий клик по меню или ввод текста в поиск тормозил на 800ms.
Почему именно INP — главная проблема WordPress-сайтов
За последний год я проверил Core Web Vitals на нескольких десятках WordPress-проектов. Паттерн одинаковый: LCP чинится за час-два, CLS — за полчаса, а INP — это неделя отладки.
Вот почему WordPress так уязвим:
1. Плагины — каждый добавляет свой JavaScript
Средний коммерческий сайт на WordPress имеет 15-25 активных плагинов. Каждый из них может подключать свои скрипты на фронтенд. Формы контактов, слайдеры, попапы, аналитика, чат-виджеты, интеграции с CRM — всё это добавляет JavaScript, который выполняется в главном потоке браузера.
Я регулярно вижу сайты, где на странице загружается 1,5-2 МБ JavaScript. Большинство этого кода не нужно для текущей страницы, но он загружается и парсится — и блокирует главный поток.
2. Конструкторы страниц — Elementor, Divi и компания
Page builders добавляют тяжёлые фронтенд-фреймворки. Elementor, например, загружает свой фронтенд-модуль даже для простых страниц. Это не проблема для LCP (браузер отрисует контент, пока скрипты ещё выполняются), но это катастрофа для INP — потому что когда пользователь кликает по меню или кнопке, эти скрипты всё ещё занимают главный поток.
3. jQuery — вечный спутник WordPress
jQuery весит 85KB (минифицированный) и выполняется при каждой загрузке страницы. В 2026 году это выглядит архаизмом — современные браузеры поддерживают querySelectorAll, fetch, classList нативно. Но тысячи плагинов и тем всё ещё зависят от jQuery, и отказаться от него невозможно без переписывания.
4. Третьесторонние скрипты
Google Analytics, Яндекс.Метрика, Facebook Pixel, чат-виджеты, пиксели ретаргетинга — каждый из них добавляет JavaScript, который конкурирует за время главного потока. На одном проекте я насчитал 12 третьесторонних скриптов, каждый из которых добавлял по 30-80ms к длительности задач.
Как измерять INP: от данных поля к лаборатории
Прежде чем что-то чинить, нужно правильно измерить. INP — это полевая метрика, и лабораторные тесты (Lighthouse) не всегда её отражают.
Google Search Console — стартовая точка
В Search Console откройте « Core Web Vitals → Мобильные/Десктоп». Вы увидите группы URL с оценкой INP: хорошие, требуют улучшения, плохие. Данные агрегируются за 28 дней, так что изменения вы увидите не сразу.
PageSpeed Insights — поле + лаборатория
Вставляете URL и получаете два набора данных: полевые (реальные пользователи из Chrome UX Report) и лабораторные (симуляция Lighthouse). Для INP полевые данные важнее, потому что лабораторный тест может не触发нуть те же взаимодействия, что и реальные пользователи.
Chrome DevTools — точная диагностика
Это основной инструмент для глубокой отладки:
- Откройте DevTools → Performance
- Нажмите Record
- Взаимодействуйте со страницей (кликайте по меню, кнопкам, вводите текст)
- Остановите запись
- Смотрите на вкладку Interactions — там показана длительность каждого взаимодействия
Ищите «Long Tasks» — задачи дольше 50ms. Это они блокируют главный поток и убивают INP.
web-vitals JavaScript библиотека — для продакшена
Если хотите мониторить INP на проде, подключите библиотеку web-vitals от Google:
import {onINP} from 'web-vitals';
onINP((metric) => {
// Отправляем в аналитику
navigator.sendBeacon('/analytics', JSON.stringify(metric));
});Это даст вам реальные данные по каждому взаимодействию, с的诊断информацией: какой элемент, какой тип события, сколько времени заняло.
WordPress-специфичные фиксы: что реально работает
Перейдём к практике. Вот что я делаю на каждом проекте, где нужно вытащить INP.
1. Аудит подключённых скриптов
Первое, что я делаю — смотрю, какие скрипты вообще загружаются на странице. Через WP-CLI:
wp eval 'global $wp_scripts; foreach($wp_scripts->queue as $s) echo $s . "\n";'Или через плагин Query Monitor — он показывает все подключённые скрипты и стили с зависимостями.
Результат обычно шокирует клиентов. На одном проекте я обнаружил, что Contact Form 7 загружает свои скрипты на всех 200 страницах сайта, хотя форма была только на странице контактов. WooCommerce загружал cart fragments AJAX на каждой странице, включая блог. Плагин дляcookie-баннера подключал 120KB JavaScript — для простого баннера.
2. Условная загрузка скриптов
Самый быстрый выигрыш — загружать скрипты только там, где они нужны:
// Contact Form 7 — только на странице контактов
add_action('wp_enqueue_scripts', function() {
if (!is_page('contact')) {
wp_dequeue_script('contact-form-7');
wp_dequeue_style('contact-form-7');
}
});
// WooCommerce — не на страницах блога
add_action('wp_enqueue_scripts', function() {
if (!is_woocommerce() && !is_cart() && !is_checkout()) {
wp_dequeue_script('wc-cart-fragments');
}
});Только этот шаг на одном проекте сократил объём JavaScript на 40% и улучшил INP со 480ms до 280ms.
3. Defer и async для некритичных скриптов
Большинство аналитических скриптов и виджетов не нужны для начальной отрисовки. Их нужно откладывать:
// Defer Google Analytics
add_filter('script_loader_tag', function($tag, $handle) {
$defer_handles = ['google-analytics', 'gtm', 'facebook-pixel'];
if (in_array($handle, $defer_handles)) {
return str_replace(' src', ' defer src', $tag);
}
return $tag;
}, 10, 2);Чат-виджеты — отдельная история. Я загружаю их после того, как пользователь проявит активность:
// Загрузка чат-виджета при первом скролле
window.addEventListener('scroll', function() {
if (!window.chatLoaded) {
window.chatLoaded = true;
const script = document.createElement('script');
script.src = 'https://widget.chat.com/loader.js';
document.body.appendChild(script);
}
}, { once: true, passive: true });Это снимает 100-200ms с начальной нагрузки главного потока.
4. Разбиваем длинные задачи
Если у вас есть JavaScript, который делает много работы за один такт (обработка данных, рендеринг списков, сложные вычисления), его нужно разбивать:
// До: одна длинная задача
function processItems(items) {
items.forEach(item => {
heavyProcessing(item);
});
}
// После: разбиваем с yield
async function processItems(items) {
for (const item of items) {
heavyProcessing(item);
// Отдаём управление браузеру
if (navigator.scheduling?.isInputPending?.()) {
await new Promise(r => setTimeout(r, 0));
}
}
}scheduler.yield() — более современный API, но setTimeout работает как фоллбэк в большинстве браузеров.
5. Passive event listeners
Обработчики событий scroll и touch блокируют браузер от плавного скролла. Решение — добавлять { passive: true }:
// До: блокирующий
element.addEventListener('touchstart', handler);
// После: passive
element.addEventListener('touchstart', handler, { passive: true });Для WordPress-сайтов это особенно актуально, потому что многие плагины подключают touch-обработчики для мобильных меню и свайпов.
6. Оптимизация DOM
Большие DOM-деревья (более 1500 элементов) замедляют каждую интеракцию, потому что браузер пересчитывает стили и layout для всех элементов. На сайтах с Elementor я регулярно вижу DOM размером 3000-5000 узлов.
Что делать:
- Убрать лишние wrapper-дивы (да, я про вас, Elementor)
- Lazy-load контент ниже первого экрана
- Упростить layout конструктора — меньше секций, колонок, внутренних wrapper’ов
7. Уменьшаем зависимость от jQuery
Полностью отказаться от jQuery на WordPress сложно, но можно постепенно заменять отдельные участки:
// jQuery
$('.my-element').on('click', function() { ... });
// Нативный JS
document.querySelector('.my-element').addEventListener('click', function() { ... });
// jQuery: AJAX
$.get('/api/data', function(response) { ... });
// Нативный JS
fetch('/api/data').then(r => r.json()).then(response => { ... });На одном проекте я переписал 15 jQuery-обработчиков на нативный JS, и это дало улучшение INP на 60ms. Не революция, но в сумме с другими оптимизациями — критично.
Типичный план работ: от красного к зелёному
Вот мой стандартный процесс для проектов с плохим INP:
Шаг 1. Диагностика (2-3 часа)
- Search Console — какие URL в красной зоне
- PageSpeed Insights — полевые данные по ключевым страницам
- Query Monitor — список всех скриптов
- Chrome DevTools Performance — запись реальных взаимодействий
Шаг 2. Быстрые победы (4-6 часов)
- Условная загрузка Contact Form 7, WooCommerce cart fragments
- Defer для аналитики и пикселей
- Ленивая загрузка чат-виджетов
- Passive listeners для touch/scroll
Шаг 3. Средние задачи (1-2 дня)
- Аудит и удаление неиспользуемых плагинов
- Замена тяжёлых плагинов на лёгкие альтернативы
- Оптимизация DOM (упрощение layout)
- Разбивка длинных задач в кастомном JS
Шаг 4. Глубокая оптимизация (если нужно)
- Замена jQuery на нативный JS в критичных местах
- Web Workers для тяжёлых вычислений
- Переход на headless/декаплированную архитектуру для критичных страниц
Обычно шаги 1-2 вытаскивают INP из красной зоны (500+ms) в жёлтую (200-500ms). Шаг 3 доводит до зелёной. Шаг 4 нужен примерно в 20% случаев.
Инструменты, которые помогают
Несколько инструментов, без которых я не работаю с Core Web Vitals:
Query Monitor (плагин WordPress) — показывает все подключённые скрипты, стили, HTTP-запросы, запросы к БД. Бесплатный. Обязателен к установке на каждый проект.
WP-CLI — для аудита скриптов из командной строки. Быстрее, чем через админку.
Chrome DevTools Performance — основной инструмент для диагностики INP. Вкладка Interactions показывает длительность каждого взаимодействия.
web-vitals (JavaScript-библиотека) — для мониторинга в продакшене. Отправляет данные в вашу аналитику.
PageSpeed Insights — для быстрой проверки конкретных URL.
Real User Monitoring (RUM) — если проект крупный, стоит настроить полноценный RUM. Я использовал Sentry Performance и Vercel Speed Insights — оба показывают INP с разбивкой по страницам, браузерам, устройствам.
Частые ошибки при оптимизации INP
За годы практики я накопил список ошибок, которые вижу снова и снова:
1. Оптимизация LCP вместо INP
LCP и INP — разные метрики. Оптимизация серверного времени ответа (TTFB) и сжатие картинок не помогут с INP. INP — это про JavaScript.
2. Слепая вера в плагины кеширования
WP Rocket, LiteSpeed Cache и другие — отличные инструменты для LCP и CLS. Но для INP они делают минимум. Автоматическое.defer скриптов может сломать функционал. Нужен ручной подход.
3. Игнорирование мобильного трафика
На мобильных INP хуже в 2-3 раза по сравнению с десктопом. Процессоры слабее, сеть медленнее, JavaScript выполняется дольше. Если ваш сайт имеет мобильный трафик 70%+ (а у большинства коммерческих сайтов так), оптимизируйте сначала для мобильных.
4. Проверка только главной страницы
Главная страница часто имеет лучший INP, потому что на ней меньше интерактивных элементов. Проверяйте страницы каталога, карточки товаров, поиск — именно там пользователи взаимодействуют чаще всего.
5. Установка «быстрых» плагинов поверх старых
Установка плагина для оптимизации поверх 20 других плагинов не работает. Сначала аудит и удаление лишнего, потом оптимизация оставшегося.
Что говорит Google: тренды 2026 года
В 2026 году Google усиливает значимость Core Web Vitals как рангового сигнала. Несколько ключевых моментов:
Page Experience Signal стал строже. Если раньше плохие CWV были незначительным минусом, то теперь сайты с постоянным «провалом» по CWV получают систематическую пессимизацию. Это особенно заметно для мобильной выдачи.
INP — самый коррелирующий с конверсией показатель. Исследования показывают, что улучшение INP с 500ms до 200ms даёт прирост конверсии 5-15% на e-commerce сайтах. Это не SEO — это直接影响 бизнес-показатели.
Новые инструменты в Search Console. Google добавил более детальную разбивку по INP в Search Console, с группировкой по URL-шаблонам и историческими графиками.
Чеклист для самостоятельной проверки
Если вы хотите проверить свой WordPress-сайт прямо сейчас:
- Откройте PageSpeed Insights и введите URL вашего сайта. Посмотрите на INP в полевых данных.
- Если INP > 200ms — откройте Query Monitor в админке и посмотрите список скриптов на странице.
- Откройте Chrome DevTools → Performance, нажмите Record, покликайте по меню, кнопкам, поищите. Остановите запись и посмотрите Long Tasks.
- Проверьте Search Console → Core Web Vitals. Сколько URL в красной зоне?
- Сделайте список «тяжёлых» скриптов и решите, какие можно: отложить (defer), загрузить условно, удалить совсем.
Итоги
INP в 2026 году — это не техническая мелочь, а бизнес-критичная метрика. WordPress-сайты особенно уязвимы из-за архитектуры плагинов, jQuery и конструкторов страниц. Но это чинимо — системный подход от диагностики до оптимизации обычно вытаскивает INP в зелёную зону за 1-2 недели.
Главное — не пытайтесь чинить «всё сразу». Начните с аудита, получите быстрые победы (условная загрузка, defer), потом углубляйтесь. И измеряйте после каждого изменения — INP чувствителен к контексту, и то, что помогло одному сайту, может не помочь другому.
А как у вас обстоят дела с Core Web Vitals? Заглядывали в Search Console за последнее время? Делитесь в комментариях — обсудим.
