Ми використовуємо cookie-файли, щоб покращити ваш досвід, аналізувати трафік сайту та персоналізувати вміст. Ви можете прийняти всі cookie або обрати, які категорії дозволити. Дізнатися більше
Основні веб-показники для електронної комерції 2026: виправлення LCP, INP, CLS | Ordiko
Посібник
Основні веб-показники для електронної комерції 2026: виправлення LCP, INP, CLS
Практичний посібник 2026 року з основних веб-показників для електронної комерції — пороги LCP/INP/CLS, причини в реальному світі та виправлення, які впливають на PDP та PLP.
PT1H
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с
Джерело: . INP замінив FID як основний веб-показник у березні 2024 року і залишається показником на 2026 рік.
Поширені запитання
Чи впливають основні веб-показники на ранжування?
Так, з 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 та межами Suspense для динамічного контенту. За замовчуванням INP становить менше 200 мс на типовому PDP без спеціальної оптимізації.
Google використовує CWV як сигнал про досвід користувача на сторінці при ранжуванні. Дані реальних користувачів показують, що сторінки з усіма зеленими CWV перевершують порівнянні сторінки з поганими CWV у конкурентних нішах.
Окрім ранжування, CWV безпосередньо впливає на конверсію. Дослідження 2024–2025 років постійно показують:
Поліпшення LCP на 1 секунду: 5–15% підвищення конверсії на PDP.
INP менше 200мс: 10–20% зменшення покинутих кошиків.
CLS менше 0.1: помітне підвищення сприйняття якості UX.
Вимірювання правильним способом
Джерела даних, які мають значення:
CrUX (Звіт про досвід користувачів Chrome): дані реальних користувачів, які Google використовує для ранжування. 28-денний період, p75. Відображається в PageSpeed Insights та Search Console.
Ваш власний RUM: дані реальних користувачів, які ви збираєте за допомогою бібліотеки web-vitals або вашого CDN. Показує свіжіші дані, дозволяє розрізати за типом сторінки, пристроєм, країною.
Синтетичні інструменти (Lighthouse, WebPageTest) корисні для діагностики, але не для оцінювання.
Виправлення LCP (найбільша контентна частина)
На сайтах електронної комерції LCP майже завжди:
Героїчне зображення на домашній, PLP та PDP.
H1 + перший абзац на блогових/статейних сторінках.
Великі виграші:
Попереднє завантаження зображення LCP з <link rel="preload" as="image" fetchpriority="high">:
Витягніть літерали regex з обробників подій — повторне створення regex у гарячому шляху коштує вимірювального INP.
Відкладіть не критичні сторонні скрипти. Маркетингові пікселі, віджети чату, SDK для A/B тестування: завантажуйте їх з strategy="afterInteractive" або lazyOnload.
Виправлення CLS (кумулятивний зсув макета)
Великі виграші:
Завжди встановлюйте ширину/висоту для зображень. Браузери резервують правильний простір.
Резервуйте місце для вбудованого контенту. iframes, реклама, відеоплеєри потребують явних розмірів або контейнерів з аспектним співвідношенням.
Уникайте `font-display: swap` без CSS для запасного шрифту. Заміна переплановує текст. Використовуйте size-adjust, щоб відповідати метрикам або прийміть font-display: optional.
Не вставляйте контент вище існуючого контенту. Сповіщення банерів, згода на використання файлів cookie, банери розпродажу — рендерте їх у позиції, яка не зсуває сторінку.
Скелетні завантажувачі повинні відповідати реальним розмірам контенту. Скелет, який менший за завантажений контент, зсуває сторінку.
Примітки, специфічні для типу сторінки
Головна сторінка
Героїчне зображення є 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)
Дані в реальному часі, розрізані за сторінкою, пристроєм, країною
Чи впливають основні веб-показники на ранжування? Так, з 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 без спеціальної оптимізації.