Как оптимизировать Core Web Vitals на мобильных устройствах и снизить INP?

Чтобы снизить INP на мобильных устройствах, важно не просто ускорить загрузку страницы, а обеспечить как можно более быстрое отображение следующего кадра после нажатия, касания или ввода с клавиатуры. Сжатие изображений и подключение CDN улучшают загрузку, но сами по себе не решают проблему задержки отклика после нажатия кнопки. Если главный поток занят выполнением скриптов или отрисовкой страницы, взаимодействие по-прежнему будет тормозить.

Чтобы понять, как оптимизировать Core Web Vitals для улучшения мобильного взаимодействия, нужно разделить INP на задержку ввода, длительность обработки события и задержку отображения, а затем устранить причины затрат времени на каждом этапе. Одного лишь сокращения времени выполнения обработчика нажатия или повышения результата разового лабораторного теста недостаточно, чтобы доказать улучшение отзывчивости для реальных пользователей.

INP измеряет время от взаимодействия до следующего кадра, а не время выполнения бизнес-операции

INP, то есть время от взаимодействия до следующей отрисовки, учитывает соответствующие критериям нажатия, касания и взаимодействия с клавиатурой на протяжении жизненного цикла страницы и отражает отзывчивость, близкую к отзывчивости при самом медленном взаимодействии. Если взаимодействий много, при расчёте по правилам исключается небольшое количество экстремальных значений, поэтому INP нельзя просто считать средним временем всех нажатий или абсолютным максимумом.

В оценке Google Core Web Vitals значение INP до 200 мс включительно считается «хорошим», более 200 и до 500 мс включительно — «требующим улучшения», а свыше 500 мс — «плохим». Соответствие сайта требованиям оценивается по 75-му процентилю данных реальных посещений отдельно для мобильных устройств и компьютеров. Это отличается от выбора репрезентативного взаимодействия в рамках одного посещения страницы: речь идёт о двух разных уровнях статистики.

INP — это не время отклика API. После отправки запроса на консультацию страница может сразу отобразить состояние «Отправка», а сетевой запрос завершится позже; при этом INP взаимодействия может быть низким. Но низкий INP не означает, что бизнес-операция завершилась успешно: время выполнения запроса, частоту ошибок и повторные отправки всё равно нужно отслеживать отдельно.

Сначала определите, какой этап занимает больше времени, а затем решайте, что менять

Задержка ввода при взаимодействии — это время ожидания от действия пользователя до начала выполнения обработчика события; длительность обработки — время выполнения соответствующих обработчиков; задержка отображения — время от завершения обработчика до отображения следующего кадра. Каждый из этих этапов может стать узким местом на мобильном устройстве.

Если в момент нажатия пользователя главный поток занят разбором скриптов, выполнением стороннего кода или другими задачами, увеличивается задержка ввода. Если обработчик синхронно фильтрует большое количество товаров, проверяет всю форму или обновляет множество компонентов, увеличивается длительность обработки. Если после завершения обработчика требуется пересчитать стили для большой области, выполнить компоновку и отрисовку, возрастает задержка отображения.

В Chrome DevTools можно записать на панели производительности такие действия, как раскрытие меню, фильтрация товаров, переключение характеристик и отправка запроса на консультацию, а затем проверить задачи главного потока и активность рендеринга вдоль трассы взаимодействия. Задачи длительностью более 50 мс считаются длинными, но это лишь подсказка при диагностике: несколько коротких задач подряд тоже могут задерживать отрисовку. Отсутствие длинных задач не доказывает, что INP соответствует требованиям.

Важнее устранять блокировки, а не просто откладывать скрипты

Если задержка ввода велика, проверьте, не начинают ли скрипты интенсивно выполняться после того, как пользователь приступает к взаимодействию. На маркетинговых сайтах стоит по отдельности проверить онлайн-консультантов, теги аналитики, рекламные трекеры и всплывающие окна, оценив время загрузки и затраты на выполнение. Атрибуты async и defer меняют время загрузки и выполнения скриптов, но не устраняют нагрузку на главный поток во время их работы.

Ненужные скрипты можно загружать с учётом назначения страницы, состояния согласия пользователя или фактических потребностей, а дублирующиеся теги — удалять. При отложенной загрузке важно не запускать все скрипты одновременно при первом нажатии: так затраты на загрузку лишь переносятся на путь взаимодействия.

Синхронные вычисления следует выполнять порциями, между которыми нужно освобождать главный поток. В браузерах с поддержкой можно использовать scheduler.yield(); в остальных средах потребуется альтернативное решение. Разбиение работы только с помощью Promise или queueMicrotask ненадёжно: очередь микрозадач всё ещё может выполняться непрерывно до отрисовки. Вычисления, интенсивно использующие CPU и не зависящие от DOM, можно перенести в Web Worker, но при этом нужно учитывать затраты на обмен данными и их копирование.

Сокращайте объём работы и в обработчиках событий, и при рендеринге

Обработчик нажатия должен в первую очередь выполнять необходимые изменения состояния, например показывать индикатор загрузки, отмечать текущий вариант или блокировать повторную отправку, а затем планировать выполнение несрочных задач. Изменить интерфейс, а после этого продолжить синхронные вычисления — не значит, что пользователь уже увидел отклик: браузеру нужно предоставить возможность выполнить отрисовку.

Для фильтрации товаров можно кэшировать результаты вычислений, чтобы не перебирать все данные при каждом взаимодействии. При проверке формы следует избегать повторного вычисления всей формы при каждом введённом символе. Debounce подходит для сокращения числа несрочных запросов, но не должен задерживать визуальный отклик кнопки или использоваться для сокрытия задержек при выполнении необходимых действий.

Если задержка отображения велика, проверьте размер DOM, область влияния стилей и границы обновления компонентов. Для длинных списков товаров можно использовать виртуализацию, но необходимо также учитывать требования доступности и поисковой индексации. Чередование операций «записать стиль — прочитать размеры» может вызвать принудительную компоновку; по возможности сначала выполняйте все чтения, а затем записи. В приложениях на фреймворках также следует выяснить, не вызывают ли локальные изменения состояния обновление несвязанных компонентов, вместо того чтобы учитывать только длительность обработчика.

requestAnimationFrame — тоже не контейнер для длительных задач: его код выполняется до отрисовки, и большие вычисления внутри него всё равно заблокируют следующий кадр.

Проверяйте результаты на данных реальных посещений, а не только по одному тесту

Лабораторные тесты подходят для воспроизведения причин проблемы, а мониторинг реальных пользователей — для определения масштаба её влияния. Данные CrUX в PageSpeed Insights отражают опыт реальных посетителей; при недостаточном трафике данные на уровне страницы могут отсутствовать, и отсутствие данных не означает, что производительность хорошая. Общее время блокировки в Lighthouse помогает обнаружить нагрузку на главный поток на этапе загрузки, но не заменяет INP.

На сайте можно использовать web-vitals и его функцию атрибуции, записывая целевой элемент взаимодействия, тип страницы и длительность каждого этапа, но не собирая персональные данные, например содержимое форм. Тестирование должно охватывать реальные мобильные устройства и разумные условия понижения частоты CPU. Режим узкого экрана в настольном браузере сам по себе не отражает различия в вычислительных возможностях мобильных устройств.

При приёмке после выпуска сравнивайте распределение INP на страницах одного типа и при сопоставимых условиях использования устройств, а также повторно проверяйте корректность выполнения ключевых взаимодействий. CrUX использует скользящие данные за 28 дней, поэтому не следует ожидать, что все результаты изменений отразятся сразу. Согласно определению INP от Google, подтверждением эффективной оптимизации служит сокращение фактического ожидания при взаимодействии, а не уменьшение объёма ресурсов или повышение результата одного теста.