Якщо Ви шукали «перевірку Core Web Vitals не пройдено», хоча бал швидкості зелений, спочатку з’ясуйте, які дані описує кожен результат. PageSpeed Insights (PSI) поєднує дані реальних відвідувань з окремим тестом у контрольованих умовах. Перш ніж купувати інструмент або просити переробити сайт, запишіть адресу, пристрій, охоплення даних і метрику, яка не пройшла перевірку.
Ми починаємо із цього запису, адже завдання «зробити бал зеленим» залишає забагато невизначеності. Розробнику потрібно знати, який користувацький досвід потребує уваги та які підтвердження дозволять вважати виправлення корисним.
Перевірку Core Web Vitals не пройдено: що вимірював звіт?
Перевірка описує зафіксований досвід відвідувачів, а розділ Lighthouse запускає діагностичний тест. Документація Google щодо PageSpeed Insights пояснює: польові дані надходять із Chrome User Experience Report, або CrUX, за рухомий період у 28 днів. Тому новий діагностичний запуск і накопичена історія можуть показувати різні результати.
Умови тестування відрізняються. Один контрольований запуск не охоплює всі пристрої, з’єднання та дії реальних відвідувачів. Використовуйте його для дослідження можливої причини, а оцінюючи невирішені проблеми, тримайте поруч дані відвідувань.
Результат може охоплювати більше ніж одну сторінку. Якщо для конкретної сторінки даних мало, PSI може використати дані джерела — origin, тобто адреси сайту з урахуванням протоколу та імені хоста. Такий результат об’єднує відвідування різних сторінок. Перевірте зазначене у звіті охоплення, перш ніж вважати його доказом проблеми конкретної сторінки товару чи послуги.
Період містить і давніші відвідування. Сьогоднішня зміна не переписує вчорашні спостереження. Збережіть дату розгортання, щоб відрізняти негайну перевірку виправлення від подальших даних про відвідувачів.
Ці відмінності визначають різні завдання звітів: дані відвідувань показують, який досвід слід дослідити; контрольований тест допомагає його відтворити й вивчити.
Яка метрика потребує уваги?
Перш ніж обирати виправлення, розгляньте LCP, INP і CLS окремо. Настанови Google щодо Web Vitals розділяють завантаження, швидкість реакції та візуальну стабільність. У таблиці наведено пороги оцінки «Добре» із цих настанов: їх застосовують до 75-го процентиля для відповідної групи пристроїв. Настанови Google щодо порогів пояснюють: щонайменше 75% виміряних переглядів сторінок мають відповідати доброму порогу для цієї метрики. Це не середнє значення й не загальний бал Lighthouse.
| Метрика | Що описує | Поріг «Добре» | Що запитати у фахівця |
|---|---|---|---|
| LCP, Largest Contentful Paint | Коли з’являється найбільший видимий елемент вмісту | Не більше ніж 2,5 секунди | Який елемент затримується та на якому етапі його завантаження? |
| INP, Interaction to Next Paint | Наскільки швидко сторінка реагує на взаємодії | Не більше ніж 200 мілісекунд | Який дотик, клік або натискання клавіші сповільнюється за відповідних умов? |
| CLS, Cumulative Layout Shift | Неочікувані зміщення макета | Не більше ніж 0,1 | Який елемент зміщується та в який момент відвідування? |
Коли даних достатньо за всіма цими метриками, для успішної перевірки PSI вимагає оцінку «Добре» для їхніх значень на 75-му процентилі. Якщо даних INP недостатньо, добрі LCP і CLS усе одно можуть дати успішний результат. Якщо бракує даних LCP або CLS, PSI не може оцінити сторінку чи джерело.
Сприймайте відсутність даних як невизначеність. Методологія Google CrUX вимагає придатних для вимірювання відвідувань і достатньої популярності, але не публікує універсальної мінімальної кількості відвідувачів. Відсутність результату не означає, що ніхто не заходить, що все працює добре або що виправлення не допомогло.
Що перевірити до оплати робіт?
Збережіть початковий звіт і пройдіть той самий клієнтський шлях на телефоні, перш ніж обирати інструмент. Вам потрібен зрозумілий опис проблеми: сторінка, дані, на яких ґрунтується попередження, та поведінка, яку вдається відтворити. Якщо відтворити її не вдається, зафіксуйте це обмеження, не заповнюючи прогалину здогадкою.
- Відкрийте в PSI точну сторінку, важливу для бізнесу. Збережіть її адресу й дату звіту. Укажіть посадкову сторінку або шаблон, що стосується заявки чи покупки, яку Ви досліджуєте.
- Запишіть тип пристрою та охоплення даних. Зазначте, що представляє польовий розділ: URL, джерело чи недостатній обсяг даних. Для подальших порівнянь використовуйте той самий варіант.
- Назвіть метрику, яка потребує уваги. Перегляньте окремі результати Core Web Vitals, потім дослідіть діагностичний розділ у пошуках підказок. Явно позначайте відсутні вибірки.
- Виконайте реальне завдання на телефоні. Відкрийте меню, застосуйте потрібний фільтр або заповніть відповідну форму. Запишіть, що завантажується пізно, повільно реагує чи несподівано зміщується.
- Пов’яжіть спостереження з тестом. Попросіть фахівця відтворити проблемну дію або затримку завантаження та пояснити, що саме може встановити цей тест.
Для ширшої перевірки зображень, віджетів, кешу й хостингу скористайтеся нашим розбором поширених причин повільної роботи сайту. Зосередьте поточне завдання на непройденій перевірці та даних, потрібних для оцінки виправлення.
Що має входити у виправлення?
Оберіть найменшу зміну, яку підтверджує діагностика, та узгодьте спосіб перевірки. Почніть із уже доступних звітів і функцій. Технічну роботу легше оцінити, коли фахівець називає відповідну сторінку чи шаблон, пояснює вузьке місце та зберігає порівнянні умови до й після зміни.
- Пов’яжіть пропозицію з метрикою. Настанови web.dev щодо LCP розділяють затримки відповіді, виявлення, завантаження та відображення найбільшого елемента. Настанови щодо INP зосереджені на повільних взаємодіях. Настанови щодо CLS охоплюють і зміщення після початкового завантаження. Просіть відповідні підтвердження замість загальної обіцянки прискорити сайт.
- Усуньте знайдену причину й повторно перевірте поведінку. Точкове виправлення ресурсу чи шаблону може бути частиною розробки та підтримки сайтів. Запишіть, що й коли змінилося, а за можливості — як це скасувати.
- Переконайтеся, що клієнтське завдання досі можна виконати. Перевірте навігацію, форми та етапи покупки, що стосуються сторінки. Збережіть працездатність елементів керування згодою; досліджуйте їхню поведінку й розташування, зберігаючи законне отримання згоди.
- Визначте, чи потрібні додаткові дані. Якщо доступні звіти не дозволяють знайти проблемну взаємодію чи сторінку, додаткові вимірювання можуть допомогти. Перш ніж додавати платний сервіс, запитайте, на яке питання відповість запропонований моніторинг.
Якщо технічний пріоритет незрозумілий, технічні SEO-роботи можна почати з діагностики та списку завдань, який можна перевірити. Редизайну чи пакету оптимізації потрібне окреме обґрунтування.
Ви можете скопіювати цю картку завдання й залишити невідомі поля порожніми:
Сторінка та бізнес-завдання:
Пристрій і охоплення польових даних:
Метрика, яка потребує уваги:
Спостережувана поведінка та умови тесту:
Ймовірна причина та зміна:
Дата розгортання:
Порівнянна перевірка після зміни:
Подальше польове спостереження та невизначеність, що залишилася:Як перевірити, що робота допомогла?
Спочатку оцініть змінену поведінку, потім порівняйте подальші польові дані в тому самому охопленні. Згідно з документацією PSI, польові дані оновлюються щодня зі збереженням рухомого вікна збору. Зберігайте дату розгортання разом із записом. Це вікно не означає обіцяного відліку до успішної перевірки.
Порівнюйте потрібну метрику та клієнтське завдання за схожих умов тестування. Якщо симптом залишається, поверніться до діагностики. Якщо тест став кращим, але подальші дані відвідувань не підтверджують ефект, знову дослідіть відповідні сторінки та умови відвідувачів. Відсутність польових даних має залишатися явно зазначеним обмеженням.
Як ми долучаємося
Ми починаємо зі звіту, важливих сторінок і завдання, яке можемо відтворити. Окремо розглядаємо запропоноване виправлення, його перевірку та подальші дані відвідувань — так кожне рішення має підставу, яку можна оцінити. Бриф щодо продуктивності сайту можна почати з картки вище; явно позначайте невідомі поля.
