Підрядник надсилає знімок екрана із зеленим колом і числом 94 та пише: «Сайт прискорили». Через місяць у Search Console частина сторінок усе ще має статус «потребує покращення», а менеджери чують від клієнтів, що на телефоні кнопка замовлення «стрибає». Усі три повідомлення можуть бути правдивими одночасно, бо описують різні сторінки, пристрої та джерела даних.
Core Web Vitals — це три показники: LCP, INP і CLS. Кожен треба читати разом із чотирма уточненнями: яка сторінка, який пристрій, звідки дані і за який період. Показники допомагають перевірити, чи швидко відвідувач бачить основний вміст, чи швидко сторінка реагує на натискання і чи не зсуваються елементи під пальцем. Доказом утрачених або отриманих продажів вони самі по собі не є.
Нижче — як прочитати звіт, поставити розробнику завдання і прийняти виправлення.
Що показують LCP, INP і CLS
Google об’єднує під назвою Core Web Vitals три показники, які описують різні частини досвіду відвідувача: завантаження основного вмісту, реакцію на дії та стабільність розташування елементів. В одну «загальну швидкість» вони не складаються: сторінка може швидко показувати вміст і водночас повільно реагувати на натискання.
LCP: коли з’явився найбільший елемент
LCP (Largest Contentful Paint) показує, коли у видимій частині екрана відобразився найбільший елемент із тих, що враховує ця метрика. Відлік іде від початку переходу на сторінку. Враховуються зображення, кадр-заставка відео, фонове зображення, підключене через стилі, і блоки з текстом — наприклад, головне фото товару або банер на першому екрані.
LCP не означає «коли з’явилася ціна» чи «коли стала доступна кнопка». Якщо найбільший елемент — фото, показник описує саме фото.
Приклад проблеми: на мобільній сторінці категорії спершу з’являються меню й фільтри, а великий банер із пропозицією — через кілька секунд. Відвідувач бачить порожнє місце там, де мав бути головний блок.
INP: як швидко сторінка реагує на дію
INP (Interaction to Next Paint) вимірює затримку від дії відвідувача до наступного оновлення екрана, яке показує реакцію. Враховуються натискання мишею, дотики та клавіші; прокручування і наведення курсора — ні. Поки сторінка відкрита, браузер фіксує затримки всіх таких дій, і підсумком стає найдовша. Якщо взаємодій багато, на кожні 50 одна найдовша відкидається, щоб поодинокий збій не визначав результат.
INP закінчується, щойно екран уперше змінився у відповідь на дію. Він не вимірює, скільки сервер обробляв замовлення. Якщо після натискання одразу з’являється індикатор завантаження, а операція триває три секунди, INP може бути добрим, хоча процес для клієнта довгий. Це дві різні проблеми.
Приклад проблеми: відвідувач натискає «Додати в кошик», пів секунди нічого не відбувається, людина натискає вдруге — і в кошику дві одиниці товару.
INP став одним із Core Web Vitals у березні 2024 року й замінив показник FID. Якщо звіт підрядника досі спирається на FID, він складений за застарілим набором.
CLS: чи зсуваються елементи несподівано
CLS (Cumulative Layout Shift) оцінює неочікувані зсуви елементів сторінки. Це безрозмірне число: для кожного зсуву враховується, яку частку екрана зачепив рух і на яку відстань змістилися елементи. Зсуви, близькі в часі, об’єднуються в групи, і показник бере найбільшу групу. Рух протягом пів секунди після натискання відвідувача, наприклад розгортання списку, у CLS не враховується.
Приклад проблеми: на картці товару в телефоні фото завантажується без зарезервованого місця, блок опускається, і палець, який тягнувся до «Купити», потрапляє на «Доставка».
Порогові значення
| Показник | Добре | Потребує покращення | Погано |
|---|---|---|---|
| LCP, секунди | LCP ≤ 2,5 | 2,5 < LCP ≤ 4 | LCP > 4 |
| INP, мілісекунди | INP ≤ 200 | 200 < INP ≤ 500 | INP > 500 |
| CLS, безрозмірне число | CLS ≤ 0,1 | 0,1 < CLS ≤ 0,25 | CLS > 0,25 |
Пороги відповідають опису Web Vitals і PageSpeed Insights. Вони застосовуються до 75-го процентиля завантажень, окремо для мобільних і настільних пристроїв.
Де дивитися показники і які дані ви бачите
Власнику достатньо двох інструментів Google: PageSpeed Insights для окремої сторінки та звіту Core Web Vitals у Search Console для груп сторінок.
PageSpeed Insights: реальні дані і лабораторний тест
У звіті PageSpeed Insights дві частини, які часто змішують.
Верхня частина — дані реальних відвідувань. Вони беруться з CrUX (Chrome User Experience Report): знеособлених вимірювань від користувачів Chrome на комп’ютерах і Android, які погодилися надсилати статистику. Відвідування з iPhone та інших браузерів сюди не потрапляють. Дані охоплюють останні 28 днів і оновлюються щодня як ковзне вікно. Саме тут є INP і підсумок перевірки Core Web Vitals.
Нижня частина — лабораторний тест Lighthouse. Це одне завантаження сторінки на сервері Google з імітацією телефона середнього рівня в мобільній мережі або комп’ютера з дротовим підключенням. Тест допомагає знайти причину і швидко повторити перевірку після змін, але не описує ваших відвідувачів і не має реальних натискань, тому INP у ньому немає.
Результати для мобільних пристроїв і комп’ютерів окремі; починайте з того варіанта, яким користується більшість ваших відвідувачів.
Сторінка чи весь origin
Якщо відвідувань конкретної сторінки в CrUX замало, PageSpeed Insights може показати дані для origin — поєднання протоколу, домену і порту, наприклад https://shop.example.ua. Такі дані об’єднують відвідування всіх сторінок у цих межах. Адреси https://example.ua і https://shop.example.ua — різні origin, так само як варіанти з http і https.
Коли звіт показує origin, це треба назвати прямо: «дані для всього сайту, конкретна сторінка окремо не оцінена». Хороший результат origin не доводить, що саме сторінка оформлення замовлення працює добре.
Якщо реальних даних немає
Порожній блок реальних даних означає, що для цієї сторінки немає доступних польових даних. Причиною може бути недостатня кількість відвідувань або те, що сторінка не відповідає умовам CrUX: наприклад, вона закрита від індексації чи недоступна публічно. Про швидкість така відсутність нічого не говорить. Залишаються лабораторний тест і власні вимірювання, якщо сайт збирає показники з браузерів відвідувачів через систему моніторингу.
Звіт Core Web Vitals у Search Console
Звіт Core Web Vitals використовує ті самі реальні дані, але об’єднує схожі сторінки в групи. Для сайту з сотнями карток товарів це зручніше, ніж перевіряти адреси по одній. Мобільні й настільні дані розділені. Статус групи визначає найгірший із показників: якщо LCP у зоні «добре», а CLS — «погано», група отримає статус «погано». Якщо хоча б для одного з показників LCP чи CLS даних замало, групу не показано, і це теж не оцінка.
Як читати оцінку без хибних висновків
Що означає 75-й процентиль
Уявіть, що всі завантаження сторінки за 28 днів вишикувано від найшвидшого LCP до найповільнішого. 75-й процентиль — значення на позначці трьох чвертей цього ряду. LCP 2,3 с означає: у 75 % завантажень найбільший елемент з’явився за 2,3 с або швидше, у решти — повільніше. Середнє значення могло б приховати повільні завантаження за рахунок швидких.
За описом PageSpeed Insights, сторінка проходить перевірку Core Web Vitals, коли всі три показники на 75-му процентилі в зоні «добре». Один показник поза нею означає, що перевірку не пройдено. Виняток — INP: якщо даних про взаємодії замало, достатньо добрих LCP і CLS, але тоді реакцію сторінки на дії ніхто не оцінив.
Бал Lighthouse — не перевірка Core Web Vitals
Число від 0 до 100 у колі — бал лабораторного тесту; зелений колір означає 90 і більше. Бал розраховується з кількох лабораторних метрик, серед яких є LCP і CLS, але немає INP. Бал 94 означає, що одне тестове завантаження в заданих умовах пройшло добре.
Перевірка Core Web Vitals спирається на реальні відвідування, тому можливі обидва розходження. Лабораторний бал буває високим, коли реальні дані погані — наприклад, коли телефони відвідувачів повільніші за імітований або на сторінці спрацьовують скрипти, які в тесті не проявилися. Буває і навпаки. Причину в кожному випадку перевіряють окремо.
У лабораторному звіті є TBT (Total Blocking Time) — показник блокування головного потоку браузера довгими завданнями: для кожного завдання, довшого за 50 мс, враховується час понад ці 50 мс. TBT допомагає шукати причини поганого INP, але це інший показник, і підписувати його як INP не можна.
Умовний приклад: один звіт, два висновки
Умовний приклад. Дані вигадані для пояснення.
| Що у звіті | Значення | Правильне прочитання |
|---|---|---|
| Бал лабораторного тесту, мобільний | 94 | Тестове завантаження пройшло добре |
| LCP реальних відвідувань, мобільні, 75-й процентиль | 3,6 с | Зона «потребує покращення» |
| INP реальних відвідувань, мобільні | 180 мс | Зона «добре» |
| CLS реальних відвідувань, мобільні | 0,05 | Зона «добре» |
| Джерело реальних даних | Origin | Оцінено весь сайт, а не сторінку |
Мобільна перевірка Core Web Vitals не пройдена через LCP, і ця оцінка стосується всього origin. Повідомлення «бал 94» цього не спростовує. Наступний крок — з’ясувати, які типи сторінок дають повільний LCP.
Типові помилки: порівнювати лабораторний результат «до» з реальними даними «після»; оцінювати мобільну версію за результатом для комп’ютера; сприймати дані origin як дані сторінки; робити висновок про продажі за зміною одного показника.
Які сторінки перевіряти першими
Головна сторінка — не завжди найважливіша. Відвідувачі з пошуку й реклами часто потрапляють одразу в категорію, на картку товару чи сторінку послуги, а звернення надходять через форму або кошик. Порядок перевірки редакція радить складати за чотирма ознаками:
- Роль у сценарії: сторінки на шляху до звернення чи замовлення — сторінки входу, категорії, картки, послуги, кошик, форма.
- Шаблон: проблема шаблону повторюється на багатьох сторінках, і виправлення може подіяти на всі; групи у Search Console допомагають це побачити.
- Спостережувана проблема: реальні дані поза зоною «добре», скарги клієнтів, запис сеансу відвідувача, де видно зсув чи затримку.
- Частка відвідувань за даними вашої аналітики.
Першими беруть сторінки з важливою роллю і спостережуваною проблемою; шаблон і частка відвідувань допомагають вибрати між ними. Ці ознаки впорядковують роботу, але не оцінюють, скільки грошей принесе кожне виправлення.
Як перетворити звіт на завдання розробнику
Червоний показник — симптом, а не причина. Повільний LCP може давати повільна відповідь сервера, важке зображення, пізнє завантаження головного фото, стилі, що затримують відображення, або побудова сторінки скриптами. Поганий INP — сторонній віджет, чат, лічильник або власний код сайту. Діагноз ставить розробник після перевірки.
Тому завдання формулюється так, щоб розробник міг відтворити проблему, а ви — прийняти результат:
| Поле завдання | Що вписати |
|---|---|
| Симптом для відвідувача | Що відбувається зі сторінкою з погляду людини |
| Сторінка або шаблон | Адреса прикладу і тип сторінки |
| Умови та джерело | Пристрій, джерело даних, дата, значення показника |
| Припущена причина | Позначена як гіпотеза |
| Як підтвердити причину | Яку перевірку виконати перед зміною |
| Відповідальний | Хто виконує і хто приймає |
| Критерій приймання | За якою ознакою завдання виконане |
Умовний приклад. Заповнене завдання:
Симптом: на мобільній картці товару після завантаження фото кнопка «Купити» опускається; користувач може натиснути не туди.
Шаблон: картка товару, приклад —
/catalog/boiler-24/.Умови та джерело: мобільні; група карток у звіті Core Web Vitals Search Console має статус «потребує покращення» за CLS; дані на дату постановки завдання.
Припущена причина: для головного фото не задано розміри або співвідношення сторін.
Як підтвердити: відтворити завантаження на імітації телефона з повільною мережею і зафіксувати зсуви в інструментах розробника.
Відповідальний: розробник виконує; SEO-фахівець перевіряє показники; менеджер проєкту приймає.
Критерій приймання: на трьох прикладах карток кнопка не зсувається після завантаження фото; сценарій «варіант → кошик» працює; зміни опубліковано, дату зафіксовано.
Якщо перевірка показує іншу причину, розробник описує знайдену причину і що саме змінено. Коли виправлення стосується коду шаблону, серверних налаштувань чи сторонніх скриптів, до роботи залучається розробка.
Як прийняти виправлення
Приймання складається з двох окремих частин. Технічне виправлення можна прийняти одразу після перевірки. Реальні дані перевіряються пізніше окремим завданням, бо їхнє 28-денне вікно лише поступово заповнюється відвідуваннями після змін.
Технічне приймання — одразу після публікації змін:
- лабораторна перевірка в тих самих умовах: та сама адреса, мобільний режим, кілька запусків, бо результат коливається; редакція радить порівнювати типове значення, а не один найкращий запуск, і перевіряти кілька сторінок шаблону;
- сценарій: пошук і фільтри, вибір варіанта, кошик, форма, оплата, надходження звернень у CRM, події аналітики;
- відсутність регресій: виправлення одного показника не погіршило два інші й не зламало інші шаблони.
Контроль реальних даних — окреме завдання з датою і відповідальним. Нове 28-денне вікно повністю складеться з відвідувань після змін приблизно через 28 днів після публікації; у Search Console для групи можна запустити перевірку виправлення, яка теж спостерігає 28 днів. Якщо показники покращилися, а в журналі змін немає інших правок, які могли на них вплинути, це узгоджується з виправленням. Якщо ні — перевіряють, чи зміни дійшли до всіх сторінок групи. Чи змінилася вартість звернень, звіт про швидкість не показує: для цього потрібна окрема перевірка з даними про витрати і звернення.
Результат фіксується в картці приймання. Її заповнює виконавець, а власник чи менеджер перевіряє, чи немає порожніх полів.
Картка приймання технічних змін
Умовний приклад. Картку заповнено для пояснення, це не результат реального проєкту.
| Поле картки | Значення |
|---|---|
| Сторінка або шаблон | Картка товару, мобільна версія |
| Проблема відвідувача | Після завантаження фото кнопка «Купити» зсувається, людина може натиснути не туди |
| Показник | CLS |
| Джерело й умови | Search Console, група карток товару, мобільні, статус «потребує покращення» на дату постановки завдання; лабораторна перевірка трьох карток |
| Що змінено | Для головного фото задано співвідношення сторін, місце резервується до завантаження |
| Результат перевірки | Технічно прийнято: на трьох картках зсуву кнопки немає, сценарій «варіант → кошик → оформлення» працює, події кошика надходять. Не визначено: зміна CLS у реальних даних |
| Наступний крок | Контроль статусу групи в Search Console через 28 днів після публікації; відповідальний — SEO-фахівець |
Перед підписанням акта поставте підряднику чотири запитання, на які картка відповідає лише частково:
- Як саме підтвердили причину проблеми?
- На скількох сторінках шаблону і на яких пристроях перевіряли результат?
- Звідки цифри: реальні дані сторінки, дані origin чи лабораторний тест, і якої дати?
- Що залишилося невиправленим або невизначеним і чому?
Наступні кроки
- Власник або керівник маркетингу обирає кілька сторінок чи шаблонів за ознаками вище.
- SEO-фахівець фіксує для них реальні та лабораторні дані з датою і позначає, де показано origin або де реальних даних немає.
- Розробник за завданням підтверджує причину, вносить зміни і заповнює картку приймання.
- Менеджер проєкту приймає технічне виправлення і ставить окреме завдання на контроль реальних даних із датою та відповідальним.
Робота завершена, коли технічне виправлення прийнято за карткою, а контроль реальних даних призначено. Результат контролю записується в картку, коли контроль завершиться, яким би він не був.
Обговорімо, які сторінки потребують перевірки та як приймати виправлення.
