How Performance Works

speed Що показує вкладка Performance

Performance показує швидкість і якість завантаження ваших сторінок очима Google. Це той самий сигнал який Google використовує для ранжування з 2021 року (Page Experience update).

Ми тягнемо дані з двох офіційних Google API:

PageSpeed Insights (PSI) — синтетичний прогон Lighthouse у Google датацентрі. Дає Performance / SEO / Accessibility / Best Practices score (0-100) і lab-значення Core Web Vitals.
Chrome UX Report (CrUX) — реальна статистика від користувачів Chrome за останні 28 днів (rolling window) + 25 тижнів історії. Це той самий field-data який Google використовує для ранжування.

Скан працює у двох режимах: щоденний (top-20 by clicks) о 08:00 UTC і раз на тиждень deep scan (top-100 by clicks) о 03:00 UTC. Кожен сайт отримує один deep scan на тиждень + 6 щоденних. Скануємо у двох стратегіях — Mobile і Desktop. Зберігаємо історію, не перетираємо.

science Lab vs Field — два різні джерела

Це найважливіше що треба зрозуміти про Performance. Lab і Field — це не "одне правильне, інше неправильне", вони відповідають на різні питання:

Аспект	Lab (Lighthouse)	Field (CrUX)
Хто вимірює	Бот Google у датацентрі	Реальні юзери у Chrome (опт-ін)
На якому пристрої	Стандартний емулятор (Moto G4, 4G)	Реальні пристрої / мережі юзерів
Скільки даних	Один прогін на момент сканування	Агреговано за 28 днів
Що відповідає	"Як швидко вона працює в ідеалі"	"Як її бачать ваші реальні юзери"
Використовується Google для ранжування	❌ Ні	✅ Так — це той самий сигнал
Завжди є	✅ Так — Google прогоняє по запиту	❌ Тільки для сайтів з достатнім Chrome-трафіком

Просте правило: якщо хочете оцінити що бачить Google для ранжування — дивіться Field (CrUX). Якщо хочете дебажити конкретні проблеми (важкі скрипти, повільний LCP, blocked render) — дивіться Lab (Lighthouse), бо там Top Issues з конкретними рекомендаціями.

grid_view 9 KPI-карток зверху

Зверху сторінки — три ряди карток. Перші 4 — Lighthouse scores (0-100), решта 5 — Core Web Vitals. На hover показується звідки число (real users / synthetic).

Lighthouse scores (0-100)

Performance — як швидко сайт стає інтерактивним. Агрегує LCP, INP, CLS, FCP, TTFB.
SEO — базові SEO-практики: meta description, alt-теги, valid hreflang, crawlable links.
Accessibility — кольорові контрасти, ARIA-атрибути, semantic HTML.
Best Practices — HTTPS, console errors, deprecated APIs, image aspect ratios.

Кольори: ≥90 зелений 50-89 жовтий <50 червоний

Core Web Vitals

Метрика	Що означає	Good	Needs Improvement	Poor
LCP Largest Contentful Paint	Час до появи найбільшого елементу на екрані	< 2.5 с	2.5-4.0 с	> 4.0 с
INP Interaction to Next Paint	Затримка відповіді сайту на клік/тап	< 200 мс	200-500 мс	> 500 мс
CLS Cumulative Layout Shift	Скільки сторінка "стрибає" поки вантажиться	< 0.1	0.1-0.25	> 0.25
FCP First Contentful Paint	Час до появи будь-чого крім білого екрану	< 1.8 с	1.8-3.0 с	> 3.0 с
TTFB Time to First Byte	Час до першого байту від сервера	< 0.8 с	0.8-1.8 с	> 1.8 с

Числа на картках — це field (real users з CrUX) якщо доступно, інакше lab fallback. На hover видно джерело.

verified Core Web Vitals — Google ranking signal

Нижче 9 KPI-карток є окремий блок Core Web Vitals з 4 картками: Passes CWV, LCP, INP, CLS.

Це саме той сигнал який Google використовує для ранжування, тому тут показуємо не середнє значення, а офіційну Google-логіку через гістограму:

Кожна метрика розділяється на 3 bucket: Good Needs Improvement Poor
На картці показано % сторінок у Good + кольоровий bar з розподілом
Passes CWV = сайт проходить тоді коли ≥75% сторінок у Good на ВСІХ трьох метриках одночасно (LCP + INP + CLS)
Зелена рамка картки = passing, червона рамка = failing

75% правило — точне формулювання Google: "Sites should meet the recommended targets at the 75th percentile of page loads, segmented across mobile and desktop devices." Тобто якщо у вас 100 page-loads, мінімум 75 з них мають бути у Good по LCP і по INP і по CLS — тоді сайт passes.

bar_chart Distribution over time

Це стек-бар чарт під CWV-картками. Кожен бар — один тиждень за останні 25 тижнів. Висота стеку — 100% page-loads за цей тиждень, поділені на Good / NI / Poor (зелений / жовтий / червоний).

Пунктирна горизонтальна лінія на 75% — це Google's pass-cutoff. Якщо зелена частина бару доходить до неї — сайт passing CWV у цьому тижні.

Зверху селектор LCP / INP / CLS щоб перемикатись між метриками.

Як читати тренд

Зелена частина росте тиждень за тижнем → ваші оптимізації працюють
Раптовий стрибок жовтого/червоного → щось зламалось після релізу (нова важка библіотека, неоптимізоване зображення, change у CDN)
Стабільні значення → можна сфокусуватись на інших аспектах сайту

show_chart Real-user field metrics (25 тижнів)

Нижче — line chart з історичними p75-значеннями Core Web Vitals за 25 тижнів. P75 означає 75-й перцентиль: те значення яке мали 75% користувачів або кращих.

Чому p75, а не середнє: Google свідомо не використовує середнє, бо воно "розмазується" — пара швидких користувачів може приховати проблеми у решти. P75 показує: "найгірший досвід серед 75% ваших юзерів". Якщо p75 = 2.4с — це значить що принаймні три чверті ваших юзерів бачать LCP за 2.4с або краще.

Один CrUX-виклик = 25 тижнів історії. Тому ми не дублюємо запити: на сайт є 7-денний dedup-гард, CrUX все одно оновлює дані лише раз на тиждень.

list Per-URL таблиця і Top issues

Внизу сторінки — таблиця сторінок які ми сканували, відсортована від найгіршої до найкращої по Performance score. Це action list — куди дивитись першочергово.

Ще нижче — "Top issues across pages": агреговані Lighthouse audits, які провалились на кількох сторінках. Це real action list для дев-команди: "5 сторінок з noindex tag", "8 сторінок мають Forced reflow", "1.2 MB unused JS на 6 сторінках".

Кожен audit — клікабельний, розкривається з конкретним рекомендованим фіксом від Google + список сторінок де він провалився.

schedule Розклад і кнопка Refresh

Розклад автоматичного сканування (UTC):

Час	Що відбувається
schedule 03:00 UTC	Weekly deep scan — top-100 by clicks. Запускається тільки для 1/7 сайтів кожного дня (день фіксований для сайту через хеш URL). За тиждень кожен сайт отримає один deep scan.
schedule 08:00 UTC	Daily scan — top-20 by clicks. Скіпає сайти що отримали скан за останні 20 годин (тобто включно з тими, кого зачепило ранковий deep scan).
timer ~3-30 хв на сайт	20 сторінок = ~3-6 хв, 100 сторінок = ~15-30 хв. Працюють 3 PSI-воркери паралельно, не блокують GSC-syncs.

Кнопка Refresh now

Якщо потрібен скан раніше — натисніть Refresh now на сторінці Performance. Що відбудеться:

Кнопка одразу блокується з іконкою-крутилкою і текстом "Refreshing…"
Скан з'являється у черзі PSI-воркера (окремо від GSC-задач, не чекає)
Кожні 30 секунд автоматично перевіряємо чи завершився; як готово — кнопка розблоковується, дані оновлюються
Перезавантажиш сторінку посеред скана — стан зберігається, кнопка лишається заблокованою
Якщо інший член команди вже запустив скан — твоя кнопка побачить і також заблокується

Limit: Refresh має сенс натискати раз на день — реальна field-data (CrUX) оновлюється у Google лише раз на тиждень. Якщо натиснути 5 разів за годину — це просто перепрожене ті самі Lighthouse-числа і даремно витратить PSI-квоту.

visibility_off Чому Core Web Vitals блоки порожні

Інколи 9 KPI-карток зверху заповнені, але блок Core Web Vitals + Distribution + 25-week trend — порожні. Це не баг. Це означає що Chrome UX Report від Google не має статистики для цього сайту.

CrUX публікує дані тільки якщо у нього достатньо samples від реальних Chrome-користувачів. Google не публікує точне число, але практично — приблизно мінімум кілька тисяч унікальних Chrome-юзерів на місяць на origin. Якщо сайт:

Новий або з низьким трафіком
Має багато трафіку через мобільні апплікації / inApp-браузери (не Chrome)
У сегментах де Chrome не домінує (наприклад, певні регіони з Samsung Internet)

...то CrUX повертає chrome ux report data not found для всіх URL цього сайту, навіть на origin-рівні.

Як перевірити вручну

Відкрийте pagespeed.web.dev, вставте URL сайту. Якщо там показано "Real-user experience data isn't available for this URL/origin" — це підтвердження, проблема не у нас, а у відсутності CrUX-покриття.

Що з цим робити: нічого з нашого боку. Як тільки сайт досягне CrUX-порогу (зросте Chrome-трафік), Google автоматично почне публікувати дані — наш cron підтягне без додаткових налаштувань. Lab-метрики (Lighthouse) працюють завжди — це наш best signal для таких сайтів.

help Часті питання

Чому числа PSI у мене відрізняються від pagespeed.web.dev?

Якщо різниця 1-3 поінти — це норма. Lighthouse є varianца у кожному прогоні (мережа, CPU load на тестовому сервері Google). Ми зберігаємо історію, тому ви бачите тренд за тиждень — він стабільніший за один прогін. Якщо різниця 20+ поінтів — можливо у нас застарілий run, натисніть Refresh now.

Які саме сторінки сканують?

Top-N за clicks у Google пошуку за останні 28 днів (з impressions як tiebreaker для сторінок з 0 кліків). Daily — top-20, weekly deep — top-100. Кліки краще відображають business-critical сторінки ніж raw impressions: реальні юзери туди прийшли і ви знаєте що сторінка важлива. Якщо сайт новий і трафіку немає — fallback на homepage. Конкретний список видно у per-URL таблиці внизу.

Як додати свою сторінку у scan list?

Поки що — ніяк, селектація автоматична. На roadmap є "custom URLs to monitor" — налаштування вручну.

Чому 20 щоденно, а 100 раз на тиждень?

Це баланс між свіжістю і квотою. PSI-квота Google = 25 000 викликів/день безкоштовно. У нас ~340 сайтів. Якщо робити 100 сторінок щоденно для всіх — це 68 000 викликів/день, більше 2.5× понад квоту. Тому:

Daily 20 = ~13 500 викликів/день для всіх сайтів — найважливіші сторінки оновлюються щодоби
Weekly 100 = ~9 600 викликів/день (~1/7 сайтів × 100) — повна картина оновлюється раз на тиждень
Сумарно ~21 000 викликів/день (~84% квоти) — з запасом на ручний Refresh і spikes

Field-data (CrUX) Google і так оновлює лише раз на тиждень — тому daily частіше за weekly не дає інформативного приросту для real-user metrics.

Як дізнатись який день — мій deep scan?

День deep scan фіксований для кожного сайту через хеш його URL (детермінований). Не залежить від того коли ви додали сайт. Конкретний день видно непрямо — у per-URL таблиці внизу буде раптом 100 сторінок замість 20 у певний день тижня.

Можна додати інші сайти у CrUX вручну?

Ні. CrUX dataset — це не sitemap, ви не можете "субмітити" туди свій сайт. Google автоматично включає сайт коли у нього достатньо опт-ін Chrome-юзерів за останні 28 днів. Це пасивний dataset.

INP = 0 — це баг?

Можливо. INP вимірюється тільки коли у юзера є хоч одна взаємодія (клік, тап, тип). Якщо ваш сайт лендинг без CTA-кнопок або юзери приходять і йдуть — INP буде null/0. Це не означає ідеал, це означає "немає даних".

Чому Lighthouse Performance score стрибає від 60 до 95?

Звичайна Lighthouse varianца. Google запускає тест на shared compute — CPU contention впливає. Тому довіряйте тренду за тиждень, а не одному значенню.

Чим відрізняється від GSC Core Web Vitals report?

GSC Core Web Vitals report агрегує по групах URL ("Good URLs", "Poor URLs") — корисно для понимання обсягу, але деталей мало. Ми показуємо те саме per-page, плюс per-week historical trend на 25 тижнів, плюс lab-аналітику. По суті — те саме джерело (CrUX), просто з більшою деталізацією.