Core Web Vitals: як виправити кожну з трьох метрик
Core Web Vitals - три показники Google, якими він міряє, наскільки зручно людині користуватися сторінкою: чи швидко зʼявився основний вміст, чи швидко сторінка відповідає на дії і чи не стрибає під пальцем верстка.
Що це за метрики, які пороги і де їх подивитися, ми розібрали в статті про PageSpeed Insights. Тут - інше: що конкретно робити, коли якась із трьох метрик у червоній зоні. По кожній окремо, бо причини й виправлення в них різні.
Коротко про пороги, щоб не повертатися: LCP до 2,5 секунди, INP до 200 мілісекунд, CLS до 0,1. Усі три рахуються за 75-м перцентилем реальних візитів за останні 28 днів.
1. Де дивитися по всьому сайту
PageSpeed показує одну сторінку. Щоб побачити картину цілком, потрібен звіт Основні веб-показники у Google Search Console, розділ Якість.
Він бере ті самі польові дані Chrome, але групує сторінки за схожістю верстки. Тому одразу видно головне: проблема на одній сторінці чи на цілому шаблоні. Для роботи це принципово - ви лагодите шаблон картки товару, а не двісті карток окремо.
Звіт розділений на мобільні й десктопні дані, і дивитися треба передусім мобільні. Усередині - три зони: повільні, потребують пришвидшення, швидкі. Клікнувши на проблемну групу, побачите приклади URL і яка саме метрика не проходить.
⚠️ Дані запізнюються. Звіт оновлюється раз на кілька днів і рахує 28-денне вікно, тому ефект від виправлення видно не раніше ніж за два-три тижні. Це нормально і не привід переробляти все ще раз.
2. LCP: контент довго не зʼявляється
Що це. Час, за який відмалювався найбільший видимий елемент у першому екрані. Зазвичай це головне зображення, банер або великий заголовок.
Google розкладає LCP на чотири частини, і в кожної своє лікування.
Повільна відповідь сервера. Найчастіше це приблизно 40% усього часу LCP. Якщо сервер думає довго, далі вже нічого не допоможе. Лікується кешуванням, нормальним хостингом і зменшенням кількості переадресацій: кожен зайвий редирект додає повний цикл запиту.
Браузер пізно дізнається про потрібну картинку. Класика: головне зображення підвантажується скриптом або через CSS-фон, тому браузер бачить його не одразу. Лікується просто - зображення має бути звичайним тегом у HTML, з fetchpriority="high" для головного.
🔴 І окреме: не ставте lazy loading на зображення першого екрана. Відкладене завантаження корисне для всього, що нижче, але для LCP-елемента воно прямо шкідливе. Це одна з найчастіших причин поганого LCP на сайтах, де «зробили оптимізацію картинок».
Картинка завантажується довго. Тут працюють формати WebP і AVIF замість JPEG, стиснення і віддача зображення в тому розмірі, у якому воно показується, а не в оригінальному.
Рендер блокують стилі та скрипти. Синхронні скрипти в <head> зупиняють відмальовування. Лікується атрибутом defer і винесенням критичного CSS.
3. INP: сторінка гальмує у відповідь на дії
Що це. Затримка між дією користувача і видимою реакцією сторінки: натиснули кнопку, а меню відкрилося за півсекунди. INP замінив стару метрику FID і міряє не першу взаємодію, а всі за час візиту.
Причина завжди одна й та сама: основний потік браузера зайнятий JavaScript. Відрізняються лише деталі.
Довгі задачі під час завантаження. Поки браузер розбирає й виконує великий скрипт, він не може відреагувати ні на що. Лікується розбиттям роботи на дрібні частини і відкладанням того, що не потрібно одразу.
Важкі обробники подій. Коли на клік підвішено багато обчислень. Тут допомагає спочатку показати реакцію інтерфейсу, а решту роботи зробити після.
Занадто великий DOM. Сторінка на кілька тисяч елементів змушує браузер перераховувати стилі довго. Типовий випадок - каталог, який вивантажує всі товари одразу замість посторінкового виводу.
На практиці для більшості сайтів малого бізнесу INP псують не власні скрипти, а сторонні: чати, віджети зворотного дзвінка, попапи, кілька систем аналітики одночасно. Перше, що варто зробити - перелічити все, що стоїть на сайті, і чесно відповісти, чим із цього справді користуються.
4. CLS: верстка стрибає
Що це. Наскільки елементи зміщуються під час завантаження. Метрика без одиниць виміру, і саме вона найчастіше псує враження: людина тягнеться до кнопки, а на її місце стрибає банер.
Хороша новина: CLS найдешевше лагодити. Причин небагато, і вони очевидні.
Зображення без розмірів. Причина номер один. Браузер не знає, скільки місця зарезервувати, тому підставляє картинку після завантаження і зсуває все нижче. Лікується атрибутами width і height у тезі або властивістю aspect-ratio у стилях.
Реклама і вбудовані блоки. Те саме, але гірше, бо їхня висота заздалегідь невідома. Рішення - задати контейнеру мінімальну висоту.
Шрифти. Текст спершу малюється системним шрифтом, потім перемальовується вебшрифтом іншого розміру, і все зміщується. Лікується властивістю font-display і підбором резервного шрифту зі схожими пропорціями.
Анімації через top і left. Такі зміни змушують браузер перераховувати всю розкладку. Правильно анімувати через transform.
Контент, що зʼявляється зверху. Банер про куки, повідомлення про акцію, панель згоди - усе, що вставляється над наявним вмістом і штовхає його вниз. Або резервувати місце, або показувати поверх, не зсуваючи.
5. Порядок роботи
Як ми підходимо до цього на проєктах.
Спершу дивимось, чи є проблема взагалі. Якщо в звіті Search Console усі URL у зеленій зоні, займатися швидкістю не потрібно, навіть якщо лабораторний бал PageSpeed невисокий. Це найчастіша зайва робота в цій темі.
Далі шукаємо шаблон, а не сторінку. Якщо проблемних URL сотні, вони майже завжди одного типу. Одна правка в шаблоні закриває всю групу.
Починаємо з CLS. Він найдешевший: часто це буквально дописати розміри зображенням. LCP другий, INP останній, бо він зазвичай вимагає розбиратися з чужими скриптами.
Чекаємо три тижні. Не робимо висновків раніше і не переробляємо все вдруге, поки не оновилось 28-денне вікно.
І чесна рамка очікувань: Core Web Vitals - фактор ранжування, але слабкий. Він працює як гігієна. Сайт, який провалює всі три метрики, втрачає і позиції, і конверсію. Але виправлення метрик саме собою не виводить сторінку в топ, якщо з контентом і посиланнями порожньо.