Метрики користувацького досвіду перетворилися з технічної деталі на робочий інструмент SEO. При цьому в обговореннях панує плутанина: одні стверджують, що все вирішує код, інші — що достатньо змінити хостинг. Правда посередині, і корисно чітко розділити, за що відповідає сервер, а за що — сторінка.
Із чого складається LCP
Показник найбільшого відображуваного елемента вимірює, коли користувач побачив основний контент. Він розкладається на чотири складові: час до першого байта відповіді, завантаження стилів і скриптів, які блокують відображення, завантаження самого елемента та його промальовування.
Перша складова — цілком зона відповідальності інфраструктури. І вона ж найчастіше стає прихованим тягарем: якщо сервер думає 800 мілісекунд, у вас залишається менше ніж 1,7 секунди на все інше, щоб укластися в рекомендований поріг.
Що саме в сервері впливає на час до першого байта
- Швидкість дискової підсистеми. Кожен запит до бази — це операції введення-виведення, і на повільному диску вони стають вузьким місцем.
- Версія та налаштування інтерпретатора. Актуальна версія PHP з увімкненим кешем байт-коду дає відчутний приріст без змін коду.
- Конкуренція за ресурси. На переущільненому спільному сервері ваш запит стоїть у черзі за чужими.
- Географічна відстань. Фізична затримка мережі додається до кожного з’єднання.
- Наявність серверного кешу. Готова відповідь із кешу віддається в рази швидше за згенеровану.
INP: тут сервер майже ні до чого
Метрика відгуку на взаємодію вимірює затримку між дією користувача і візуальною реакцією сторінки. Вона майже повністю визначається тим, наскільки завантажений головний потік браузера. Важкі скрипти, довгі задачі обробки, надлишкові обробники подій — ось причини поганого показника. Заміна хостингу тут не допоможе, потрібна робота з фронтендом.
Практичний висновок: не варто чекати, що переїзд на швидший сервер виправить усі метрики. Він виправляє одну конкретну складову, зате ту, без якої решта оптимізацій втрачає сенс.
Порядок дій, який дає результат
Спочатку виміряйте час відповіді сервера за польовими даними реальних користувачів, а не в лабораторному тесті. Якщо він виходить за рекомендовані межі, переходьте на інфраструктуру з швидкими дисками й адекватною щільністю розміщення. Якісний хостинг на NVMe-дисках із серверним кешуванням зазвичай знімає цю проблему одразу після міграції.
Далі оптимізуйте критичний шлях відображення: приберіть блокуючі ресурси, задайте пріоритет завантаження головного зображення, винесіть некритичні скрипти. І лише потім беріться за тонке налаштування взаємодії.
Чому це особливо актуально для української аудиторії
Як виміряти правильно
Лабораторний тест на швидкому каналі й потужному процесорі показує оптимістичну картину, яка мало пов’язана з реальністю. Орієнтуйтеся на польові дані від справжніх відвідувачів за останні 28 днів — саме вони враховуються при оцінці якості сторінки. Якщо польових даних бракує через невеликий трафік, беріть лабораторні, але з обмеженням швидкості мережі та зниженою продуктивністю процесора в налаштуваннях інструмента.
І дивіться на розподіл, а не на середнє значення. Показник вважається пройденим, якщо в межі вкладаються 75% візитів. Середнє арифметичне здатне приховати ситуацію, коли чверть ваших користувачів чекає вдвічі довше за решту.
Значна частина трафіку в Україні йде з мобільних пристроїв, часто в умовах нестабільного покриття. На повільному з’єднанні кожна зайва мілісекунда серверної затримки й кожен зайвий кілобайт множаться на реальні секунди очікування. Сайт, який на офісному Wi-Fi здається миттєвим, у мобільній мережі на околиці міста може вантажитися вісім секунд. Тестуйте саме в таких умовах — вони ближчі до реальності вашого відвідувача, ніж лабораторний прогін на швидкому каналі.