Оптимизация INP и FID: достигаем ≤200 мс для Core Web Vitals

INP стал критической метрикой Core Web Vitals — с марта 2024 он заменяет FID и учитывает все взаимодействия пользователя. Плохой INP (более 200 мс) напрямую снижает конверсию: каждая 100 мс задержки при вводе в поиск или клике на кнопку уводит 1–2% посетителей. Мы помогаем клиентам достичь значения ≤200 мс и подтверждаем результат инструментальным мониторингом за счёт комбинации разбивки Long Tasks, асинхронной фильтрации и выноса тяжёлых вычислений в Web Workers.

Как работает INP

INP = время от действия пользователя (mousedown, keydown, pointerdown) до следующей отрисовки фрейма браузером. Задержка складывается из трёх фаз: input delay — ожидание, пока main thread освободится; processing time — выполнение обработчиков событий; presentation delay — layout, paint, composite. Типичная ситуация: пользователь кликает кнопку фильтрации, но main thread занят парсингом аналитического скрипта — клик ждёт 120 мс, затем обработчик выполняется 80 мс, ещё 50 мс на отрисовку — итого 250 мс, что уже за пределами нормы.

Почему INP критичен для SEO?

Google сделал INP одним из трёх ключевых сигналов ранжирования. Сайты с INP > 200 мс теряют позиции в выдаче и получают меньше органического трафика. Для интернет-магазинов каждая миллисекунда задержки снижает конверсию на 1–2%. В одном из проектов после снижения INP с 350 мс до 80 мс конверсия выросла на 12%, а средняя глубина просмотра увеличилась на 2 страницы.

Диагностика медленных взаимодействий

Используйте PerformanceObserver для сбора всех взаимодействий с задержкой >16 мс:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 200) {
      console.warn(`Slow interaction: ${entry.name}`, {
        duration: entry.duration,
        processingStart: entry.processingStart,
        processingEnd: entry.processingEnd,
        inputDelay: entry.processingStart - entry.startTime,
        processingTime: entry.processingEnd - entry.processingStart,
        presentationDelay: entry.startTime + entry.duration - entry.processingEnd,
      });
    }
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 16 });

Chrome DevTools → Performance → запись страницы → фильтр Long Tasks. Любая задача > 50 мс — кандидат на оптимизацию. В реальной сессии мы часто видим Long Tasks от 100 до 500 мс, создаваемые сторонними скриптами или тяжёлыми вычислениями на основном потоке.

Устранение Long Tasks: два подхода

Разбивка через yield подходит для лёгких вычислений. Web Worker лучше для CPU-интенсивных задач, так как полностью освобождает main thread. Пример из практики: в интернет-магазине фильтрация по 20 000 товаров в реальном времени давала INP 350 мс. Мы вынесли фильтрацию в Web Worker и добавили виртуализацию списка — INP упал до 80 мс.

// Async filter с yield каждые 50 элементов
async function filterProductsAsync(products, filters) {
  const results = [];
  for (let i = 0; i < products.length; i++) {
    if (matchesFilters(products[i], filters)) {
      results.push(products[i]);
    }
    if (i % 50 === 0 && i > 0) {
      await scheduler.yield(); // Chrome 115+
      // fallback: await new Promise(r => setTimeout(r, 0));
    }
  }
  return results;
}

// Web Worker – вынос тяжёлой фильтрации
// worker.js
self.onmessage = function({ data: { products, filters } }) {
  const results = products.filter(p => matchesFilters(p, filters));
  self.postMessage(results);
};

// main.js
const worker = new Worker('/js/filter-worker.js');
worker.postMessage({ products, filters });
worker.onmessage = ({ data }) => setFilteredProducts(data);

Оптимизация React-компонентов

Проблема: синхронная фильтрация на каждый keystroke блокирует main thread. Решение — useTransition и виртуализация. Вот как выглядит компонент поиска с мгновенным откликом:

function ProductList() {
  const [query, setQuery] = useState('');
  const [deferredQuery, setDeferredQuery] = useState('');

  const filtered = useMemo(
    () => products.filter(p => p.name.toLowerCase().includes(deferredQuery.toLowerCase())),
    [deferredQuery]
  );

  function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    const value = e.target.value;
    setQuery(value); // срочно — поле отзывается мгновенно
    startTransition(() => {
      setDeferredQuery(value); // некритично — список обновится позже
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      <ul>
        {filtered.map(p => <ProductItem key={p.id} product={p} />)}
      </ul>
    </>
  );
}

Для длинных списков используйте виртуализацию:

import { useVirtualizer } from '@tanstack/react-virtual';

function VirtualProductList({ products }: { products: Product[] }) {
  const parentRef = useRef<HTMLDivElement>(null);
  const rowVirtualizer = useVirtualizer({
    count: products.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 80,
    overscan: 5,
  });

  return (
    <div ref={parentRef} style={{ height: '600px', overflow: 'auto' }}>
      <div style={{ height: rowVirtualizer.getTotalSize() }}>
        {rowVirtualizer.getVirtualItems().map(virtualRow => (
          <div
            key={virtualRow.index}
            style={{
              transform: `translateY(${virtualRow.start}px)`,
              position: 'absolute',
              width: '100%',
            }}
          >
            <ProductItem product={products[virtualRow.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

Third-party скрипты: скрытая угроза

Чаты, пиксели, аналитика — частая причина плохого INP. Они выполняются в main thread и блокируют взаимодействия. Решения:

• Загрузка после основного контента (setTimeout 3s после load).
• Использование Partytown для запуска скриптов в Web Worker.

Типичные ошибки при оптимизации INP

• Оптимизация только одного взаимодействия, тогда как INP берёт наихудшее.
• Игнорирование presentation delay — иногда paint занимает больше времени, чем обработчик.
• Использование setTimeout(0) вместо scheduler.yield() — первый не освобождает поток гарантированно.
• Забывают про мобильные устройства: на слабых процессорах Long Tasks возникают чаще.

Как измерить INP в реальном времени?

Настройте Real User Monitoring (RUM) с отправкой метрик в аналитику. Используйте navigator.webdriver для фильтрации ботов. Пример: собирайте все взаимодействия с INP > 200 мс в performanceEntries и отправляйте на бэкенд для анализа. Это позволит выявить проблемные страницы и устройства.

Целевые показатели INP

Процесс оптимизации INP

1. Диагностика — сбор реальных метрик через RUM и лабораторные тесты.
2. Анализ — определение топ-5 проблемных взаимодействий с точными значениями задержек.
3. Реализация — применение техник (yield, Workers, lazy loading, виртуализация).
4. Тестирование — A/B-эксперименты, проверка влияния на конверсию и SEO-трафик.
5. Мониторинг — настройка постоянного контроля INP с алертами при превышении 200 мс.

Сроки ориентировочно

От 3 до 7 дней — в зависимости от числа проблемных взаимодействий и сложности архитектуры. Стоимость рассчитывается индивидуально после аудита.

Более 50 успешных оптимизаций INP. Гарантируем достижение ≤200 мс или возвращаем деньги. Свяжитесь с нами для аудита и получите план оптимизации за 3 дня. Закажите консультацию — разберём ваш случай.

MDN: INP