Core Web Vitals evaluation
Рекомендовані пороги оцінюються на 75-му перцентилі окремо для mobile та desktop experiences.
Вебпродуктивність · Core Web Vitals · Вимірювання
Як правильно тестувати Core Web Vitals: CrUX vs PageSpeed Insights vs Lighthouse vs RUM
CrUX, PageSpeed Insights, Lighthouse і RUM — не чотири конкурентні способи виміряти одне й те саме. Я використовую field data, щоб зафіксувати проблему реальних користувачів, калібрую lab profiling під affected audience, знаходжу механізм у trace, впроваджую мінімальну зміну й повертаюся до field data для валідації.
Коротка відповідь
Починайте з field evidence, а не з Lighthouse score. Я беру CrUX як публічний baseline, щоб зрозуміти, чи є проблема Core Web Vitals у реальних eligible Chrome users, а first-party RUM або analytics використовую для уточнення affected cohort. Lighthouse і локальне DevTools profiling — це контрольоване середовище для debugging: його потрібно налаштувати так, щоб воно наближало реальних користувачів, відтворити symptom, дослідити trace і вже після release перевірити результат у field data. Green lab run корисний, але не замінює field measurement.
CrUX rolling window
PSI field data та CrUX API використовують trailing 28-day collection period, що оновлюється щодня.
Good LCP · INP · CLS
Поточні good thresholds для LCP, INP та CLS відповідно.
CrUX form factors
CrUX дає phone, tablet і desktop, але не точні моделі девайсів, тому calibration потребує first-party context.
Measurement model
Core Web Vitals test — це не один тест
Перше рішення — не який інструмент кращий, а на яке питання ви зараз шукаєте відповідь.
Найпоширеніша помилка — скласти CrUX percentile, PageSpeed Insights lab result, локальний Lighthouse run і RUM percentile в одну категорію під назвою score. У них різні populations, time windows і рівень контролю. Field data показує, що реально пережили користувачі; lab data дає контрольоване середовище для reproduction та diagnosis. Google проводить ту саму межу: CrUX і PSI field data — це real-user distributions, тоді як Lighthouse — simulated load для diagnostics.
| Джерело | Що воно представляє | Найкраще питання | Головне обмеження |
|---|---|---|---|
| CrUX | Aggregated eligible Chrome user experiences; page або origin; rolling 28 days | Чи існує real-user problem і на якому form factor? | Публічний aggregate; Chrome-only eligible population; обмежена сегментація |
| PageSpeed Insights | CrUX field data плюс Lighthouse lab analysis в одному interface | Чи можу я швидко побачити field status і lab diagnostic для URL? | Field і lab panels — різні datasets і можуть закономірно не збігатися |
| Lighthouse / DevTools | Один controlled або simulated test environment | Чи можу я відтворити symptom і зрозуміти причину? | Один run не є distribution реальних користувачів і залежить від умов |
| First-party RUM | Measurements з реальних visits до вашого продукту | Які routes, cohorts, releases або environments реально affected? | Implementation, consent, sampling і methodology стають вашою відповідальністю |
ДжерелоGoogle for Developers — About PageSpeed Insights · Chrome for Developers — CrUX methodology · Chrome for Developers — Lighthouse performance scoring · web.dev / Chrome team — Why is CrUX data different from my RUM data? · web.dev / Chrome team — Best practices for measuring Web Vitals in the field
Кастомна схема
Field evidence має визначати lab experiment
CrUX і RUM фіксують production problem. PSI може показати field signal разом із Lighthouse snapshot. Lighthouse і DevTools перетворюють цей signal на контрольований експеримент, а не замінюють його.
Field baseline
Починайте з CrUX — але перед дією перевірте URL, origin і form factor
Real-user number корисний лише тоді, коли ви точно знаєте population та aggregation, які він представляє.
CrUX — моя стартова точка, бо він відповідає на ключове перше питання: чи видно проблему в real-user data? Але я ніколи не копіюю першу цифру з interface. PSI може показувати page-level CrUX, коли URL має достатньо data, і fallback на origin-level, коли її недостатньо. Search Console іде ще далі та групує схожі URL. Це три різні grains, і їх змішування легко спрямовує investigation на сторінку, яку окремо взагалі не вимірювали.
Зберіть CrUX baseline, який можна захистити
- 1
Перевірте grain
У PageSpeed Insights переконайтеся, чи field panel показує requested URL, чи Origin fallback. Не приписуйте origin-wide p75 одній сторінці.
Шлях
PageSpeed Insights → Discover what your real users are experiencing → This URL / OriginКритерійУ notes явно записано URL-level або origin-level.
- 2
Розділіть mobile та desktop
Читайте affected form factor окремо. Core Web Vitals target оцінюється на p75 за device category, а Search Console також розділяє Mobile і Desktop.
Шлях
PSI / CrUX → form factor · Search Console → Core Web Vitals → Mobile або DesktopКритерійFailing metric і p75 записані для релевантного form factor, а не лише all-device aggregate.
- 3
Зафіксуйте collection window
Збережіть first/last dates або принаймні access date. CrUX API чи PSI field number представляє rolling 28-day period, а не лише performance поточного deployment.
КритерійBaseline містить measurement window і verification date.
- 4
Дивіться на distribution, а не тільки badge
Збережіть p75 разом із good / needs-improvement / poor distribution, якщо воно доступне. Threshold classification приховує, наскільки cohort близький до межі.
КритерійEvidence package зберігає percentile і distribution, а не лише green/amber/red label.
- 5
Коли UI неоднозначний — робіть explicit query
Для відтворюваних перевірок використовуйте CrUX API з конкретним URL або origin і formFactor. API підтримує DESKTOP, PHONE та TABLET.
КритерійQuery target і form factor чітко задані та відтворювані.
| Surface | Granularity | Time behavior | Для чого використовувати |
|---|---|---|---|
| PSI field panel | Page, якщо eligible; інакше origin fallback | Trailing 28 days, daily update | Швидка перевірка URL, але завжди верифікуйте grain |
| CrUX API | Page або origin; optional form factor | Trailing 28 days, daily update | Reproducible queries та automation |
| CrUX History API / CrUX Vis | Page або origin; form factor | 40 weekly points, кожен на основі 28-day collection period | Trend context без хибного припущення, що кожна точка — незалежний тиждень |
| Search Console Core Web Vitals | Groups of similar URLs; Mobile / Desktop | 28-day field measurements як issue groups | Пріоритизація site-wide cohorts, а не diagnosis одного exact URL |
PSI interpretation
PageSpeed Insights — це два вимірювання в одному report
Field panel і Lighthouse panel стоять поруч в interface, але це не observations одного run.
PageSpeed Insights корисний саме тому, що показує поруч два evidence layers: верхній field section — це CrUX за попередні 28 днів, а lab diagnostics формує Lighthouse у simulated environment. Через таку зручність виникає типова помилка: field p75 LCP порівнюють із поточним Lighthouse LCP так, ніби значення мають відтворювати одне одного. Не мають. Перше — historical distribution у багатьох real-user conditions; друге — controlled single test.
Кастомна схема
Читайте PageSpeed Insights як field evidence + lab experiment
PSI може показувати CrUX distribution і Lighthouse diagnostic для одного requested URL, але population і time horizon цих шарів різні.
Три перевірки перед тим, як цитувати PSI number
- Field value показано для This URL чи Origin?
- Ви цитуєте field p75 чи Lighthouse lab metric?
- Який form factor, collection period і lab environment представляє число?
Lab variability
Чому та сама сторінка може показати 2.0s, потім 4.0s і 3.5s LCP у Lighthouse
Repeated lab runs — це samples із test environment. Вони стають evidence лише тоді, коли environment контрольований і задокументований.
У щоденному profiling я очікую, що repeated Lighthouse runs будуть рухатися. Простий illustrative sequence: LCP 2.0 s → 4.0 s → 3.5 s на тій самій сторінці без code change. Це не client measurements, а приклад того, чому я ніколи не беру найшвидший run і не оголошую сторінку fixed. Google серед типових sources of variability називає network routing, різне hardware, browser extensions, antivirus та інший resource contention. PageSpeed Insights також окремо згадує local network availability, client hardware і client resource contention.
| Run | LCP | Що це доводить |
|---|---|---|
| 1 | 2.0 s | Лише те, що цей конкретний execution дав good LCP у своїх умовах |
| 2 | 4.0 s | Test environment або page behavior достатньо variable, щоб змінити висновок |
| 3 | 3.5 s | Один best run не є стабільним baseline; потрібно дослідити spread та умови |
Зробіть lab measurements порівнюваними
- 1
Зафіксуйте tested state
Використовуйте той самий route, build, feature flags, consent state та user journey. Якщо ads або experiments nondeterministic — зафіксуйте limitation або контролюйте їх у dedicated test environment.
КритерійКожен run стартує з однаково задокументованого application state.
- 2
Приберіть зайвий machine noise
За можливості використовуйте clean browser profile без extensions і закрийте важкі локальні workloads, які конкурують за CPU, memory або network.
КритерійMachine та browser state достатньо стабільні між runs.
- 3
Свідомо оберіть cache state
Не змішуйте cold-load та warm-cache runs в одному comparison. Оберіть state під конкретне питання й тримайте його однаковим для baseline та candidate build.
КритерійУсі порівнювані runs мають однакове cache/storage rule.
- 4
Зафіксуйте CPU та network settings
Для comparison використовуйте один задокументований throttling profile. Він має наближати affected audience, а не бути випадковим preset.
КритерійCPU і network settings записані разом із результатом.
- 5
Запустіть невелику repeatable series
Для цього workflow моя рекомендація — п’ять equivalent runs, коли це практично. Зберігайте всі результати, використовуйте median як compact summary і дивіться на spread. П’ять запусків — practical comparison protocol цього гайду, а не Google threshold чи official standard.
КритерійBaseline і candidate мають однаковий run count, conditions, median та visible spread.
- 6
Збережіть trace для slow cases
Outlier часто має діагностичну цінність. Якщо один run регресує, відкрийте Performance trace і network activity, а не усереднюйте symptom до зникнення.
Шлях
Chrome DevTools → Performance → Record and reload / RecordКритерійRepresentative slow trace можна прив’язати до конкретного loading, scripting або rendering mechanism.
Audience calibration
Калібруйте local profiling під своїх користувачів, а не під generic 4G preset
Reproducible lab корисний; reproducible lab, що нагадує affected cohort, значно корисніший.
Моя звична послідовність — field baseline → audience profile → local reproduction. Спочатку в CrUX визначаю, де проблема сильніша: mobile чи desktop. Потім використовую first-party analytics або RUM, щоб зрозуміти реальний traffic mix: browser, viewport/device class, route, geography або release cohort — там, де це доступно й privacy-safe. І лише після цього обираю CPU та network constraints. 4G — це приклад, а не універсальний preset. Якщо він не наближає affected users, для цього investigation він неправильний.
Побудуйте local test profile з audience evidence
- 1
Знайдіть failing field cohort
Почніть із CrUX або Search Console device category та metric, який реально failing на p75.
КритерійДо відкриття DevTools ви можете чітко назвати field cohort і metric.
- 2
Додайте first-party audience context
Використайте analytics/RUM, щоб побачити route types, screen/device classes, browsers або releases, які домінують у affected traffic. Не очікуйте від CrUX exact phone model: його public form-factor dimension — лише phone, tablet або desktop.
КритерійLocal profile обґрунтований first-party audience evidence, а не generic device persona.
- 3
Увімкніть field overlay у Performance panel
У Chrome DevTools Performance увімкніть CrUX Field metrics. Live Metrics показує local metrics поруч із field metrics, а Environment settings може рекомендувати device, CPU і Network throttling на основі CrUX data.
Шлях
Chrome DevTools → Performance → Live metrics → Field metrics / Environment settingsКритерійLocal та field context видно одночасно, а обраний environment задокументований.
- 4
Обережно калібруйте CPU
DevTools дозволяє calibrate custom CPU throttling presets для наближення low- та mid-tier mobile devices, але slowdown відносний до вашого комп’ютера. Chrome прямо зазначає, що desktop CPU не може точно симулювати mobile CPU architecture.
Шлях
Performance → Capture settings → CPU → CalibrateКритерійReport містить host machine і selected/calibrated CPU slowdown, а не твердження про exact device simulation.
- 5
Відтворіть реальний journey
Для LCP тестуйте navigation state, що створює slow load. Для INP та CLS включайте interactions або post-load behavior, на які вказують field data чи RUM. Load-only Lighthouse audit не бачить усі interaction-driven issues.
КритерійTest journey здатний викликати той самий class of symptom, з якого почалося investigation.
First-party field data
Використовуйте RUM, коли CrUX занадто грубий для рішення
CrUX — сильний public baseline, але first-party RUM відкриває cohorts і release context, потрібні для дії.
CrUX — не census усіх відвідувачів. Поточні eligibility rules охоплюють supported Chrome platforms та opted-in users; Chrome on iOS, Android WebView і інші Chromium browsers на кшталт Edge не потрапляють у CrUX. Якісний RUM тому може відповісти на питання, які public CrUX не закриває: який route template регресував після release X, чи гірший певний browser cohort, чи відрізняються signed-in journeys, який element пов’язаний із poor metric. Але RUM не стає автоматично правильнішим — consent, sampling та implementation choices теж змінюють population.
| Dimension | CrUX | First-party RUM |
|---|---|---|
| Population | Eligible Chrome experiences за CrUX methodology | Visitors, яких ваша implementation має право й можливість виміряти |
| Time window | Fixed rolling 28-day view у common CrUX surfaces | Може бути release-, day- або cohort-specific за достатнього sample size |
| Device detail | Phone / tablet / desktop public form factor | Можна додати privacy-safe device, viewport або browser cohorts |
| Route / release context | Page/origin aggregates; Search Console URL groups | Можна додати normalized route templates, build/release IDs і journeys |
| Debug attribution | Обмежені public aggregates | Можна збирати targeted LCP/INP/CLS attribution з відповідною instrumentation |
STATICALLY VERIFIED · Мінімальний first-party Web Vitals attribution payload
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendWebVital(metric) {
const attribution = metric.attribution || {};
const target =
metric.name === 'LCP' ? attribution.target :
metric.name === 'INP' ? attribution.interactionTarget :
metric.name === 'CLS' ? attribution.largestShiftTarget :
null;
const payload = {
name: metric.name,
value: metric.value,
rating: metric.rating,
id: metric.id,
path: location.pathname,
target: target || null
};
navigator.sendBeacon(
'/rum/web-vitals',
new Blob([JSON.stringify(payload)], {type: 'application/json'})
);
}
onLCP(sendWebVital);
onINP(sendWebVital);
onCLS(sendWebVital);Syntax checked 2026-09-08. Потрібні package web-vitals і site-specific endpoint /rum/web-vitals. Тримайте payload мінімальним; нормалізуйте routes і видаляйте identifiers або sensitive data до collection.
Metricum Lab method
Мій workflow: field signal → cohort → lab → trace → release → field
Measurement chain має робити явним кожен перехід: що ми observed, що hypothesize, як reproducing і як validate release.
Я використовую CrUX як перший public baseline, а не фінальний diagnostic. Коли field signal зрозумілий, визначаю affected audience, роблю lab достатньо схожим на нього, щоб відтворити symptom, знімаю trace, перевіряю по одній falsifiable hypothesis і повертаюся в production. Такий порядок захищає від двох типових помилок: оптимізувати Lighthouse number, якого немає в жодного реального user cohort, або впровадити plausible fix, який ніколи не був пов’язаний із field regression.
Кастомна схема
Field-to-lab-to-field validation loop
Кожна lab action прив’язана до production signal, а кожен release повертається до production measurement замість завершуватися synthetic score.
Проведіть investigation як evidence chain
- 1
1 · Зафіксуйте field problem
Запишіть CrUX p75, distribution, grain, form factor та collection window для failing metric.
КритерійProblem statement можна сформулювати без згадки Lighthouse.
- 2
2 · Визначте affected cohort
Коли доступно, використайте RUM/analytics для route, browser, viewport/device class, geography або release differences, яких public CrUX не показує.
КритерійHypothesis називає cohort, а не абстрактного average user.
- 3
3 · Відтворіть у controlled conditions
Налаштуйте browser environment під цей cohort і повторіть той самий navigation або interaction journey.
КритерійSymptom з’являється достатньо стабільно для capture trace у задокументованих conditions.
- 4
4 · Знайдіть mechanism у trace
Performance panel має зв’язати metric із network, main-thread, rendering або layout evidence. Відокремлюйте observed trace від hypothesis про root cause.
КритерійProposed change посилається на observed mechanism у representative trace.
- 5
5 · Змініть один causal lever
Віддавайте перевагу найменшій зміні, що може falsify або підтримати current hypothesis. Broad bundle performance edits ускладнює attribution.
КритерійДля того самого controlled test є чітке before/after expectation.
- 6
6 · Validate у production RUM
Після release порівняйте affected cohort з baseline за тією самою metric definition та після достатньої кількості samples. Одночасно перевірте інші Core Web Vitals.
КритерійProduction distribution рухається в очікуваний бік без material new regression.
- 7
7 · Дайте CrUX підтвердити durable outcome
CrUX/History використовуйте як повільніше public confirmation. Через rolling 28-day window реальний release improvement не має повністю переписати field distribution наступного ранку.
КритерійLonger-window field trend узгоджується з production RUM або remaining disagreement досліджено.
Decision support
Коли CrUX, PSI, Lighthouse і RUM не збігаються — діагностуйте mismatch
Розбіжність — не причина обрати улюблений tool. Це evidence, що population, grain, timing або environment різні.
| Observed pattern | Найімовірніше трактування | Наступна дія |
|---|---|---|
| CrUX poor · Lighthouse good | Lab не відтворив affected field conditions або journey | Перевірте URL vs origin, form factor, RUM cohorts, throttling та interaction path; потім зніміть representative trace |
| CrUX good · Lighthouse poor | Constrained lab case може бути рідкіснішим або суворішим за current field p75 | Зберігайте lab issue, якщо він показує meaningful risk, але не називайте його current field failure |
| PSI показує origin data · один URL виглядає poor | Field number належить origin aggregate, а не обов’язково цьому URL | Query URL-level CrUX, якщо eligible, або використайте RUM перед assigning root cause сторінці |
| RUM poor · CrUX good | Populations або metric implementations різні, або issue concentrated у cohort, який CrUX згладжує | Спочатку вирівняйте Chrome-only / device / 28-day comparison, потім audit RUM instrumentation і cohort mix |
| Search Console group poor · sampled URL good | URL group може мати shared status, а один example URL бути outlier | Досліджуйте template/cohort та інші group members, а не робіть group verdict з одного URL test |
| Lighthouse baseline і candidate сильно overlap | Apparent change менший за test variability | Посильте control/repetition, аналізуйте traces і не заявляйте improvement за best individual run |
Для CLS lab/field gaps особливо типові, коли shifts виникають після user interaction. Той самий принцип використано в Metricum Lab CLS debugging guide: відтворіть user journey, збережіть evidence і перевірте результат у field data замість завершувати load-only audit.
Release gate
Green Lighthouse run — не моє визначення fixed
Fix завершено, коли mechanism покращився в controlled conditions, а affected production distribution рухається в той самий бік.
Lab потрібен мені для швидкого feedback. Field — для фінального verdict. Сильна performance change має пройти обидва рівні: same controlled test покращується з explainable reason, а після release рухається production cohort. CrUX свідомо повільніший через 28-day rolling aggregates, тому RUM дає earlier release feedback, а CrUX — durable public confirmation.
Release validation contract
- 1
Controlled comparison покращився
Повторіть той самий lab contract для baseline і candidate build; порівнюйте median, spread та traces, а не один best run.
КритерійCandidate кращий в equivalent conditions, а mechanism видно у trace evidence.
- 2
Не приховано trade-off між Core Web Vitals
Перевірте LCP, INP і CLS разом. Зміна, що покращує одну metric ціною material regression іншої, не є clean win.
КритерійВ інших Core Web Vitals немає нового material regression.
- 3
Production RUM рухається для affected cohort
Порівняйте той самий route/device/browser/release cohort і metric definition після достатньої кількості real-user samples.
КритерійField distribution рухається в очікуваний бік із sufficient sample context.
- 4
CrUX наздоганяє зміни у rolling window
Стежте за PSI/CrUX або History API без очікування overnight reset. Weekly historical points усе одно базуються на overlapping 28-day collection periods.
КритерійLonger public field trend підтверджує improvement або показує remaining cohort mismatch.
- 5
Збережіть evidence package
Зберігайте field baseline, environment contract, representative traces, code change, release ID і post-release field comparison. Так fix стає regression test, а не одноразовим успіхом.
КритерійМайбутню regression можна порівняти з тим самим evidence chain.
Практичний принцип простий: CrUX визначає, чи є real-user problem; RUM уточнює, хто саме його має; Lighthouse і DevTools допомагають відтворити та пояснити; після цього field data має довести, що change спрацював. Якщо проблема у visual stability, продовжуйте з CLS debugging workflow. Той самий field-first принцип буде основою нашого LCP diagnosis workflow.
Першоджерела та документація
Джерела
Кожне змінне твердження про пошукову систему, браузер, інтерфейс або технічну поведінку в матеріалі прив’язане до актуального першоджерела.
- web.dev / Chrome team Web Vitals (відкриється в новій вкладці)Актуальні визначення Core Web Vitals, пороги та правило 75-го перцентиля.
- Google for Developers About PageSpeed Insights (відкриється в новій вкладці)Першоджерело про field/lab у PSI, 28-денне вікно CrUX, URL→origin fallback і варіативність запусків.
- Chrome for Developers CrUX Tools (відкриється в новій вкладці)Порівняння CrUX API, History API, PSI, Search Console і BigQuery за вікном та гранулярністю.
- Chrome for Developers CrUX methodology (відкриється в новій вкладці)Eligibility, page/origin aggregation і обмеження вибірки користувачів CrUX.
- Chrome for Developers CrUX dimensions (відкриється в новій вкладці)Визначення form factor: phone, tablet і desktop.
- Chrome for Developers CrUX API (відкриється в новій вкладці)Програмні page/origin запити, p75 та фільтрація за form factor.
- Google Search Console Help Core Web Vitals report (відкриється в новій вкладці)Групування Search Console, device views, джерело CrUX і трактування p75 за останні 28 днів.
- Chrome for Developers Performance features reference (відкриється в новій вкладці)Live Metrics, CrUX field overlay, рекомендації середовища та CPU/network throttling.
- Chrome for Developers Lighthouse performance scoring (відкриється в новій вкладці)Офіційна документація про варіативність Lighthouse metrics і Performance score.
- web.dev / Chrome team Why lab and field data can be different (and what to do about it) (відкриється в новій вкладці)Пояснення різниці між контрольованим lab-середовищем і розподілом real-user experiences.
- web.dev / Chrome team Why is CrUX data different from my RUM data? (відкриється в новій вкладці)Порівняння population, aggregation та measurement differences між CrUX і first-party RUM.
- web.dev / Chrome team Best practices for measuring Web Vitals in the field (відкриється в новій вкладці)Чому production field measurement потрібен для перевірки реального ефекту змін.
- web.dev / Chrome team Debug performance in the field (відкриється в новій вкладці)Field-to-lab debugging model та guidance для real-user attribution.
- GoogleChrome / GitHub web-vitals library README (відкриється в новій вкладці)Актуальне використання бібліотеки й attribution build для LCP, INP та CLS diagnostics.
Потрібна допомога з діагностикою та впровадженням?
Перетворіть Core Web Vitals measurements на відтворюваний performance backlog
Metricum Lab може зв’язати CrUX і first-party field signals із controlled browser traces, implementation hypotheses та post-release validation — без оптимізації Lighthouse number у відриві від користувачів.
Переглянути Core Web Vitals Optimization