**TL;DR.** Основні веб-показники у 2026 році: LCP ≤ 2.5с, INP ≤ 200мс, CLS ≤ 0.1 на p75. На сайтах електронної комерції LCP фіксується за допомогою попереднього завантаження героїчного зображення, INP — відкладення JS та використання функцій React 18+ для паралельного виконання, а CLS — за рахунок резервування місця для зображень та динамічних регіонів. Google оцінює на p75 протягом 28-денного періоду; виправлення потребують тижнів, щоб відобразитися.

## Пороги 2026 року

| Показник | Добре  | Потребує покращення | Погано   |
| -------- | ------ | ------------------- | -------- |
| LCP      | ≤ 2.5с | 2.5с – 4.0с         | > 4.0с   |
| INP      | ≤ 200мс| 200мс – 500мс       | > 500мс  |
| CLS      | ≤ 0.1  | 0.1 – 0.25          | > 0.25   |
| TTFB     | ≤ 800мс| 800мс – 1.8с        | > 1.8с   |

Джерело: [web.dev/vitals](https://web.dev/articles/vitals). INP замінив FID як основний веб-показник у березні 2024 року і залишається показником на 2026 рік.

## Чому важливі CWV

Google використовує CWV як сигнал про досвід користувача на сторінці при ранжуванні. Дані реальних користувачів показують, що сторінки з усіма зеленими CWV перевершують порівнянні сторінки з поганими CWV у конкурентних нішах.

Окрім ранжування, CWV безпосередньо впливає на конверсію. Дослідження 2024–2025 років постійно показують:

- Поліпшення LCP на 1 секунду: 5–15% підвищення конверсії на PDP.
- INP менше 200мс: 10–20% зменшення покинутих кошиків.
- CLS менше 0.1: помітне підвищення сприйняття якості UX.

## Вимірювання правильним способом

Джерела даних, які мають значення:

1. **CrUX (Звіт про досвід користувачів Chrome)**: дані реальних користувачів, які Google використовує для ранжування. 28-денний період, p75. Відображається в PageSpeed Insights та Search Console.
2. **Ваш власний RUM**: дані реальних користувачів, які ви збираєте за допомогою бібліотеки `web-vitals` або вашого CDN. Показує свіжіші дані, дозволяє розрізати за типом сторінки, пристроєм, країною.

Синтетичні інструменти (Lighthouse, WebPageTest) корисні для діагностики, але не для оцінювання.

## Виправлення LCP (найбільша контентна частина)

На сайтах електронної комерції LCP майже завжди:

- Героїчне зображення на домашній, PLP та PDP.
- H1 + перший абзац на блогових/статейних сторінках.

Великі виграші:

1. **Попереднє завантаження зображення LCP** з `<link rel="preload" as="image" fetchpriority="high">`:

```html
<link rel="preload" as="image" href="/products/leather-bag/hero.avif" fetchpriority="high" imagesrcset="/products/leather-bag/hero-400.avif 400w, /products/leather-bag/hero-800.avif 800w" imagesizes="(max-width: 768px) 100vw, 50vw" />
```

2. **Використовуйте Next.js `<Image>` з `priority`** на зображенні LCP:

```tsx
<Image
  src={product.heroImage}
  width={800}
  height={800}
  priority
  fetchPriority="high"
  alt={product.altText}
/>
```

3. **Використовуйте сучасні формати**. AVIF перевершує WebP, WebP перевершує JPEG. Next.js Image обробляє це автоматично.

4. **Не завантажуйте зображення LCP з затримкою**. `loading="lazy"` призначено лише для зображень нижче за межами видимості.

5. **Включіть критичний CSS для стилів над межами видимості**. Уникайте блокування завантаження таблиць стилів на критичному шляху рендерингу.

6. **Використовуйте рендеринг на краю**. TTFB ≤ 100мс з кешу на краю забезпечує більшість бюджету LCP.

## Виправлення INP (взаємодія з наступним малюнком)

INP вимірює найгірший випадок серед усіх взаємодій на сторінці. Один повільний клік фільтра може зіпсувати ваш INP на всю сесію.

Великі виграші:

1. **Зменште JS на стороні клієнта**. Використовуйте компоненти сервера React, де це можливо. Кожен кілобайт клієнтського JS шкодить INP.

2. **Використовуйте `startTransition` для не термінових оновлень стану**:

```tsx
import { startTransition, useState } from 'react';

function FilterButton({ filter }) {
  const [isPending, startTransition] = useTransition();
  return (
    <button onClick={() => startTransition(() => applyFilter(filter))}>
      {filter.label}
    </button>
  );
}
```

3. **Використовуйте `useOptimistic` для миттєвого зворотного зв'язку**:

```tsx
import { useOptimistic } from 'react';

function Cart() {
  const [cart, addOptimistic] = useOptimistic(serverCart);
  return (
    <button onClick={() => {
      addOptimistic({ ...newItem });
      addToCartServerAction(newItem);
    }}>Додати до кошика</button>
  );
}
```

4. **Дебонуйте введення**. Автозаповнення пошуку повинно мати затримку 150–250мс з `AbortController`, щоб скасувати запити, що виконуються:

```tsx
useEffect(() => {
  const controller = new AbortController();
  const timeout = setTimeout(() => {
    fetch(`/api/search?q=${query}`, { signal: controller.signal });
  }, 200);
  return () => {
    clearTimeout(timeout);
    controller.abort();
  };
}, [query]);
```

5. **Витягніть літерали regex з обробників подій** — повторне створення regex у гарячому шляху коштує вимірювального INP.

6. **Відкладіть не критичні сторонні скрипти**. Маркетингові пікселі, віджети чату, SDK для A/B тестування: завантажуйте їх з `strategy="afterInteractive"` або `lazyOnload`.

## Виправлення CLS (кумулятивний зсув макета)

Великі виграші:

1. **Завжди встановлюйте ширину/висоту для зображень**. Браузери резервують правильний простір.

```html
<img src="/hero.avif" width="800" height="800" alt="..." />
```

2. **Резервуйте місце для вбудованого контенту**. iframes, реклама, відеоплеєри потребують явних розмірів або контейнерів з аспектним співвідношенням.

3. **Уникайте `font-display: swap` без CSS для запасного шрифту**. Заміна переплановує текст. Використовуйте [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust), щоб відповідати метрикам або прийміть `font-display: optional`.

4. **Не вставляйте контент вище існуючого контенту**. Сповіщення банерів, згода на використання файлів cookie, банери розпродажу — рендерте їх у позиції, яка не зсуває сторінку.

5. **Скелетні завантажувачі повинні відповідати реальним розмірам контенту**. Скелет, який менший за завантажений контент, зсуває сторінку.

## Примітки, специфічні для типу сторінки

**Головна сторінка**

- Героїчне зображення є LCP. Попередьте його.
- Каруселі є мінними полями CLS. Використовуйте лише CSS або попередньо рендерте перший слайд.

**PLP (список продуктів / категорія)**

- LCP зазвичай є зображенням першої картки продукту.
- INP — це кліки фільтра та пагінація. Використовуйте `startTransition` агресивно.
- CLS — це повторне планування сітки продуктів, коли застосовуються фільтри. Резервуйте висоту сітки.

**PDP**

- LCP — це основне зображення продукту.
- INP — це зміна варіантів та додавання до кошика. Оптимістичний UI є обов'язковим.
- CLS — це мініатюри галереї продуктів, які завантажуються після основного зображення.

**Кошик / Оформлення замовлення**

- INP тут критично важливий. Повільна кнопка "оформити замовлення" коштує замовлень.
- CLS від завантаження платіжних iframes (Stripe Elements тощо). Резервуйте місце.

## Інструменти

| Інструмент                 | Для чого він корисний                                     |
| -------------------------- | -------------------------------------------------------- |
| PageSpeed Insights         | Діагностика одного URL з накладкою реальних користувачів (CrUX) |
| Lighthouse                 | Синтетичне вимірювання для робочих процесів розробників   |
| WebPageTest                | Вимірювання з обмеженням мережі, з кількох локацій       |
| Search Console → CWV        | Рівень домену p75 за 28 днів                            |
| Ваш власний RUM (web-vitals)  | Дані в реальному часі, розрізані за сторінкою, пристроєм, країною |

## Як Ordiko обробляє CWV за замовчуванням

Стек магазину Ordiko:

- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- Рендеринг на краю статичних оболонок (TTFB ≤ 100мс).
- Зображення LCP попередньо завантажується за замовчуванням на PDP, PLP, домашній сторінці.
- Межі затримки навколо динамічних островів (кошик, нещодавно переглянуті, персоналізований герой).
- `startTransition` + `useOptimistic` на фільтрах та елементах варіантів.
- 200мс дебонованого пошуку з `AbortController`.

Типовий реальний p75 на стандартному Ordiko PDP: LCP 1.0–1.8с, INP 80–160мс, CLS < 0.05.

## Питання та відповіді

**Чи впливають основні веб-показники на ранжування?**
Так, з 2021 року — але як роздільник, а не як основний сигнал. Дві сторінки з однаковою якістю контенту будуть ранжуватися в порядку CWV. Виправлення CWV на погано ранжованій сторінці не зробить її раптом високою, якщо контент слабкий.

**Чому INP важче виправити, ніж LCP?**
LCP в основному є проблемою CDN та оптимізації зображень з добре зрозумілими виправленнями. INP є проблемою виконання JavaScript, яка вимагає аналізу компонента за компонентом. Кожна подія взаємодії може мати різне вузьке місце (клік фільтра проти додавання до кошика проти зміни варіанту).

**Яка хороша мета INP для PDP?**
Менше 200мс p75 є "добрим". Менше 100мс досяжно на сучасних PDP з дисципліною (RSC, без важких сторонніх скриптів, дебоновані введення). Більше 500мс є "поганим" і, ймовірно, вплине на ранжування.

**Як Ordiko обробляє CWV за замовчуванням?**
Ordiko постачає Next.js 16 Cache Components + PPR, який транслює статичну оболонку з уже попередньо завантаженим зображенням LCP та межами затримки для динамічного контенту. За замовчуванням INP залишається нижче 200мс на типовому PDP без спеціальної оптимізації.