Google оцінює сайти не лише за текстами чи зворотними посиланнями, а й за тим, наскільки зручно на них перебувати реальній людині. Core Web Vitals — це набір метрик, які вимірюють саме це: швидкість завантаження, відгукливість і візуальну стабільність сторінки. Погані показники означають вищий відсоток відмов і нижчі позиції в пошуку. Хороші — довше тримають відвідувача і сигналізують пошуковику, що сайт працює як слід.
Усі метрики Core Web Vitals зводяться до трьох ключових показників. Нижче розберемо кожен із них без зайвої теорії — з фокусом на те, що саме перевіряти й як виправляти.
Що таке LCP і як його покращити
LCP (Largest Contentful Paint) показує, за який час найбільший елемент у видимій частині екрана стає повністю завантаженим і готовим до перегляду. Це може бути велике зображення, відеопостер, блок тексту на весь екран чи фонове зображення.
Google оцінює LCP так:
- до 2,5 секунди — добре;
- від 2,5 до 4 секунд — потребує покращення;
- понад 4 секунди — погано.
Що найчастіше гальмує LCP
Повільний сервер — перша причина. Якщо сервер обробляє запит три секунди, жодна оптимізація на фронтенді не допоможе. Друга — невиправдано важкі зображення. Третя — рендер-блокуючі ресурси: CSS і JavaScript, які завантажуються у верхній частині сторінки й не дають браузерові показати контент.
Практичні кроки для покращення LCP
Оптимізуйте зображення. Переведіть їх у сучасні формати — WebP або AVIF. Зменшуйте розмір до реальних потреб: немає сенсу завантажувати зображення 2400 пікселів завширшки, якщо воно відображається на 800. Для зображень поза першим екраном використовуйте lazy loading, але не застосовуйте його до головного зображення сторінки — воно якраз і є LCP-елементом у більшості випадків.
Прискорте відповідь сервера. Перевірте Time to First Byte (TTFB). Якщо він перевищує 800 мілісекунд, варто подивитися на хостинг, налаштувати кешування на рівні сервера, підключити CDN або оптимізувати серверну частину (базу даних, PHP-версію тощо).
Зменште вплив рендер-блокуючих ресурсів. Вбудований CSS і JavaScript у верхній частині сторінки затримують відображення контенту. Перенесіть непотрібний JS у кінець сторінки або додайте атрибути defer та async. Мінімізуйте CSS, видаляючи невикористані стилі.
Використовуйте preload для ключових ресурсів. Якщо LCP-елементом є зображення, додайте тег <link rel="preload"> у секцію <head>, щоб браузер почав завантажувати його раніше.
Що таке FID та INP і як їх оптимізувати
FID (First Input Delay) вимірює час від першої взаємодії користувача зі сторінкою (клік, натискання кнопки, вибір поля форми) до моменту, коли браузер фактично починає обробляти цю дію. Проблема FID у тому, що він фіксує лише першу взаємодію — а користувачів зазвичай цікавить увесь досвід роботи зі сторінкою.
Саме тому з березня 2024 року Google замінив FID на нову метрику — INP (Interaction to Next Paint).
Як працює INP
INP фіксує затримку для всіх взаємодій на сторінці протягом усього сеансу, а не лише для першої. З усіх вимірюваних взаємодій береться найгірший результат (або близький до нього) — він і стає фінальним INP сторінки.
Оцінка INP:
- до 200 мілісекунд — добре;
- від 200 до 500 мілісекунд — потребує покращення;
- понад 500 мілісекунд — погано.
Що спричиняє поганий INP
Головна причина — довгі завдання в головному потоці браузера (main thread). Коли JavaScript виконується тривалий час без перерв, браузер не може реагувати на дії користувача. Типові джерела: важкі сторонні скрипти (аналітика, віджети чатів, рекламні модулі), неоптимізовані обробники подій, складні анімації на JavaScript.
Як оптимізувати INP
Розбивайте довгі завдання. Якщо скрипт виконується більше 50 мілісекунд, розбийте його на менші частини за допомогою setTimeout, requestIdleCallback або scheduler.yield(). Це дає браузеру «проміжки» для обробки дій користувача.
Оцініть сторонні скрипти. Підключайте їх лише там, де вони дійсно потрібні. Завантажуйте непріоритетні скрипти з затримкою або після взаємодії користувача. Якщо чат-віджет або аналітика блокують основний потік — це прямий кандидат на виправлення.
Використовуйте Web Workers. Обчислення, які не пов’язані з інтерфейсом (обробка даних, парсинг), можна винести у фоновий потік через Web Workers. Це звільняє головний потік для реакції на кліки й скрол.
Зменште обсяг JavaScript. Чим менше коду браузеру потрібно завантажити, скомпілювати та виконати — тим швидше він реагує на взаємодії. Tree-shaking, код-сплітинг і видалення невикористаного коду дають реальний результат.
Що таке CLS і як його виправити
CLS (Cumulative Layout Shift) вимірює візуальну стабільність сторінки. Показник фіксує, наскільки елементи зміщуються несподівано під час завантаження. Наприклад, ви почали читати текст, і раптом зображення з’явилося над вашим рядком — текст стрибнув вниз. Або ви вже навели курсор на кнопку, а банер підсунув її нижче. Це й є layout shift.
Оцінка CLS:
- до 0,1 — добре;
- від 0,1 до 0,25 — потребує покращення;
- понад 0,25 — погано.
Що викликає зсуви
Найчастіші винуватці — зображення та відео без заданих розмірів, динамічно підвантажуваний контент (реклама, віджети), веб-шрифти, які підмінюють системний шрифт із іншими пропорціями, і елементи, позиція яких залежить від контенту, що ще не завантажився.
Як виправити CLS
Задайте явні розміри зображенням і відео. У кожного тега <img> мають бути атрибути width і height, що відповідають реальним пропорціям. Браузер одразу резервує місце на сторінці, і коли зображення завантажиться — нічого не стрибне. Те саме стосується <video>.
Використовуйте CSS-властивість aspect-ratio. Якщо розміри задаються через стилі, aspect-ratio дозволяє резервувати простір без жорсткої прив’язки до пікселів ширини чи висоти.
Резервуйте місце для динамічного контенту. Рекламні блоки, віджети й елементи, які підвантажуються пізніше, повинні мати фіксовану площу в макеті. Якщо блок з’являється над текстом без попереднього резервування місця — це гарантований зсув.
Налаштуйте завантаження шрифтів. Використовуйте font-display: swap, але врахуйте нюанс: саме значення swap може спричинити зсув, якщо системний шрифт і веб-шрифт мають різну висоту рядка чи ширину символів. Щоб цього уникнути, підберіть системний шрифт-запасник з максимально близькими метриками, або використовуйте font-display: optional — тоді браузер застосує веб-шрифт лише якщо він встигне завантажитися до першого відображення тексту.
Уникайте вставки контенту над існуючим. Якщо ви додаєте елементи в DOM поверх уже відображеного контенту (наприклад, спливаючі повідомлення, кнопки «наверх», динамічні заголовки) — розмістіть їх у фіксованій позиції або в місцях, які не зсувають основний контент.
Перевіряти всі три метрики зручно через PageSpeed Insights, панель Core Web Vitals у Google Search Console та розширення Lighthouse у браузері. Головне — не гнатися за ідеальними числами одноразово, а налаштувати регулярний моніторинг, бо будь-яке оновлення сайту може повернути старі проблеми.