Узнайте, как новая метрика INP влияет на работу сайтов, созданных с использованием фреймворков и библиотек JavaScript.
Chrome недавно представил новый экспериментальный показатель отзывчивости в отчете Chrome UX Report . Эта метрика, которую мы теперь знаем как «Взаимодействие с следующей отрисовкой» (INP), измеряет общую реакцию на действия пользователя на странице. Сегодня мы хотим поделиться информацией о том, какое место занимают веб-сайты, созданные с использованием современных фреймворков JavaScript, по отношению к этому показателю. Мы хотим обсудить, почему INP важен для фреймворков и как Aurora и фреймворки работают над оптимизацией скорости реагирования.
Фон
Chrome использует задержку первого ввода ( FID ) как часть Core Web Vitals ( CWV ) для измерения скорости реагирования веб-сайтов на нагрузку . FID измеряет время ожидания от первого взаимодействия с пользователем до момента, когда браузер сможет обработать обработчики событий, связанные с взаимодействием. Сюда не входит время на обработку обработчиков событий, обработку последующих взаимодействий на той же странице или рисование следующего кадра после выполнения обратных вызовов событий. Однако оперативность имеет решающее значение для взаимодействия с пользователем на протяжении всего жизненного цикла страницы, поскольку пользователи проводят примерно 90% времени на странице после ее загрузки.
INP измеряет время, необходимое веб-странице для ответа на действия пользователя, с момента, когда пользователь начинает взаимодействие, до момента отображения следующего кадра на экране. С помощью INP мы надеемся обеспечить совокупную оценку воспринимаемой задержки всех взаимодействий в жизненном цикле страницы. Мы считаем, что INP обеспечит более точную оценку нагрузки веб-страниц и скорости реагирования во время их выполнения.
Поскольку FID измеряет только задержку ввода при первом взаимодействии, вполне вероятно, что веб-разработчики не оптимизировали заранее последующие взаимодействия в рамках процесса улучшения CWV. Поэтому сайтам, особенно с высокой степенью интерактивности, придется усердно работать, чтобы преуспеть по этому показателю.
Роль фреймворков
Поскольку многие веб-сайты полагаются на JavaScript для обеспечения интерактивности, на оценку INP в первую очередь будет влиять объем JavaScript, обрабатываемого в основном потоке. Фреймворки JavaScript являются важной частью современной интерфейсной веб-разработки и предоставляют разработчикам ценные абстракции для маршрутизации, обработки событий и разделения кода JavaScript. Таким образом, они играют центральную роль в оптимизации оперативности и пользовательского опыта веб-сайтов, которые их используют.
Фреймворки, возможно, уже предприняли шаги для повышения оперативности, улучшив FID для веб-сайтов ранее. Однако теперь им придется проанализировать имеющиеся данные о показателях реагирования и работать над устранением любых выявленных пробелов. В целом, INP имеет тенденцию иметь более низкую скорость прохождения, а разница в процессе измерения требует дополнительной оптимизации кода. В следующей таблице показано, почему.
Команда Aurora в Chrome работает с веб-фреймворками с открытым исходным кодом, чтобы помочь разработчикам улучшить различные аспекты взаимодействия с пользователем, включая производительность и показатели CWV. С введением INP мы хотим быть готовыми к изменению показателей CWV для веб-сайтов на основе платформы. Мы собрали данные на основе экспериментальной метрики отзывчивости в отчетах CrUX. Мы поделимся идеями и рекомендациями по действиям, чтобы облегчить переход на метрику INP для веб-сайтов на основе платформы.
Экспериментальные данные показателей оперативности
INP ниже или равный 200 миллисекундам указывает на хорошую реакцию. Данные отчета CrUX и отчета о технологиях CWV за июнь 2023 года дают нам следующую информацию об отзывчивости популярных фреймворков JavaScript.
В таблице показан процент источников на каждой платформе с хорошим показателем отзывчивости. Цифры обнадеживают, но говорят нам, что есть еще много возможностей для улучшения.
Как JavaScript влияет на INP?
Значения INP в полевых условиях хорошо коррелируют с общим временем блокировки (TBT), наблюдаемым в лаборатории. Это может означать, что любой сценарий, блокирующий основной поток на длительное время, будет вреден для INP. Интенсивное выполнение JavaScript после любого взаимодействия может заблокировать основной поток на длительный период и задержать ответ на это взаимодействие. Некоторые из распространенных причин, которые приводят к блокировке сценариев:
Неоптимизированный JavaScript. Избыточный код или неправильные стратегии разделения кода и загрузки могут привести к раздуванию JavaScript и блокировке основного потока на длительные периоды времени. Разделение кода, прогрессивная загрузка и разбиение длительных задач могут значительно сократить время отклика.
Сторонние скрипты. Сторонние скрипты , которые иногда не требуются для обработки взаимодействия (например, рекламные скрипты), могут блокировать основной поток и вызывать ненужные задержки. Расстановка приоритетов важных сценариев может помочь уменьшить негативное влияние сторонних сценариев.
Несколько обработчиков событий. Несколько обработчиков событий, связанных с каждым взаимодействием, каждый из которых выполняет отдельный сценарий, могут мешать друг другу и в сумме вызывать длительные задержки. Некоторые из этих задач могут быть несущественными и могут быть запланированы на веб-воркере или когда браузер находится в режиме ожидания.
Накладные расходы платформы на обработку событий. Платформы могут иметь дополнительные функции/синтаксис для обработки событий. Например, Vue использует v-on для подключения прослушивателей событий к элементам, а Angular оборачивает обработчики пользовательских событий. Для реализации этих функций требуется дополнительный код платформы поверх стандартного JavaScript.
Гидратация: при использовании платформы JavaScript сервер нередко генерирует исходный HTML-код для страницы, который затем необходимо дополнить обработчиками событий и состоянием приложения, чтобы он мог быть интерактивным в веб-браузере. Мы называем этот процесс гидратацией. Во время загрузки этот процесс может оказаться трудоемким, в зависимости от того, сколько времени потребуется JavaScript для загрузки и завершения гидратации. Это также может привести к тому, что страницы будут выглядеть интерактивными, хотя на самом деле это не так. Часто гидратация происходит автоматически во время загрузки страницы или лениво (например, при взаимодействии с пользователем) и может повлиять на INP или время обработки из-за планирования задач. В таких библиотеках, как React, вы можете использовать
useTransitionчтобы часть рендеринга компонента находилась в следующем кадре, а любые более дорогостоящие побочные эффекты оставались для будущих кадров. Учитывая это, обновления в процессе перехода, которые приводят к более срочным обновлениям, таким как клики, могут быть шаблоном, который может быть полезен для INP.Предварительная выборка. Агрессивная предварительная выборка ресурсов, необходимых для последующей навигации, может повысить производительность, если все сделано правильно. Однако если вы выполняете предварительную выборку и рендеринг маршрутов SPA синхронно, вы можете в конечном итоге отрицательно повлиять на INP, поскольку весь этот дорогостоящий рендеринг пытается завершиться за один кадр. Сравните это с отказом от предварительной выборки вашего маршрута и вместо этого запуском необходимой работы (например,
fetch()) и разблокировкой рисования. Мы рекомендуем еще раз проверить, обеспечивает ли подход вашей платформы к предварительной выборке оптимальный UX и как (если вообще) это может повлиять на INP.
Отныне, чтобы получить хороший балл INP, разработчикам придется сосредоточиться на проверке кода, который выполняется после каждого взаимодействия на странице, и оптимизировать стратегии разбивки, повторной гидратации, загрузки и размера каждого обновления render() как для первого, так и для второго уровня. сторонние и сторонние скрипты,
Как Aurora и платформы решают проблемы INP?
Aurora работает с платформами, применяя лучшие практики для предоставления встроенных решений распространенных проблем. Мы работали с Next.js, Nuxt.js, Gatsby и Angular над решениями , которые предлагают надежные настройки по умолчанию в рамках платформы для оптимизации производительности. Ниже приведены основные моменты нашей работы в этом контексте:
React и Next.js: компонент Next.js Script помогает решить проблемы, возникающие из-за неэффективной загрузки сторонних скриптов. В Next.js было введено гранулярное разбиение на фрагменты , позволяющее использовать фрагменты меньшего размера для общего кода. Это помогает уменьшить количество неиспользуемого общего кода, загружаемого на всех страницах. Мы также работаем с Next.js, чтобы сделать данные INP доступными в рамках их службы аналитики .
Angular: Aurora сотрудничает с командой Angular для изучения улучшений рендеринга и гидратации на стороне сервера. Мы также планируем изучить улучшения в обработке событий и обнаружении изменений для улучшения INP.
Vue и Nuxt.js: Мы изучаем возможности сотрудничества, в основном в отношении загрузки и рендеринга скриптов.
Как структуры думают об улучшении INP?
React и Next.js
Разделение времени в React.js, реализованное через startTransition и Suspense , позволяет вам выбрать выборочную или прогрессивную гидратацию. Это означает, что гидратация не является синхронным блоком. Это делается небольшими кусочками, которые можно прервать в любой момент.
Это должно помочь улучшить INP и позволить вам быстрее реагировать на нажатия клавиш, эффекты наведения во время перехода и щелчки. Это также помогает поддерживать отзывчивость приложений React даже на большие переходы, такие как автозаполнение.
В Next.js реализована новая структура маршрутизации , которая по умолчанию использует startTransition для переходов маршрутов. Это позволяет владельцам сайтов Next.js использовать квантование времени React и повысить скорость реагирования на переходы маршрутов.
Угловой
Команда Angular изучает несколько идей, которые также могут помочь с INP:
- Бесзональное: сокращается первоначальный размер пакета и требуемый код, который должен загрузиться, прежде чем приложение сможет что-либо отобразить.
- Гидратация: гидратация в островном стиле, позволяющая ограничить объем пробуждения приложения для взаимодействия.
- Сократите накладные расходы на компакт-диск: например, сделайте обнаружение изменений менее затратным, найдите способы меньше проверять приложение и используйте реактивные сигналы о том, что изменилось.
- Более детальное разделение кода: уменьшите первоначальный пакет.
- Улучшенная поддержка индикаторов загрузки: Например, во время повторного рендеринга SSR, во время навигации по маршруту и в операциях отложенной загрузки.
- Инструменты профилирования: улучшенные инструменты разработки для понимания стоимости взаимодействия, особенно в отношении стоимости обнаружения изменений для конкретных взаимодействий.
Благодаря этим улучшениям мы можем решить различные проблемы, которые приводят к ухудшению отзывчивости и пользовательского опыта, а также повысить показатели CWV и новую метрику INP для веб-сайтов на основе платформы.
Заключение
Мы ожидаем, что оценка INP предоставит веб-сайтам лучший ориентир для улучшения отзывчивости и производительности в будущем. В 2023 году мы будем опираться на существующее руководство INP , чтобы предоставить разработчикам фреймворков больше практических советов. Мы надеемся достичь этого путем:
- Создание каналов для легкого доступа к полевым данным INP для фреймворков и веб-разработчиков.
- Работайте с платформами для создания функций, которые по умолчанию улучшат INP.
Мы приветствуем отзывы пользователей платформы, когда они начинают свой путь по оптимизации INP.