Как redBus улучшил взаимодействие своего веб-сайта с Next Paint (INP) и увеличил продажи на 7 %

Оптимизация INP помогла redBus увеличить продажи примерно на 7%

Amit Kumar

Saurabh Rajpal

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

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

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

redBus , веб-сайт по бронированию автобусов и продаже билетов, базирующийся в Индии, предпринял значительные усилия для улучшения INP своего веб-сайта, даже в то время, когда он все еще считался экспериментальным показателем. В результате своих усилий им удалось увеличить продажи на 7%, что еще раз продемонстрировало взаимосвязь между производительностью Интернета и здоровьем бизнеса. Вот что RedBus сделал для улучшения INP своего сайта.

Лучшие цели

Когда redBus решил оптимизировать INP своего веб-сайта, они преследовали три цели:

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

Путешествие

RedBus классифицировал задержку взаимодействия двумя способами:

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

RedBus изначально был вполне уверен, что INP для их веб-сайта будет хорошим, но данные Real User Monitoring (RUM) для этого показателя на 95-м процентиле говорили о другом.

Как redBus измерял INP

RedBus использовал JavaScript-библиотеку web-vitals созданную Google, для отслеживания не только INP, но и всех важных показателей пользовательского опыта для всех страниц своего веб-сайта. В дополнение к библиотеке JavaScript web-vitals RedBus использовал ELK для анализа данных INP, собранных на внешнем интерфейсе.

Однако способ отслеживания INP вашего веб-сайта в полевых условиях может сильно отличаться от того, как RedBus подошел к этой проблеме. Мы настоятельно рекомендуем вам прочитать о том , как находить медленные взаимодействия в полевых условиях , чтобы узнать, как лучше всего отслеживать INP для ваших веб-сайтов, а затем как воспроизводить их в лаборатории, прежде чем приступать к оптимизации взаимодействий .

Когда у redBus появилась система отслеживания INP, они смогли проанализировать данные, чтобы лучше понять, где присутствует медленная интерактивность.

Снимок экрана системы регистрации ELK, сообщающей значения INP для анализа. — Скриншот системы журналирования, используемой redBus для анализа значений INP, собранных в полевых условиях. ( Нажмите, чтобы увидеть версию этого изображения с более высоким разрешением .)

Случаи использования

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

Кроме того, когда пользователь просматривает тарифы, дополнительные тарифы загружаются из API отложенно. Хотя сама прокрутка не учитывается при измерении INP , прослушиватель событий scroll сам планирует большую работу, которая должна выполняться в основном потоке. Эта работа вызывала разногласия в основном потоке, что увеличивало задержку взаимодействия и приводило к ухудшению INP на странице поиска.

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

Как redBus оптимизировал INP для страницы поиска

Чтобы улучшить INP страницы поиска, redBus провел несколько оптимизаций:

Обработчик событий scroll был удален , чтобы уменьшить количество срабатываний обратного вызова события за определенный период. За счет снижения частоты выполнения обратного вызова события scroll основной поток смог быстрее реагировать на действия пользователя на странице поиска.
Приоритет результирующей работы по рендерингу был определен с помощью обратного вызова requestAnimationFrame . requestAnimationFrame сообщает браузеру, что работа в обратном вызове должна быть выполнена до следующего кадра.

Снимок экрана панели производительности в Chrome DevTools, показывающий, как веб-сайт redBus запускает обратные вызовы событий прокрутки, которые не отклоняются. В результате основной поток блокируется. — Раньше: обработчики прокрутки сработали без устранения дребезга, примененного к обратному вызову события. В основном потоке присутствует значительное количество блокирующих задач, которые будут задерживать взаимодействие.

Кроме того, на странице результатов поиска были произведены следующие дополнительные оптимизации:

Новые пакеты результатов были получены на предпоследней карточке на странице результатов поиска, чтобы улучшить взаимодействие с пользователем и визуальную производительность за счет более раннего запуска отложенной загрузки.
Во время отложенной загрузки при каждом сетевом вызове получалось меньше результатов. При сокращении выборок с 30 до 10 результатов наблюдалось сокращение диапазонов INP с 870 до 900 до 350–370.

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

Значения INP отображаются в консоли, пока пользователь вводит данные в поле ввода. Полученное значение INP 344, наблюдаемое в лабораторных условиях, соответствует пороговым значениям «необходимости в улучшении». ( Нажмите, чтобы просмотреть версию этого видео в более высоком разрешении .)

Чтобы оптимизировать это взаимодействие, redBus локально управлял состоянием компонентов ввода и синхронизировал его с хранилищем Redux только при возникновении события blur ввода. Это изменение уменьшило количество повторных отрисовок и устранило нежелательную повторную отрисовку пользовательского интерфейса за счет менее частого вызова редуктора.

Улучшен INP в результате менее частого вызова редуктора при изменении поля ввода. ( Нажмите, чтобы просмотреть версию этого видео в более высоком разрешении .)

Благодаря этому изменению INP страницы улучшился на 72%, что привело к более быстрому и плавному взаимодействию с пользователем, с которым пользователи с большей вероятностью будут взаимодействовать.

Влияние на бизнес

Взаимосвязь между состоянием бизнеса и производительностью страниц хорошо известна. Хотя INP является относительно новым показателем по сравнению с другими показателями Core Web Vitals, redBus добился лучших результатов в бизнесе, сосредоточив внимание на улучшении этого важного показателя производительности, ориентированного на пользователя. Результатом стал общий рост продаж на 7%.

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