Мы используем cookie-файлы, чтобы улучшить ваш опыт, анализировать трафик и персонализировать контент. Вы можете принять все cookie или выбрать, какие категории разрешить. Подробнее
Оптимизация INP для страниц деталей продукта (PDP) в 2026 году | Ordiko
Руководство
Оптимизация INP для страниц деталей продукта (PDP) в 2026 году
Сфокусированное руководство по исправлению времени взаимодействия до следующей отрисовки (INP) на страницах PDP в 2026 году, охватывающее смену вариантов, галерею, добавление в корзину и шаблоны компонентов сервера React, которые постоянно снижают INP ниже 200 мс.
PT1H30M
Кратко. INP на PDP исправляется за счет уменьшения объема JavaScript и оптимистичных взаимодействий. Используйте React Server Components для статических частей. Используйте useOptimistic для смены варианта и добавления в корзину. Используйте startTransition для не срочных обновлений. Дебаунс поиска с помощью AbortController. Перенесите регулярные выражения и избегайте оператора spread в обработчиках событий. Цель: < 200ms p75, достижимо < 100ms.
Что измеряет INP
Время взаимодействия до следующей отрисовки (INP) измеряет самое долгое время от взаимодействия до отрисовки на странице во время визита пользователя. "Взаимодействие" — это клик, нажатие или нажатие клавиши, которое запускает JavaScript.
INP рассчитывается как худший случай (исключая редкие выбросы), а не среднее значение. Один медленный клик фильтра может испортить ваш INP, даже если 99 других взаимодействий были быстрыми.
Значение INP
Вердикт
≤ 200ms
Хорошо
200ms – 500ms
Требует улучшения
> 500ms
Плохо
Частые вопросы
Почему INP гораздо сложнее, чем LCP?
LCP в основном является проблемой CDN и оптимизации изображений с хорошо понятными решениями. INP — это время выполнения JavaScript при взаимодействии пользователя; каждое нажатие может иметь разные узкие места. Исправление INP требует дисциплины на уровне компонентов для каждого интерактивного элемента на странице.
Исправляет ли React Server Components INP автоматически?
В основном да. RSC уменьшает объем JS-бандла, отправляемого в браузер, что снижает работу основного потока, что улучшает INP. Но интерактивные части страницы все еще нуждаются в клиентском JS — только RSC не исправит плохо написанный клиентский компонент, который создает regex в onClick.
Какой самый большой убийца INP на PDP?
Тяжелая клиентская отрисовка виджетов рекомендаций ('Часто покупают вместе', 'Вам также может понравиться'), которые отправляют 50–200 КБ JS и агрессивно гидратируются при первом взаимодействии. Переместите их в серверные компоненты или загружайте лениво за IntersectionObserver.
Как быстро может работать хорошо оптимизированный PDP по INP?
В реальном мире p75 INP ниже 100 мс достижимо. PDP Ordiko по умолчанию имеют 80–160 мс p75 INP без ручной оптимизации. Пользовательские темы, следующие шаблонам в этом руководстве, могут стабильно достигать менее 100 мс.
Похожие материалы
Шаг 1: Профилируйте, не догадывайтесь
Используйте вкладку Performance в Chrome DevTools, чтобы записать сессию взаимодействия с PDP. Обратите внимание на:
Долгие задачи (желтые полосы > 50ms) во время взаимодействий.
Принудительные переработки (пурпурные полосы).
Большую атрибуцию для записей INP.
Или используйте API Long Animation Frames (LoAF) в вашем RUM:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 200) {
console.log('Долгая рамка:', entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Шаг 2: Откладывайте некритичный JS
Наибольшие выигрыши INP на большинстве PDP приходят от удаления или откладывания скриптов, которые не нужно загружать немедленно:
Тип скрипта
Рекомендуемая стратегия
Аналитика (GA4, Plausible)
afterInteractive
Маркетинговые пиксели
afterInteractive или lazyOnload
Чат-виджет
lazyOnload + IntersectionObserver
SDK A/B тестирования
Встраиваемый блокирующий (редко) или beforeInteractive
Только AddToCartButton и VariantSelector являются клиентскими компонентами. Все остальное остается на сервере. Размер пакета уменьшается на 60–80% по сравнению с полностью клиентским PDP.
Шаг 7: Перенос регулярных выражений и избегание spread
Плохо:
function handleClick(text) {
if (/[<>]/.test(text)) { ... } // регулярное выражение создается при каждом клике
setItems(prev => [...prev, ...newItems]); // spread в аккумуляторе
}
Хорошо:
const TAG_REGEX = /[<>]/; // перенесено в область модуля
function handleClick(text) {
if (TAG_REGEX.test(text)) { ... }
setItems(prev => prev.concat(newItems));
}
Шаг 8: Ленивый загрузка ниже сгиба
Рекомендации, отзывы, связанные продукты: разместите их ниже сгиба и загружайте лениво с помощью dynamic + ssr: false для чисто клиентских виджетов или загружайте при пересечении:
Для серверных секций оберните в <Suspense> с включенным PPR, чтобы они стримились после статической оболочки.
Измерение успеха
После развертывания исправлений улучшения INP отображаются в:
Chrome DevTools в разделе Performance → Web Vitals overlay (синтетические, немедленные).
Вашем собственном RUM с библиотекой web-vitals (реальные пользователи, почти в реальном времени).
Search Console → Core Web Vitals (реальные пользователи, p75 за 28 дней, задержка 2–4 недели).
Типичный PDP, который начинался с 350ms p75 INP и следует этому руководству, достигает 80–120ms p75 INP в течение 2–4 недель после развертывания.
Как Ordiko по умолчанию поставляет PDP с хорошим INP
Статические части PDP являются RSC (без клиентского JS).
Выбор варианта использует useOptimistic + серверные действия.
Галерея использует startTransition + предварительную загрузку изображений при наведении.
Поиск дебаунсится на 200ms с помощью AbortController.
Корзина отображает последний известный счет оптимистично.
Стандартный p75 INP: 80–160ms.
Часто задаваемые вопросы
Почему INP так намного сложнее, чем LCP? LCP в основном является проблемой CDN и оптимизации изображений с хорошо понятными решениями. INP — это время выполнения JavaScript при взаимодействии пользователя; каждый клик может иметь разные узкие места. Исправление INP требует дисциплины на уровне компонентов для каждого интерактивного элемента на странице.
Исправляет ли React Server Components INP автоматически? В значительной степени да. RSC уменьшает объем JS, отправляемого в браузер, что снижает нагрузку на главный поток, что улучшает INP. Но интерактивные части страницы все еще нуждаются в клиентском JS — RSC сама по себе не исправит плохо написанный клиентский компонент, который создает регулярные выражения в onClick.
Какой самый большой убийца INP на PDP? Сильная рендеринг клиентских виджетов рекомендаций ('Часто покупают вместе', 'Вам также может понравиться'), которые отправляют 50–200KB JS и агрессивно гидратируются при первом взаимодействии. Переместите их в серверные компоненты или лениво загружайте за IntersectionObserver.
Как быстро может оптимизированный PDP достичь INP? В реальном мире p75 INP ниже 100ms достижимо. PDP Ordiko по умолчанию имеют 80–160ms p75 INP без ручной оптимизации. Пользовательские темы, которые следуют шаблонам в этом руководстве, могут стабильно достигать ниже 100ms.