Що вимірює CLS
Cumulative Layout Shift є unitless Core Web Vital для неочікуваного візуального руху. Score фіксує найбільший burst layout shifts протягом page visit, поєднуючи частку viewport із рухом і відстань переміщення elements.
Добрий field target становить 0.1 або менше на 75-му percentile окремо для mobile і desktop. Цей threshold описує user experience на рівні population, але не доводить стабільність конкретної business-critical задачі агента.
- Добре: CLS не вище 0.1
- Потребує покращення: вище 0.1 і не вище 0.25
- Погано: вище 0.25
Observation-to-action gap
Агент може дослідити DOM, accessibility tree або rendered pixels, вибрати control і виконати дію за мить. Якщо image, banner, font, recommendation або validation message пересуває control між цими моментами, збережений target може вже описувати інший element або порожнє місце.
Chrome включає CLS до agentic browsing signals, тому що позиція element може змінитися між identification та interaction. Ризик найбільший для destructive, transactional або сусідніх неоднозначних controls, наприклад confirm і cancel.
- Агент спостерігає named control і його поточний state
- Asynchronous content змінює geometry або stacking
- Дія потрапляє у stale target або task потребує retry
- Final state відрізняється від intended outcome
Вимірюйте повний journey
Стандартний Lighthouse load записує лише початкове synthetic завантаження. Реальні shifts також виникають після scroll, route transitions, search results, consent decisions, authentication, validation і delayed personalization. Використовуйте controlled user-flow trace та field data для повного lifecycle.
Записуйте CLS поруч із task duration, retries та interventions. Shift без task friction залишається performance finding. Малий локальний shift, який спричинив неправильну дію, є task-critical finding навіть тоді, коли aggregate score нижчий за field threshold.
- Session video з timestamps observation, action і outcome
- Performance trace та layout-shift entries з affected nodes
- Before-and-after bounding boxes intended control
- DOM і accessibility snapshots навколо unstable step
- Deterministic assertion server або page state
Excluded shift не завжди є безпечним
Metric зазвичай виключає shifts у межах 500 milliseconds після qualifying discrete input через flag hadRecentInput. Так очікувана відповідь на click, tap або keypress не отримує штраф. Continuous interactions на кшталт scroll обробляються інакше.
Виключення з metric не гарантує agent safety. Якщо delayed response рухає target, поки агент планує наступну дію, workflow все одно може завершитися failure. Зберігайте і standards-based CLS value, і task-level target-stability assertion.
Усуньте типові причини
Почніть із geometry, яку browser може зарезервувати до появи content. Потім перевірте content над поточним viewport, font swaps, responsive image selection і transitions, що змінюють layout properties.
- Задавайте intrinsic width і height або aspect-ratio для images, video, ads та embeds
- Резервуйте стабільний простір для consent, personalization, recommendations і validation
- Preload critical fonts і узгоджуйте fallback font metrics, якщо swap змінює line wrapping
- Додавайте новий content поза active task area або після explicit user request
- Анімуйте transform і opacity замість top, left, width або height
- Тестуйте slow network, empty cache, localization і mobile breakpoints
Перетворіть stability на regression contract
Визначте stability window для кожного критичного кроку: від останнього observation агента до підтвердження action. Вважайте task проваленим, якщо intended control змінює identity, accessible name, visibility або position за межами declared tolerance.
Зберігайте raw CLS score як diagnostic metric, а business impact класифікуйте окремо. Так зберігається сумісність із Core Web Vitals, а agent-specific failure стає відтворюваним для engineering team.
- Версіонуйте viewport, locale, cookie state, agent profile і network preset
- Записуйте successful і failed repetitions
- Пов'язуйте shift з initiating resource або DOM mutation
- Після remediation повторюйте точну task, а не лише landing-page load
Питання CLS-аудиту для agent journeys
- Чи відповідає field CLS значенню 0.1 або менше на p75 для mobile і desktop за наявності достатніх даних?
- Чи охоплює user-flow trace route changes, scroll, forms і delayed content?
- Чи стабільні bounds критичного control між observation та action?
- Чи резервують media, embeds та async modules фінальну geometry?
- Чи можна пов'язати shift з DOM mutation, resource і task timestamp?
- Чи знаходить final-state assertion wrong-target actions і duplicate retries?
Первинні джерела
- Cumulative Layout Shift (CLS)web.dev
- Optimize Cumulative Layout Shiftweb.dev
- Lighthouse agentic browsing scoringChrome for Developers
- Layout Instability APIWICG
