Оптимізація CLS (Cumulative Layout Shift) — усуваємо зміщення елементів

Оптимізація CLS (Cumulative Layout Shift)

Уявіть: користувач наводить курсор на кнопку «Купити», а в цей момент підвантажується рекламний банер — кнопка їде вниз, клік іде впусту. Це і є Cumulative Layout Shift (CLS). За даними Google, сайти з CLS вище 0,25 втрачають до 15% конверсії. Для інтернет-магазину з місячним обігом 10 млн грн це прямий збиток 1,5 млн. Наша команда — інженери з 10+ річним досвідом, які виконали понад 200 проєктів з оптимізації Core Web Vitals. Ми оцінюємо проєкт за один день і надаємо гарантію результату — CLS ≤ 0,1.

Чому CLS важливий для бізнесу?

Згідно з дослідженнями Google, сайти з високим CLS втрачають до 15% конверсії. Середнє значення CLS за даними CrUX для топ-1000 сайтів — 0,15, а клієнти з CLS > 0,25 мають показник відмов на 32% вище. Користувачі дратуються, коли контент стрибає, особливо на мобільних пристроях з повільним з'єднанням. Для e-commerce, новинних порталів та SPA це критично: кожен міліметр зміщення — втрачений клієнт. Інвестиція в оптимізацію CLS окупається за 2-3 місяці за рахунок зростання конверсії та зниження відмов.

Як ми оптимізуємо CLS?

Процес складається з чотирьох етапів: аудит → виправлення типових проблем → тестування → звіт. На аудиті ми використовуємо Chrome DevTools, Lighthouse та PerformanceObserver для збору точних метрик, потім ранжуємо проблеми за впливом на CLS. Першими виправляємо зображення — це 80% зміщень, потім шрифти та динамічний контент. Нижче — повний чек-лист.

Зображення — найчастіша причина

<!-- Погано: браузер не знає розмір до завантаження -->
<img src="product.webp" alt="...">

<!-- Добре: атрибути width і height -->
<img src="product.webp" width="800" height="600" alt="...">

CSS для адаптивності зі збереженням співвідношення:

img {
    max-width: 100%;
    height: auto;
}

.product-image {
    aspect-ratio: 4 / 3;
    width: 100%;
    object-fit: cover;
}

Шрифти та FOUT

Font Swap викликає зміщення, коли основний шрифт завантажується і змінює fallback. Використовуйте font-display: optional або підберіть size-adjust:

@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter.woff2') format('woff2');
    font-display: optional;
}

@font-face {
    font-family: 'InterFallback';
    src: local('Arial');
    size-adjust: 107%;
    ascent-override: 90%;
    descent-override: 22%;
    line-gap-override: 0%;
}

body {
    font-family: 'Inter', 'InterFallback', sans-serif;
}

Інструмент fontaine або next/font автоматично підбирає size-adjust. Порівняння значень font-display:

Динамічний контент та скелетони

Для рекламних блоків та віджетів фіксуйте мінімальну висоту і використовуйте contain: layout. Не залишайте місце порожнім — показуйте skeleton placeholder з правильними розмірами:

.skeleton-image, .skeleton-title, .skeleton-price {
    background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
    background-size: 200% 100%;
    animation: shimmer 1.5s infinite;
    border-radius: 4px;
}

@keyframes shimmer {
    0% { background-position: 200% 0; }
    100% { background-position: -200% 0; }
}

Чому transform/opacity кращі за layout-анімації?

Анімації, що змінюють layout-властивості (width, height, top, left, margin, padding), викликають перерахунок геометрії та reflow — це прямий шлях до CLS. Властивості transform та opacity не зачіпають layout, тому абсолютно безпечні. Заміна layout-анімацій на transform/opacity знижує CLS у 5–10 разів. Приклад:

/* Добре — тільки transform */
.modal { animation: slideDown 300ms; }
@keyframes slideDown {
    from { transform: translateY(-100%); opacity: 0; }
    to   { transform: translateY(0);    opacity: 1; }
}

Для ізольованих компонентів використовуйте contain: layout — це запобігає впливу внутрішніх змін на зовнішній layout.

Як діагностувати CLS?

Для виявлення проблем використовуйте Chrome DevTools: вкладка Performance → запис → знайдіть позначки «Layout Shift» (фіолетові). Або встановіть PerformanceObserver у коді: new PerformanceObserver(...). Це дозволить відстежувати зміщення в реальному часі.

Що входить у роботу

• Аналіз усіх сторінок (Core Web Vitals, N+1 query, bundle splitting).
• Виправлення зображень (width, height, aspect-ratio, lazy loading з розміром).
• Заміна font-display: swap на optional + size-adjust.
• Фіксація розмірів рекламних блоків та динамічних віджетів.
• Заміна layout-анімацій на transform/opacity.
• Додавання скелетонів з shimmer-ефектом.
• Звіт з метриками до/після (Lighthouse, CrUX).

Типові помилки при оптимізації

Часто розробники задають width/height у відсотках без aspect-ratio — браузер не може обчислити висоту до завантаження. Правильне рішення: комбінувати width: 100% з aspect-ratio або задавати фіксовану висоту через padding-bottom. Ще одна часта помилка — використання font-display: swap без size-adjust: fallback-шрифт може бути вужчим або ширшим за основний, викликаючи зміщення.

Джерело: web.dev/cls — офіційна документація Google

Термін оптимізації: 1–3 дні для базового набору, до 5 днів при комплексному аудиті. Ми сертифіковані Google з Core Web Vitals — гарантуємо покращення метрик та підвищення конверсії. Замовте консультацію та отримайте попередню оцінку безкоштовно. Отримайте оцінку проєкту за один день — зв'яжіться з нами, і ми проведемо аудит.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.