CLS (Cumulative Layout Shift)

CLS (Cumulative Layout Shift) — це показник візуальної стабільності сторінки. Він оцінює неочікувані зміщення елементів: наприклад, коли кнопка раптово пересувається через появу банера, а користувач натискає не туди.

CLS входить до Core Web Vitals. На відміну від LCP та INP, це безрозмірне число, а не секунди чи мілісекунди. Воно враховує частку viewport, яку зачепило зміщення, і відстань переміщення.

Актуальні пороги

• добре: до 0,1 включно;
• потребує покращення: понад 0,1 до 0,25 включно;
• погано: понад 0,25.

Ціль перевіряють на 75-му перцентилі реальних візитів окремо для мобільних і десктопних пристроїв.

Що таке layout shift

Зміщення виникає, коли видимий елемент змінює початкову позицію між двома кадрами. Не кожен рух є проблемою. Анімація через transform або зміна, що очікувано сталася відразу після взаємодії користувача, може не вважатися неочікуваним layout shift.

Поширені причини

• зображення й відео без заданих розмірів або aspect ratio;
• реклама, iframe та embed без зарезервованого місця;
• банери cookie або promo, вставлені над наявним контентом;
• пізня заміна web font із суттєво іншими метриками;
• динамічні віджети й рекомендації;
• асинхронне додавання контенту у верхню частину сторінки.

Практичний приклад

У мобільному інтернет-магазині покупець збирається натиснути «Додати в кошик». Над карткою товару завантажується рекламна плашка, кнопка зміщується вниз, і користувач відкриває інше посилання. Навіть якщо сторінка завантажилася швидко, досвід є поганим через візуальну нестабільність.

Як обчислюється оцінка

Для кожного неочікуваного shift браузер враховує impact fraction і distance fraction. CLS агрегує найбільш проблемне вікно пов’язаних зміщень. Тому один великий стрибок і серія дрібних швидких стрибків можуть бути важливішими за поодинокий рух після довгої паузи.

Як покращити CLS

• задавати width, height або aspect-ratio для медіа;
• резервувати стабільні контейнери під рекламу й embeds;
• показувати банери overlay або в заздалегідь виділеній зоні;
• попередньо завантажувати критичні fonts і узгоджувати їхні метрики;
• не вставляти новий контент над поточним без дії користувача;
• використовувати transform для анімацій замість властивостей layout.

Польові й лабораторні дані

Lab-тест часто завершується швидше, ніж реальний сеанс, і може не побачити shift після прокручування, відкриття меню або завантаження реклами. RUM і CrUX охоплюють довший життєвий цикл сторінки. Для діагностики потрібне поєднання field data, DevTools і відтворення конкретного сценарію.

CLS у SPA

У single-page application навігація може відбуватися без повного перезавантаження. Динамічні переходи, skeleton screens та hydrated components створюють зміщення, які важко побачити в короткому тесті. Потрібно вимірювати реальні маршрути й резервувати простір до появи даних.

CLS і бізнес

Нестабільний інтерфейс збільшує помилкові кліки, дратує користувачів і підриває довіру. Для checkout, бронювання чи фінансової форми це може мати прямі наслідки. Тому CLS важливий не лише як технічний SEO-показник, а як контроль якості інтерфейсу.

Типові помилки

• перевіряти лише початкове завантаження;
• ігнорувати cookie banner і рекламні слоти;
• виправляти shift приховуванням важливого контенту;
• плутати анімацію з layout shift;
• не тестувати різні ширини й мови;
• оцінювати лише середній CLS;
• не знаходити конкретний unstable element.

Професорська та директорська перевірка

CLS вимірює геометричну нестабільність, але не всю якість візуального досвіду. Для директора показник особливо корисний як guardrail: інтерфейс не повинен маніпулювати або змушувати користувача помилятися через пізню зміну layout.

Пов’язані поняття

Core Web Vitals · LCP · INP · Layout shift · CrUX · Responsive design · RUM · Page experience

Висновок

CLS показує, наскільки стабільним залишається інтерфейс під час реального використання. Найкраща профілактика — заздалегідь резервувати простір і проєктувати асинхронний контент так, щоб він не відсував уже видимі елементи.

Джерело

web.dev: Optimize Cumulative Layout Shift