Core Web Vitals assessment: Failed - як читати звіт Search Console і що лагодити першим (2026)

Звіт Core Web Vitals - одне з небагатьох місць, де Google прямо каже про сайт «пройшов» або «не пройшов», і саме тому червоне Failed викликає більше паніки та більше безглуздої роботи, ніж майже будь-яке інше повідомлення в Search Console. Звіт не є оцінкою швидкості й не є думкою про ваш код. Це агрегат того, що реальні користувачі Chrome відчули на ваших сторінках за останні 28 днів, стиснутий до трьох порогів. Прочитати його правильно - приблизно десять хвилин роботи, і це рятує від значно частішого результату: команда шість тижнів тисне картинки, тоді як провалилася метрика затримки відгуку. За даними HTTP Archive 2025 Web Almanac, 43% мобільних джерел досі не проходять INP, і INP - єдина метрика, якої лабораторний тест не показує взагалі. Тут розібрано, що саме оцінюється, як визначити провалену метрику та шаблон сторінок за нею, чому статус відстає від виправлення на тижні, у що провал обходиться в позиціях і у виручці, і де проходить межа між лагодженням силами вашої команди та інженерним завданням.

Що насправді означає «Core Web Vitals assessment: Failed»?

Оцінка - це вердикт щодо групи URL, побудований на Chrome User Experience Report (CrUX). CrUX збирає вимірювання з реальних користувачів Chrome, які погодилися передавати статистику, на реальних пристроях і реальних мережах. Search Console бере 28 днів цих даних, групує URL за структурною схожістю (на практиці - за шаблоном сторінки) і рахує 75-й перцентиль кожної метрики для кожної групи. Група проходить, лише якщо всі три метрики потрапляють у зону «Good» на цьому перцентилі. Одна метрика поза зоною обвалює всю групу, а мобільні та десктоп оцінюються як незалежні набори даних, тому сайт може проходити на десктопі й провалюватися на мобільних за однакового коду. Слово Failed несе вузький і точний зміст: щонайменше одне з трьох конкретних чисел, виміряних не менш ніж на чверті реальних візитів, опинилося за порогом, який Google опублікував заздалегідь.

• LCP (Largest Contentful Paint): Good ≤ 2.5с, потребує покращення 2.5–4.0с, погано > 4.0с. Показує, коли домалювався найбільший видимий елемент в області перегляду. Це найближча технічна відповідність відчуттю «сторінка завантажилася».
• INP (Interaction to Next Paint): Good ≤ 200мс, потребує покращення 201–500мс, погано > 500мс. Вимірює затримку взаємодій протягом усієї сесії, звіт іде приблизно за 98-м перцентилем взаємодій одного користувача. Замінила FID у складі Core Web Vitals 12 березня 2024 року.
• CLS (Cumulative Layout Shift): Good ≤ 0.1, потребує покращення 0.1–0.25, погано > 0.25. Вимірює несподівані зміщення видимого контенту за час життя сторінки, рахується як безрозмірний добуток частки впливу та частки відстані.
• Правило 75-го перцентиля: Метрика вважається доброю для групи URL, лише якщо щонайменше 75% придатних візитів дали добре значення. Оптимізація під власний пристрій на власному каналі нічого не каже про ті 25% хвоста, які й вирішують результат.
• Окремі вердикти за пристроями: Провали концентруються на мобільних, бо вибірка CrUX складається переважно із середньобюджетного Android, а не з ноутбука, на якому сайт тестували.

Чому PageSpeed Insights показує 95, а Search Console пише Failed?

Тому що PageSpeed Insights розміщує два непов'язані вимірювання на одному екрані, а більшість читає лише кольорове коло. Верхній блок, коли він є, - польові дані CrUX: той самий 28-денний розподіл реальних користувачів, який оцінює Search Console. Великий бал під ним - Lighthouse, один синтетичний прогін на емульованому середньому пристрої з придушеними процесором і мережею, виконаний просто зараз, без жодної живої людини на сторінці. Ці два числа розходяться регулярно, і обидва при цьому правильні. Головний структурний розрив - INP: у лабораторному прогоні немає реальних взаємодій, які можна заміряти, тому Lighthouse не видає значення INP взагалі й підставляє Total Blocking Time як грубий замінник. Сторінка може набрати 100 у лабораторії й мати 600мс INP у полі, і лабораторний бал не попередить про це ніяк. Одне правило знімає майже всю плутанину: польові дані визначають вашу оцінку, лабораторні потрібні лише для налагодження.

• Лабораторні дані (бал Lighthouse): Один прогін, емульований середній пристрій, штучне обмеження мережі, нуль взаємодій, нуль розширень, нуль розкиду за холодним кешем. Корисно для відтворення проблеми та для регресійних перевірок у CI. Ніколи не є підставою оцінки.
• Польові дані (CrUX): 28 днів реальних сесій на фактичному розподілі пристроїв, мереж, географій і браузерних розширень ваших відвідувачів. Саме це оцінює Search Console і саме це споживають ранжувальні системи Google.
• INP існує лише в полі: Lighthouse замість неї показує Total Blocking Time. TBT корелює з INP, але вимірюється під час завантаження, тоді як INP вимірюється по всій сесії, включно з кліками по фільтрах і тапами по меню, які стаються значно пізніше за завантаження.
• URL проти домену: PageSpeed Insights відкочується до польових даних рівня домену, коли в конкретного URL замало вибірки. Ви можете дивитися на головну, а число на екрані буде середнім по всіх сторінках домену.
• Практична перевірка: Якщо лабораторний бал зелений, а оцінка червона, відкрийте блок польових даних і прочитайте три смуги. У більшості випадків винна INP або CLS, і жодної з них не видно у великому числі згори.

Яка з трьох метрик провалилася і як це перевірити?

Search Console відповідає на це прямо, але відповідь лежить у рядках проблем, а не в графіку згори. Відкрийте Core Web Vitals, оберіть «Мобільні» або «Комп'ютери» і прочитайте перелік проблем під графіком. Кожен рядок сформульовано як метрика, поріг і пристрій, наприклад «Проблема з LCP: понад 2,5 с (мобільні)», і кожен несе лічильник уражених URL. Клік по рядку розкриває приклади URL, і саме приклади найцінніші, бо показують, який шаблон сторінок провалюється. Провали групуються за шаблонами, а не розсипаються випадково, тому один макет лістингу товарів або один макет статті зазвичай пояснює всю групу цілком. Підтвердьте діагноз на одному показовому URL у PageSpeed Insights, читаючи блок польових даних, а не бал, і якщо вибірка виглядає тонкою, CrUX API поверне повну гістограму для будь-якого URL або домену.

• Починайте з рядків проблем, а не з графіка: Графік показує, скільки URL потрапило в кожну зону. Рядки називають метрику й поріг, які дали вердикт.
• Використовуйте приклади URL як карту шаблонів: Згрупуйте їх за патерном адреси. Якщо всі провалені приклади лежать у /collections/* або /blog/*, у вас один макет для лагодження, а не сотні сторінок.
• Перевіряйте за URL у PageSpeed Insights: Читайте блок «Дізнайтеся, як ваш сайт працює в реальних користувачів». Бал під ним - окреме вимірювання, і він не підтверджує й не спростовує оцінку.
• Тягніть сиру гістограму, коли вибірка тонка: https://chromeuxreport.googleapis.com/v1/records:queryRecord приймає URL або домен і повертає повний розподіл, включно з тим самим значенням p75, яке використав Search Console.
• Знімайте метрики зі своїх сесій: Офіційна бібліотека web-vitals реалізує ті самі алгоритми, що й CrUX. Надсилання onLCP, onINP і onCLS у вашу аналітику дає атрибуцію, якої в CrUX немає: який елемент, який маршрут, яка взаємодія.

Якщо потрібні три польові значення, лабораторні метрики та проблеми сторінки за ними за один прохід, безкоштовний аудит сайту проганяє ці перевірки будь-яким URL і повертає їх разом, включно з перевіркою того, чи є у вашого домену польові дані в CrUX взагалі.

Чому звіт досі показує Failed через тижні після лагодження?

Тому що оцінка рахується за ковзним вікном у 28 днів, а деплой не змінює заднім числом сесії, які вже всередині цього вікна. У день викатки виправлення вікно все ще містить 28 днів візитів до лагодження. Кожен наступний день викидає один день старих даних і додає один день нових, тому 75-й перцентиль поліпшується поступово й доходить до істинного значення приблизно через чотири тижні. Search Console згори додає власну затримку обробки в кілька днів. Це відставання - найдорожче непорозуміння в усьому звіті, бо природне прочитання незміненого червоного статусу звучить як «лагодження не спрацювало», і команда йде міняти ще код, остаточно втрачаючи можливість щось атрибутувати. Правильна реакція на червоний статус через два тижні після деплою - перевірити виправлення на свіжих даних, а не лагодити заново.

• Розраховуйте приблизно на чотири тижні до повного ефекту: Часткове зрушення видно вже за кілька днів у міру вимивання старих сесій, але підсумковому числу не можна довіряти, доки вікно не зміниться повністю.
• Search Console відстає від CrUX: Звіт відображає дані, яким уже кілька днів. Перевірка того самого тижня не каже взагалі ні про що.
• Кнопку «Перевірити виправлення» використовуйте свідомо: Вона запускає спостережувану 28-денну переоцінку уражених URL. Нічого не пришвидшує, але створює датовану позначку про те, коли ви заявили лагодження, що важливо, якщо робота розтягнулася на кілька деплоїв.
• Дивіться тим часом на власний RUM: Польові заміри через web-vitals показують ефект деплою за години, на вашому трафіку, без 28-денного згладжування. Це єдиний швидкий зворотний зв'язок, який існує.
• Не навалюйте виправлення наосліп: Три нові зміни під час вікна валідації унеможливлюють розуміння, яка з них зрушила число, а яка спричинила регрес.

Чи справді провалена оцінка Core Web Vitals б'є по позиціях у Google?

Слабше, ніж має на увазі більшість статей на цю тему, і тут варто бути точним, бо перебільшення веде до поганих бюджетних рішень. Page experience, вимірюваною частиною якого є Core Web Vitals, - справжній вхід ранжувальних систем Google, але працює він як розрізнювач між результатами співставної релевантності, а не як первинний фактор. Швидка сторінка з порожнім змістом не обійде повільнішу, яка нормально відповідає на запит. Якщо ваші сторінки не ранжуються, Core Web Vitals рідко є причиною, і робота над швидкістю не полагодить проблему контенту чи авторитетності. Де провал стабільно коштує грошей, так це після кліку: повільні та стрибучі сторінки втрачають користувачів на кожному кроці воронки, і ця втрата абсолютно не залежить від вашої позиції. Чесне формулювання таке: Core Web Vitals - питання конверсії та утримання, до якого додається скромний бонус у ранжуванні, і фінансувати цю роботу треба за першою підставою, а не за другою.

• Розрізнювач, а не важіль: Власні рекомендації Google позиціюють page experience як корисний тоді, коли решта сигналів співставні. Вважайте приріст позицій можливим побічним ефектом, а не бізнес-обґрунтуванням.
• Аргумент виручки сильніший за аргумент позицій: Відмови зростають із часом завантаження та з нестабільністю незалежно від місця у видачі. Ефект поширюється й на платний, і на поштовий, і на прямий трафік, яким ваша позиція байдужа.
• Провали концентруються там, де намір найвищий: Проблеми INP зазвичай спливають на фільтрах, пошуку по сайту, виборі варіантів товару та діях із кошиком, тобто рівно там, де відвідувач уже вирішив купити.
• Спершу діагноз, потім бюджет: Якщо органіка стоїть на місці та позиції погані, аудитуйте спершу контент, перелінковку та індексацію. Робота над Core Web Vitals на сайті без релевантного контенту - дороге оздоблення.
• За темою: Про сигнали ранжування, які зазвичай важать більше, є посібник із JSON-LD, а повна картина щодо швидкості - у посібнику з веб-продуктивності.

Що робити, якщо Search Console взагалі не показує дані Core Web Vitals?

Це проблема розміру вибірки, а не покарання, і для великої частки сайтів це нормальний стан. CrUX починає звітувати за URL або доменом лише після того, як зібрав достатньо придатних візитів від користувачів Chrome, які погодилися, щоб побудувати статистично значущий розподіл і не розкрити поведінку окремої людини. Невеликі сайти часто бачать відсутність даних на рівні URL, лише дані рівня домену або дані, які з'являються та зникають разом із коливаннями трафіку. Ні на що в ранжуванні це не впливає, і жодна оптимізація не змусить дані з'явитися швидше, бо обмеження тут в обсязі трафіку, а не в якості сторінок. Практичний наслідок: Search Console не може бути вашим зворотним зв'язком, тому його доведеться побудувати самостійно.

• Спершу подивіться, що взагалі є: Запитайте CrUX API і за URL, і за доменом. Дані рівня домену часто існують там, де даних за URL немає, і вони лишаються законним сигналом про ваші шаблони.
• Знімайте метрики з реальних користувачів самі: npm install web-vitals, потім надсилайте onLCP, onINP і onCLS в аналітику. Навіть кілька сотень сесій на тиждень дають придатний 75-й перцентиль задовго до того, як це зробив би CrUX.
• Користуйтеся лабораторними даними чесно: Lighthouse на придушеному середньому профілі - розумний замінник для LCP і CLS. Для INP він замінником не є, тому реальні взаємодії перевіряйте руками на справжньому середньобюджетному Android.
• Не женіться за зеленим лабораторним балом: Без польових даних лабораторне число - єдиний доступний зворотний зв'язок, і тому виникає спокуса оптимізувати прямо під нього. Цей шлях закінчується ідеальним балом і сайтом, який у руках усе одно відчувається повільним.

Які провали можна полагодити власними силами, а де потрібен інженер?

Межа проходить по тому, чи змінює виправлення налаштування та файл, чи змінює спосіб побудови сторінки. Більшість провалів CLS і помітна частка провалів LCP лежать на першому боці й реально лагодяться грамотною маркетинговою командою за півдня: роздута картинка в першому екрані, відсутні ширина й висота у вбудованого блока, банер, що вставляється в перший екран після завантаження, шрифт, який блокує відмалювання. Провали INP там майже ніколи не лежать. Затримка відгуку - це властивість того, скільки JavaScript виконується в головному потоці й коли саме, а отже лагодження живе всередині архітектури компонентів, стратегії гідратації та бюджету сторонніх скриптів, і до жодного з цього не дотягнутися з панелі налаштувань. Корисне питання перед виділенням бюджету звучить не «наскільки поганий бал», а «у яку з двох категорій потрапляє мій провал», бо відповідь змінює вартість на порядок.

• Зазвичай лагодить ваша команда: Нестиснуті або надмірно великі картинки першого екрана; відсутність атрибутів width і height у зображень, iframe та рекламних блоків; пізно вставлювані cookie-банери та промо-смуги; налаштування font-display, яке блокує перше відмалювання; невикористовувані застосунки, пікселі та контейнери тег-менеджера; хостинг без CDN перед ним.
• Потребує інженера: INP, спричинена вартістю гідратації або розміром бандла; елемент LCP, який рендериться на клієнті й тому не може почати завантажуватися до виконання JavaScript; блокувальні сторонні скрипти, які не можна просто видалити з бізнес-причин; зміщення макета, що народжуються в дереві компонентів, а не в одному файлі; переписування шаблонів там, де проблема в самій структурі сторінки.
• Швидка діагностична ознака: Якщо провалилася CLS, починайте зі своєї команди. Якщо INP, починайте з інженера. Якщо LCP, подивіться, що саме є найбільшим елементом: картинка зазвичай ваша, клієнтськи відмальований блок зазвичай ні.
• За темою: Про архітектурний розбір шляху відмалювання та відгуку за проваленою оцінкою - послуга Core Web Vitals та оптимізація продуктивності. Інженерні деталі саме щодо INP - у посібнику з оптимізації INP.

У якому порядку лагодити проблеми Core Web Vitals?

У порядку передбачуваності, а не тяжкості. Виправлення CLS майже детерміновані: зарезервували місце під елемент - прибрали спричинене ним зміщення, і ефект видно одразу в лабораторії та надійно в полі. Виправлення LCP здебільшого передбачувані, оскільки найбільший елемент визначається однозначно, а робота зводиться до стиснення, пріоритету та доставки. Виправлення INP найменш передбачувані та найінвазивніші, бо та сама затримка відгуку може приходити з чотирьох різних джерел, а лікування архітектурне. Робота в такому порядку фіксує підтверджені поліпшення рано, утримує кількість одночасних змін достатньо малою для атрибуції та приводить вас до дорогої архітектурної роботи вже без дешевих виграшів у вимірюванні.

• 1. Підтвердьте ціль. Назвіть провалену метрику, пристрій і шаблон до того, як чіпати код. Лагодження не тієї метрики дає зелений лабораторний бал і незмінену оцінку.
• 2. Полагодьте CLS. Зарезервуйте розміри в кожного зображення, iframe, вбудованого блока та рекламного місця. Винесіть вставлювані банери з потоку макета або відмальовуйте їх на сервері з уже виділеним місцем. Вантажте шрифти зі співставленим за метриками запасним варіантом, щоб підміна не перекладала текст.
• 3. Полагодьте LCP. Визначте елемент LCP у DevTools, потім зробіть його знаходжуваним у вихідному HTML, коректно розмірним, відданим у сучасному форматі та пріоритетним. Якщо він рендериться на клієнті, перенесення його в серверну віддачу зазвичай дає більше, ніж будь-яка оптимізація файлу.
• 4. Полагодьте INP. Скоротіть і відкладіть JavaScript у головному потоці, розбийте довгі задачі на межах взаємодій, ізолюйте сторонні скрипти та звузьте поверхню гідратації. Це архітектурна робота, і її місце останнє, коли вимірювання вже не забруднене першими трьома кроками.
• 5. Вимірюйте в полі й чекайте. Підтвердьте зміну у власному RUM за кілька днів, потім дайте 28-денному вікну змінитися, перш ніж читати оцінку як вердикт.

Скільки часу потрібно, щоб оцінка знову стала зеленою?

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

Висновок

Провалена оцінка Core Web Vitals - вузьке й точно визначене твердження: за останні 28 днів щонайменше одне з трьох чисел вийшло за свій поріг більш ніж на чверті реальних візитів по групі ваших сторінок. Майже вся марна робота навколо цього зводиться до трьох помилок прочитання: довіри лабораторному балу замість польових даних, сприйняття 28-денного відставання як доказу невдалого лагодження та припущення, що вплив на позиції більший, ніж він є. Прочитайте рядки проблем, щоб назвати метрику й шаблон, вирішіть, файлова це проблема чи архітектурна, лагодьте в порядку передбачуваності, а потім перечекайте вікно замість того, щоб ітерувати всередині нього. За такого підходу робота займає кілька сфокусованих днів плюс місяць терпіння замість шеститижневого проєкту зі стиснення картинок, який лишає провалену метрику незайманою.

Перевірте свої числа: безкоштовний аудит сайту повертає ваші польові дані, лабораторні метрики та проблеми сторінки за ними будь-яким URL, без реєстрації. Якщо провал виявиться архітектурним, послуга Core Web Vitals та оптимізація продуктивності закриває роботу з відмалюванням і відгуком, а обговорити, що саме показує ваш звіт, можна на консультації.

Джерела

• Google web.dev - Core Web Vitals
• Довідка Search Console - звіт Core Web Vitals
• Google web.dev - Largest Contentful Paint (LCP)
• Google web.dev - Interaction to Next Paint (INP)
• Google web.dev - Cumulative Layout Shift (CLS)
• Chrome UX Report - документація API
• Google web.dev - відмінності лабораторних і польових даних
• HTTP Archive - 2025 Web Almanac, розділ Performance
• Google Search Central - про page experience
• Бібліотека web-vitals на GitHub