Economic Times пытается исправить INP

Снижение TBT в 30 раз и переход на Next.js помог The Ecomonic Times сократить INP почти в четыре раза, что привело к снижению показателя отказов на 50 % и увеличению количества просмотров страниц на 43 %.

Дайя Рам Ядав
Daya Ram Yadav
Саураб Раджпал
Saurabh Rajpal

Взаимодействие с следующей отрисовкой (INP) — это показатель, который оценивает реакцию веб-сайта на ввод пользователя. Хорошая отзывчивость означает, что страница быстро реагирует на действия пользователя. Чем ниже INP страницы, тем лучше она реагирует на взаимодействия с пользователем.

Хорошие значения INP составляют 200 миллисекунд или меньше, плохие значения — более 500 миллисекунд, а все, что находится между ними, требует улучшения.

Нечеткое начало

Когда Google первоначально представил INP в качестве экспериментальной метрики с потенциалом превращения в одну из метрик Core Web Vitals, команда Economic Times взяла на себя задачу исправить ее, прежде чем она превратится в таковую, поскольку обеспечение пользовательского опыта мирового класса имеет решающее значение для наши основные бизнес-ценности.

INP до сих пор был одной из самых сложных метрик для решения. Вначале было неясно, как эффективно измерить INP. Что еще больше осложняло задачу, так это отсутствие поддержки сообщества, в том числе большинства поставщиков Real User Monitoring (RUM), которые еще не поддерживают эту функцию. Однако у нас были инструменты Google RUM, такие как Chrome User Experience Report (CrUX) , библиотека JavaScript web-vitals и другие, поддерживающие ее, что давало нам представление о том, где мы находимся, пока оцениваем дальнейший путь. Когда мы начинали, наш INP был близок к 1000 миллисекундам на исходном уровне.

При исправлении INP в полевых условиях выяснилось, что одним из целевых лабораторных показателей может быть общее время блокировки (TBT) . ТБТ уже хорошо документирован и поддержан сообществом. Однако, несмотря на то, что мы уже достигли пороговых значений для основных веб-показателей, мы не так хорошо справлялись с TBT, поскольку, когда мы начали, оно составляло более 3 секунд.

Что такое ТБТ и какие шаги мы предприняли для его улучшения?

TBT — это лабораторный показатель, который измеряет скорость реагирования веб-страницы на ввод пользователя во время загрузки страницы. Любая задача, выполнение которой занимает более 50 миллисекунд, считается длинной задачей, а время после порога в 50 миллисекунд называется временем блокировки .

TBT рассчитывается как сумма времени блокировки всех длительных задач во время загрузки страницы. Например, если во время загрузки есть две длинные задачи, время блокировки определяется следующим образом:

  • Задача А занимает 80 миллисекунд (на 30 миллисекунд больше, чем на 50 миллисекунд).
  • Задача Б занимает 100 миллисекунд (на 50 миллисекунд больше, чем на 50 миллисекунд).

TBT страницы составит: 80 миллисекунд (30 + 50). Чем ниже TBT, тем лучше, и TBT также хорошо коррелирует с INP .

Вот краткое лабораторное сравнение нашего TBT до и после принятия мер по его улучшению:

Составное изображение длительных задач во время запуска, как показано на панели производительности Chrome DevTools, и отчет о показателях страницы. Основной поток блокируется во время загрузки страницы на 3260 миллисекунд.
Основной поток во время запуска перед оптимизацией TBT. TBT составляет 3260 миллисекунд.
Составное изображение длительных задач во время запуска, как показано на панели производительности Chrome DevTools, и отчет о показателях страницы. Основной поток блокируется во время загрузки страницы на 120 миллисекунд.
Основной поток при запуске после оптимизации TBT. TBT составляет 120 миллисекунд.

Минимизируйте работу основного потока

Основной поток браузера обрабатывает все: от анализа HTML, построения DOM до анализа CSS и применения стилей, а также оценки и выполнения JavaScript. Основной поток также обрабатывает взаимодействия с пользователем, то есть щелчки, касания и нажатия клавиш. Если основной поток занят выполнением другой работы, он может не реагировать на вводимые пользователем данные эффективно и может привести к затруднениям в работе пользователя.

Для нас это была самая сложная задача, поскольку у нас есть собственные алгоритмы определения личности пользователя для показа рекламы на основе статуса подписки и сторонние скрипты для A/B-тестирования, аналитики и многого другого.

Сначала мы предприняли небольшие шаги, например, снизили приоритет загрузки менее важных бизнес-активов. Во-вторых, мы использовали requestIdleCallback для некритической работы, что может помочь снизить TBT.

if ('requestIdleCallback' in window) {
 
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData
(); // Fallback in case requestIdleCallback is not supported
}

Указывать таймаут рекомендуется при использовании requestIdleCallback , поскольку он гарантирует, что если заданное время истекло и обратный вызов еще не был вызван, он выполнит обратный вызов сразу после таймаута.

Минимизируйте время оценки сценария

Мы также загружаем сторонние библиотеки с отложенной загрузкой, используя загружаемые компоненты . Мы также удалили неиспользуемый JavaScript и CSS, профилировав страницу с помощью инструмента покрытия в Chrome DevTools. Это помогло нам определить области, где требовалось встряхивание дерева, чтобы отправлять меньше кода во время загрузки страницы и, следовательно, уменьшить первоначальный размер пакета приложения.

Скриншот инструмента покрытия в Chrome DevTools. Здесь инструмент отображает неиспользуемые части файлов JavaScript и CSS во время загрузки страницы.

Уменьшить размер DOM

Согласно Lighthouse, большие размеры DOM увеличивают использование памяти, вызывают более длительные пересчеты стилей и приводят к дорогостоящим перекомпоновкам макета .

Скриншот аудита размера DOM в Lighthouse. Количество зарегистрированных элементов DOM составляет 2706 элементов.

Мы сократили количество узлов DOM двумя способами:

  • Во-первых, мы отображали пункты меню по запросу пользователя (по клику). Это уменьшило размер DOM примерно на 1200 узлов.
  • Во-вторых, мы лениво загружаем менее важные виджеты.

Благодаря всем этим усилиям мы значительно сократили TBT, и наш INP соответственно сократился почти на 50 %:

Скриншот аудита INP в CruX. INP для страницы составляет 539 миллисекунд, что превышает «плохой» порог.

На данный момент у нас почти закончились легкие победы над дальнейшим сокращением TBT (и INP по доверенности), но мы знали, что у нас есть много возможностей для улучшения. Именно тогда мы решили обновить наш специально созданный шаблон пользовательского интерфейса до последней версии React вместе с Next.js, чтобы лучше использовать перехваты и избежать ненужного повторного рендеринга компонентов.

Из-за более частых обновлений и сравнительно меньшего трафика по сравнению с другими частями веб-сайта мы начали переносить наши тематические страницы на Next.js. Мы также использовали PartyTown для перегрузки дополнительной тяжелой работы основного потока веб-работникам, а также такие методы, как requestIdleCallBack для отсрочки некритических задач.

Как улучшение INP помогло The Economic Times?

Текущие ТБТ и INP по происхождению

На момент публикации этого поста TBT для нашего источника составлял 120 миллисекунд по сравнению с 3260 миллисекундами, когда мы начали работу по оптимизации. Аналогичным образом, после наших усилий по оптимизации INP для нашего источника составил 257 миллисекунд по сравнению с более чем 1000 миллисекундами.

Скриншот аудита INP в CruX. INP для страницы составляет 257 миллисекунд, что находится в пределах пороговых значений, требующих улучшения.

Тенденция ИЯФ Crux

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

Скриншот распределения INP, визуализированного в CrUX, за период в четыре месяца, начиная с июля 2022 г. и заканчивая октябрем 2022 г. Значения в пределах «плохих» и «требующих улучшения» порогов несколько снизились, тогда как значения в пределах «хорошего» порога повысился.

Анализ ТБТ Akamai mPulse

Мы используем Akamai mPulse в качестве нашего решения RUM, которое измеряет TBT в полевых условиях. Мы наблюдали последовательное снижение уровня ТБТ, что четко отражает результаты наших усилий по снижению INP. Как видно на скриншоте ниже, значения TBT в полевых условиях в конечном итоге упали примерно с 5 секунд до примерно 200 миллисекунд.

Скриншот графика в Akamai mPulse, показывающий снижение TBT в течение примерно месяца.

Бизнес-результат

В целом, наши усилия по снижению TBT в 30 раз, а также переход на Next.js помогли нам сократить INP почти в 4 раза, что в конечном итоге привело к снижению показателя отказов на 50 % и увеличению количества просмотров на тематических страницах на 43 % .

Скриншот Google Analytics, сравнивающий количество просмотров страниц с показателем отказов. Благодаря оптимизации INP на веб-сайте The Economic Times показатель отказов снизился на 50 %, а количество просмотров страниц увеличилось на 43 %.

Заключение

Подводя итог, можно сказать, что INP во многом помог выявить проблемы с производительностью отдельных частей веб-сайта Economic Times. Это оказалось одним из наиболее эффективных показателей, положительно влияющих на результаты бизнеса. В связи с очень обнадеживающими цифрами, которые мы получили в результате этих усилий, мы заинтересованы в том, чтобы расширить наши усилия по оптимизации на другие области нашего веб-сайта и получить дополнительные преимущества.