Щоб покращити показник INP (Interaction to Next Paint) у WordPress та WooCommerce, необхідно звільнити основний потік браузера (Main Thread). Для цього розбивають тривалі JavaScript-завдання (Long Tasks > 50 мс), оптимізують скрипти кошика WooCommerce, налаштовують дебаунсинг обробників подій і спрощують структуру DOM-дерева.
Що таке INP і чому це критично для WordPress та WooCommerce
Метрика Interaction to Next Paint (INP) є офіційним показником Google Core Web Vitals. Вона оцінює загальну чутливість інтерфейсу протягом усього сеансу перебування користувача на сторінці. Згідно з документацією Google щодо INP, метрика фіксує найдовшу затримку відповіді сайту на такі дії користувача, як кліки по кнопках, тапи на мобільних пристроях та введення символів у форми.
Стандарти Google визначають три діапазони якості:
- Добре (≤ 200 мс): інтерфейс реагує без відчутних затримок.
- Потребує покращення (201–500 мс): помітні мікрозависання інтерфейсу.
- Погано (> 500 мс): виражене блокування дій користувача.
В інтернет-магазинах на WooCommerce затримка реакції при кліку на кнопку «Купити», відкритті міні-кошика або фільтрації каталогу безпосередньо шкодить користувацькому досвіду та може призводити до відмов від покупки.
Анатомія затримки: з чого складається INP
Відповідно до посібника web.dev з оптимізації INP, затримка взаємодії складається з трьох послідовних компонентів:
- Input Delay (Затримка вхідного сигналу): час від фізичної дії користувача (клік, тап) до моменту, коли браузер може запустити обробник події. Якщо Main Thread зайнятий виконанням фонового JS, клік стає в чергу очікування.
- Processing Time (Час обробки): тривалість виконання JavaScript-коду, прив’язаного до події (наприклад, перерахунок замовлення чи валідація форми).
- Presentation Delay (Затримка відображення): час, необхідний браузеру для перерахунку стилів (Recalculate Style), макета (Layout) та відмальовки кадру (Paint/Composite).
Діагностика: як знайти Long Tasks у WordPress
Згідно зі специфікацією MDN Long Tasks API, будь-яка задача в головному потоці браузера тривалістю понад 50 мілісекунд вважається Long Task і блокує чергу подій.
Покроковий алгоритм виявлення проблем у Chrome DevTools:
- Відкрийте цільову сторінку (картку товару чи каталог) у режимі інкогніто.
- Відкрийте DevTools (F12) та перейдіть у вкладку Performance.
- Увімкніть обмеження процесора (CPU: 4x або 6x slowdown), щоб емулювати потужність середнього смартфона.
- Натисніть Record, здійсніть взаємодію (наприклад, клік на кнопку «Додати у кошик» чи відкриття фільтрів) і зупиніть запис.
- У секції Interactions перегляньте деталі затримки (Input Delay, Processing, Presentation Delay), а в доріжці Main знайдіть червоні трикутники тривалих задач.
Діагностична матриця прийняття рішень
| Симптом у DevTools | Ймовірна причина | Інженерне рішення |
|---|---|---|
| Input Delay > 50 мс | Потік блокується важкими скриптами під час завантаження (слайдери, чати, пікселі). | Додати defer/async, відкласти ініціалізацію сторонніх віджетів до першої взаємодії. |
| Processing Time > 100 мс | Важкі функції зворотного виклику (event listeners), довгі синхронні цикли, AJAX WooCommerce. | Дебаунсинг обробників, розбиття коду через scheduler.yield() або setTimeout. |
| Presentation Delay > 100 мс | Надмірна глибина DOM (> 1500 вузлів) через візуальні білдери, складні CSS-правила. | Спрощення DOM-дерева в Elementor/конструкторах, використання content-visibility: auto. |
Покроковий план оптимізації INP у WordPress та WooCommerce
Крок 1. Оптимізація та робота з cart-fragments у WooCommerce
За замовчуванням скрипт wc-cart-fragments.js надсилає AJAX-запит wc-ajax=get_refreshed_fragments для оновлення вмісту міні-кошика на кожній сторінці. Це створює навантаження на PHP і блокує ресурси браузера під час завантаження сторінки.
Якщо на сторінках блогу чи статичних сторінках міні-кошик не потрібен, виклик скриптів можна безпечно деактивувати:
add_action('wp_enqueue_scripts', function() {
if (function_exists('is_woocommerce') && !is_woocommerce() && !is_cart() && !is_checkout()) {
wp_dequeue_script('wc-cart-fragments');
}
}, 99);Важливо: Повне відключення
wc-cart-fragmentsна сторінках каталогу або товару без налаштування альтернативного оновлення через клієнтський JavaScript (LocalStorage) може порушити коректне оновлення лічильника кошика в кастомних темах. Перед вимкненням перевірте роботу міні-кошика в режимі інкогніто.
Крок 2. Розбиття Long Tasks і повернення керування браузеру
Коли функція виконує масивні обчислення під час кліку, браузер не може відмалювати зміну стану елемента (наприклад, стан натиснутої кнопки). Використовуйте асинхронні паузи за допомогою scheduler.yield() або переходу на мікрозавдання:
async function handleProductFilterClick(event) {
showVisualFeedback(event.target); // Негайний відгук інтерфейсу
// Повертаємо керування браузеру для рендерингу кадру
if ('scheduler' in window && 'yield' in window.scheduler) {
await window.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
performHeavyFilterCalculation(); // Важкі обчислення
}Крок 3. Дебаунсинг і тротлінг обробників подій
Події живого пошуку (input), зміни розміру вікна (resize) або скролу каталогу (scroll) можуть спрацьовувати десятки разів на секунду, перевантажуючи потік. Застосовуйте дебаунсинг (debounce), щоб запускати обробку лише після паузи у взаємодії:
function debounce(func, delay = 150) {
let timeoutId;
return function(...args) {
clearTimeout(timeoutId);
timeoutId = setTimeout(() => func.apply(this, args), delay);
};
}
const liveSearchInput = document.querySelector('#ajax-product-search');
if (liveSearchInput) {
liveSearchInput.addEventListener('input', debounce((e) => {
fetchSearchResults(e.target.value);
}, 200));
}Крок 4. Зменшення розміру DOM-дерева та рендерингу
Високий показник Presentation Delay часто виникає через візуальні конструктори сторінок (Elementor, Divi), які створюють надлишкову кількість обгорток <div>. Коли клік викликає зміну DOM, браузер змушений перераховувати позицію тисяч елементів.
- Увімкніть опцію Optimized DOM Output та Flexbox/Grid-контейнери в Elementor для скорочення кількості вкладених контейнерів.
- Застосовуйте CSS-властивість
content-visibility: auto;для довгих каталогів товарів, щоб рендеринг блоків за межами екрана відбувався лише при наближенні скролу. - Уникайте універсальних і надмірно складних селекторів CSS (наприклад,
.catalog * div:nth-child(2) span), які сповільнюють фазу Recalculate Style.
Крок 5. Ізоляція важких сторонніх скриптів
Онлайн-чати, віджети зворотного дзвінка та маркетингові пікселі часто запускають фонові таймери, що перехоплюють Main Thread у момент, коли користувач намагається взаємодіяти з сайтом.
- Завантажуйте маркетингові скрипти через Google Tag Manager із тригером за подією першої взаємодії (Scroll або Mouse Movement), а не при старті сторінки.
- Використовуйте статичну кнопку-заглушку (фасад) для онлайн-чату, яка підвантажує важкий бандл скриптів віджета лише після реального кліку користувача.
Чек-лист контролю показника INP
- [ ] Показник INP на ключових шаблонах (головна, каталог, картка товару, checkout) не перевищує 200 мс на мобільних пристроях.
- [ ] Усі сторонні аналітичні скрипти мають атрибути
deferабо підвантажуються асинхронно. - [ ] Скрипт
cart-fragments.jsоптимізований або відключений на сторінках, де міні-кошик відсутній. - [ ] Обробники живого пошуку та фільтрів використовують
debounce. - [ ] Загальна кількість DOM-елементів на сторінці каталогу не перевищує 1400–1500 вузлів.
Висновок
Оптимізація INP у WordPress та WooCommerce вимагає інженерного аналізу поведінки JavaScript та структури рендерингу сторінок. На відміну від метрик завантаження, де достатньо встановити плагін кешування, оптимізація відгуку інтерфейсу досягається очищенням основного потоку та коректним розподілом пріоритетів виконання коду.
Якщо вашому інтернет-магазину або корпоративному проєкту потрібна комплексна оптимізація сайту та усунення затримок Core Web Vitals, команда VORONOV Solutions проведе детальний аудит коду, налаштує роботу скриптів і допоможе досягти високої швидкості роботи інтерфейсу.