Шаблон аудиту Core Web Vitals і швидкості сторінки

Проаналізуйте та виправте Core Web Vitals (LCP, INP, CLS) і загальну швидкість сторінки, використовуючи польові та лабораторні дані, щоб досягти хороших порогів Google.

Core Web Vitals — це метрики користувацького досвіду, за якими Google оцінює реальне завантаження, інтерактивність і візуальну стабільність: LCP (<=2.5 с), INP (<=200 мс) і CLS (<=0.1). Цей шаблон проведе вас через вимірювання кожної метрики за допомогою польових і лабораторних даних, діагностику першопричини, застосування перевірених виправлень і повторне тестування, щоб підтвердити, що покращення закріпилися. Опрацюйте варіанти по порядку або одразу перейдіть до метрики, яка не проходить для ваших URL-адрес.

6 готових варіантів

Базові показники та польові дані проти лабораторних

Зафіксуйте відправну точку для кожного Core Web Vital, перш ніж щось змінювати, і зрозумійте, якому джерелу даних довіряти для оцінки, а якому — для налагодження.

Зафіксуйте базовий рівень

Перш ніж щось оптимізувати, зафіксуйте, де сьогодні перебуває кожна метрика для [URL сторінки]. Google ранжує за польовими даними (реальні користувачі Chrome, набір даних CrUX, ковзне 28-денне вікно), тож саме це число має значення для пошуку. Лабораторні дані (Lighthouse, одне змодельоване завантаження) призначені для налагодження, бо вони відтворювані й дають корисні трейси.

  • Джерело польових даних: отримайте дані CrUX із PageSpeed Insights або зі звіту Core Web Vitals у Search Console для [Ресурс].
  • Джерело лабораторних даних: запустіть Lighthouse (Chrome DevTools або PageSpeed Insights), щоб відтворити й простежити проблеми.
  • Запишіть пороги: LCP добре <=2.5 с, INP добре <=200 мс, CLS добре <=0.1; занотуйте своє поточне значення та статус проходження за "75-м перцентилем" для кожної.

Польові та лабораторні дані розходитимуться, і це очікувано. Лабораторне завантаження відбувається на одному пристрої й одній мережі; польові дані агрегують багато. Використовуйте лабораторні дані, щоб знайти причину, а польові — щоб підтвердити результат лікування.

Результат: базова таблиця з кожною метрикою, її поточним польовим значенням, лабораторним значенням і статусом проходження на [Дата].

Виправлення Largest Contentful Paint (LCP)

Діагностуйте та виправте повільний LCP, щоб основний елемент контенту відображався протягом 2.5 секунди для більшості відвідувачів.

Зробіть так, щоб основний контент з'являвся швидко

LCP вимірює, коли найбільший видимий елемент (зазвичай головне зображення, постер відео або блок заголовка) завершує рендеринг. Ціль — <=2.5s на 75-му перцентилі. Визначте LCP-елемент у Lighthouse, а потім попрацюйте над чотирма фазами, які його затримують.

  1. Час до першого байта: скоротьте відповідь сервера для [Джерело] за допомогою кешування, швидшого хостингу або рендерингу на межі мережі.
  2. Ресурси, що блокують рендеринг: відкладіть некритичні CSS і JavaScript, щоб браузер міг відмалювати сторінку раніше.
  3. Затримка завантаження ресурсу: додайте preload для LCP-зображення й встановіть на ньому [fetchpriority=high], щоб браузер завантажував його раніше.
  4. Затримка рендерингу ресурсу: переконайтеся, що LCP-зображення не завантажується ліниво й подається в сучасному форматі та правильному розмірі.

Уникайте завантаження головного зображення через CSS-фон або клієнтський JavaScript, бо браузер виявляє його надто пізно. Пряме посилання на попередньо завантажене зображення правильного розміру майже завжди виграє.

Перевірте: повторно запустіть Lighthouse і підтвердьте, що LCP-елемент і його часова шкала завантаження для [URL сторінки] опустилися нижче 2.5 с.

Виправлення Interaction to Next Paint (INP)

Підвищіть чутливість, щоб сторінка швидко реагувала на кліки, торкання та натискання клавіш, замінивши старішу метрику FID.

Зробіть взаємодію миттєвою

INP замінив FID як Core Web Vital у березні 2024 року. Він вимірює затримку взаємодій упродовж усього візиту на сторінку, повідомляючи приблизно про найгіршу з них. Ціль — <=200ms. Поганий INP майже завжди спричинений JavaScript, який займає головний потік у момент дії користувача.

  • Знайдіть довгі завдання: скористайтеся панеллю Performance у DevTools, щоб виявити завдання головного потоку тривалістю понад 50 мс під час взаємодії на [URL сторінки].
  • Розбийте JavaScript: розділіть довгі завдання на менші частини й поступайтеся головним потоком, щоб ввід можна було обробити.
  • Зменшіть роботу головного потоку: видаліть або відкладіть невикористовувані скрипти, особливо важкі сторонні теги, як-от [Назва тегу].
  • Оптимізуйте обробники подій: застосовуйте debounce для витратних операцій і відкладайте несрочні оновлення до наступного відмалювання.
  • Мінімізуйте розмір і вартість макета DOM: великий або глибоко вкладений DOM робить кожну взаємодію витратнішою.

Мета — тримати головний потік вільним, коли користувачі клікають і торкаються, щоб браузер міг відмалювати відповідь у межах бюджету 200 мс.

Перевірте: протестуйте реальні взаємодії й підтвердьте, що польовий INP рухається до хорошого для [Ресурс].

Виправлення Cumulative Layout Shift (CLS)

Зупиніть стрибки контенту під час завантаження, щоб макет залишався візуально стабільним нижче CLS 0.1.

Зупиніть стрибки макета

CLS вимірює неочікувані зсуви макета видимого контенту протягом життя сторінки. Ціль — <=0.1. Зсуви дратують користувачів і спричиняють помилкові кліки, і майже завжди вони походять від елементів, що завантажуються без зарезервованого місця.

  • Задавайте розміри медіа: завжди встановлюйте атрибути width і height (або CSS aspect-ratio) для зображень, відео та iframe, щоб браузер резервував місце до їх завантаження.
  • Резервуйте місце для вбудувань і реклами: надайте слотам для [Реклама або вбудований елемент] контейнер із фіксованою min-height, щоб вони не зсували контент донизу.
  • Ніколи не вставляйте контент над наявним: уникайте впровадження банерів, повідомлень чи cookie-панелей, які штовхають сторінку вниз після рендерингу.
  • Запобігайте зсувам через підміну шрифтів: попередньо завантажуйте ключові шрифти й розумно використовуйте [font-display], щоб обмежити перекомпонування.
  • Резервуйте місце для динамічного інтерфейсу: тримайте місце для елементів, доданих через JavaScript, щоб вони розгорталися в заздалегідь виділений простір.

Ставтеся до будь-якого "стрибка", який ви бачите під час завантаження, як до дефекту, що потрібно усунути.

Перевірте: перегляньте кінострічку завантаження й підтвердьте відсутність видимих зсувів на [URL сторінки].

Оптимізація ресурсів і доставлення

Скоротьте та пришвидшіть ресурси, які надсилає сторінка — зображення, JavaScript, CSS, кешування і CDN — щоб підняти всі метрики одразу.

Надсилайте менше, доставляйте швидше

Більшість проблем зі швидкістю сторінки зводиться до надсилання забагато байтів або надто повільного їх надсилання. Оптимізація доставлення покращує LCP, INP і CLS разом, бо браузеру потрібно менше завантажувати, розбирати й виконувати.

  • Зображення: подавайте сучасні формати (наприклад, WebP або AVIF), масштабуйте їх до відображуваних розмірів і стискайте; застосовуйте ліниве завантаження лише до зображень поза видимою частиною, ніколи — до LCP-зображення.
  • JavaScript: мініфікуйте, застосовуйте tree-shaking і code-splitting, щоб кожна сторінка завантажувала лише необхідне; відкладайте або робіть async некритичні скрипти.
  • CSS: мініфікуйте, видаляйте невикористовувані правила й вбудовуйте критичний CSS для контенту у видимій частині на [Шаблон].
  • Кешування: встановлюйте довгий час життя кешу для статичних ресурсів і використовуйте імена файлів із відбитком (fingerprint), щоб оновлення безпечно скидали кеш.
  • CDN: подавайте ресурси з граничних вузлів поблизу користувачів і вмикайте стиснення (Brotli або gzip) у [Постачальник CDN].

Безжально перевіряйте сторонні скрипти, бо вони — поширена прихована причина повільних завантажень і поганої чутливості.

Перевірте: порівняйте загальний обсяг переданих даних і кількість запитів до й після для [URL сторінки].

Повторне тестування та моніторинг

Підтвердьте, що виправлення спрацювали в польових даних, і налаштуйте постійний моніторинг, щоб регресії виявлялися рано.

Підтвердьте перемогу й утримайте її

Виправлення не завершене, поки польові дані його не підтвердять. Оскільки CrUX використовує ковзне 28-денне вікно, покращення для реальних користувачів з'являються не одразу, тож перевіряйте у два етапи: спершу лабораторно для миттєвого зворотного зв'язку, потім польово протягом наступних тижнів.

  1. Повторіть лабораторні тести: скористайтеся Lighthouse або PageSpeed Insights, щоб підтвердити, що проблему рівня трейсу на [URL сторінки] усунено.
  2. Спостерігайте за польовими даними: відстежуйте CrUX у звіті Core Web Vitals у Search Console й зачекайте, поки 28-денне вікно оновиться, перш ніж оголошувати успіх.
  3. Задайте цілі: тримайте кожну групу URL на рівні LCP <=2.5s, INP <=200ms, CLS <=0.1 на 75-му перцентилі.
  4. Моніторте безперервно: додайте моніторинг реальних користувачів (RUM) або заплановані аудити для [Ресурс], щоб регресії виявлялися швидко.
  5. Захищайтеся від дрейфу: проводьте повторний аудит після великих релізів, нових сторонніх тегів або змін шаблону.

Продуктивність — це не разовий проєкт; ставтеся до неї як до постійного бюджету, який ви захищаєте з кожним деплоєм.

Результат: звіт «до/після» й занотована періодичність моніторингу на [Дата].

Як використовувати цей шаблон

  1. Запустіть PageSpeed Insights для ключових URL-адрес і запишіть значення як польових даних (CrUX), так і лабораторних (Lighthouse) для LCP, INP і CLS.
  2. Порівняйте кожну метрику з хорошими порогами Google: LCP <=2.5 с, INP <=200 мс, CLS <=0.1 на 75-му перцентилі, і позначте кожну метрику, що не проходить.
  3. Для LCP, що не проходить, визначте LCP-елемент, потім зробіть його preload, задайте високий пріоритет завантаження, приберіть ліниве завантаження й скоротіть ресурси, що блокують рендеринг, та час відповіді сервера.
  4. Для INP, що не проходить, відкрийте панель Performance у DevTools під час взаємодії, знайдіть довгі завдання головного потоку понад 50 мс і розбийте або відкладіть JavaScript, що їх спричиняє.
  5. Для CLS, що не проходить, додайте width і height (або aspect-ratio) до всіх зображень і вбудувань, зарезервуйте місце для реклами й динамічного контенту та припиніть вставляти контент над наявним.
  6. Оптимізуйте доставлення ресурсів: подавайте сучасні формати зображень, мініфікуйте й розділяйте JS і CSS, вмикайте стиснення й CDN та задавайте довгий час життя кешу.
  7. Повторно запустіть Lighthouse, щоб підтвердити виправлення кожної проблеми лабораторного рівня, потім моніторте польові дані CrUX у Search Console, зважаючи на оновлення ковзного 28-денного вікна.
  8. Налаштуйте постійний моніторинг за допомогою RUM або запланованих аудитів і проводьте повторне тестування після кожного великого релізу, щоб виявляти регресії до того, як вони дійдуть до користувачів.

Поради

  • Довіряйте польовим даним (CrUX) щодо того, чи ви проходите, і лабораторним (Lighthouse) — щоб діагностувати чому; очікуйте, що ці два числа відрізнятимуться.
  • Ніколи не завантажуйте ліниво своє LCP-зображення й ніколи не завантажуйте його через CSS-фон чи JavaScript, бо браузер виявляє його надто пізно.
  • Проблеми з INP майже завжди — це JavaScript у головному потоці; аудит і відкладення важких сторонніх тегів часто дають найбільший виграш.
  • Усувайте будь-який видимий стрибок під час завантаження, резервуючи місце заздалегідь; якщо ви бачите, як контент рухається, ваш CLS постраждає.

Поширені запитання

Які три Core Web Vitals і їхні хороші пороги?

Largest Contentful Paint (LCP) має бути 2.5 секунди або менше, Interaction to Next Paint (INP) — 200 мілісекунд або менше, а Cumulative Layout Shift (CLS) — 0.1 або менше. Кожен поріг має досягатися на 75-му перцентилі візитів реальних користувачів, щоб вважатися хорошим.

Що сталося з First Input Delay (FID)?

INP замінив FID як Core Web Vital у березні 2024 року. FID вимірював лише затримку до обробки першої взаємодії, тоді як INP вимірює повну затримку взаємодій упродовж усього візиту на сторінку, даючи повнішу картину чутливості.

У чому різниця між польовими та лабораторними даними?

Польові дані надходять від реальних користувачів Chrome у наборі даних CrUX за ковзне 28-денне вікно, і саме їх Google використовує для ранжування. Лабораторні дані надходять від одного змодельованого завантаження в інструменті на кшталт Lighthouse; вони відтворювані й ідеальні для налагодження, але не відображають того, що відчувають реальні користувачі.

Чому мій показник Lighthouse відрізняється від польового показника CrUX?

Lighthouse виконує одне завантаження на конкретному змодельованому пристрої й мережі, тоді як CrUX агрегує багато реальних користувачів на різних пристроях, з'єднаннях і станах кешу. Розбіжність — це нормально. Використовуйте лабораторні дані, щоб знайти й усунути причину, а польові — щоб підтвердити, що виправлення спрацювало для реальних користувачів.

Чому мої Core Web Vitals не покращилися одразу після деплою виправлення?

Польові дані оновлюються повільно, бо CrUX використовує ковзне 28-денне вікно, тож покращення проявляються повністю за тижні. Підтвердьте виправлення в лабораторних інструментах на кшталт Lighthouse для миттєвого зворотного зв'язку, потім спостерігайте за польовим звітом у Search Console, поки вікно поступово оновлюється даними після виправлення.

Яка найпоширеніша причина поганого INP?

Довгі завдання JavaScript, що блокують головний потік, коли користувач взаємодіє. Коли головний потік зайнятий, браузер не може обробити ввід і відмалювати відповідь у межах бюджету 200 мс. Розбиття довгих завдань, відкладення некритичних і сторонніх скриптів та поступання головним потоком — найефективніші виправлення.