Мир браузеров становится все лучше и лучше с каждым днем, теперь у нас есть полноценные веб-страницы, которые выполняют полный набор транзакций со всеми функциями, которые продукт может планировать для нативных приложений ……
Основная проблема в мире браузеров заключалась в том, что когда вы так сильно нагружаете свой JavaScript, чтобы включить все функции, которые могут замедлить работу вашего сайта и ухудшить работу пользователей. Конечно, вы можете использовать веб-пакет или другие инструменты для разделения фрагментов или динамической загрузки и т. д., но ими сложно управлять и сокращать неиспользуемый код.
К счастью, у нас есть полный набор матрицы веб-жизненных показателей, которая сообщает нам о болевых точках наших сайтов и помогает нам сделать их лучше…
Есть 6 основных жизненно важных показателей, но мы ограничим наше обсуждение одним последним жизненно важным показателем (INP), мы будем говорить в основном об этом.
Что такое ИНП?
Веб-разработчики изо всех сил пытались исправить другие жизненно важные вопросы, и это все еще продолжается… у нас есть эта новая бомба 😊.
Но, ребята, поверьте мне, это один из очень интересных моментов, который помогает понять пользовательский опыт и узкие места в нем.
Определение веб-разработчика:
Interaction to Next Paint (INP) — это экспериментальная метрика, которая оценивает скорость отклика. Когда взаимодействие приводит к тому, что страница перестает отвечать на запросы, это плохой пользовательский опыт. INP отслеживает задержку всех взаимодействий пользователя со страницей и сообщает об одном значении, ниже которого были все (или почти все) взаимодействия. Низкий INP означает, что страница постоянно могла быстро реагировать на все или подавляющее большинство пользовательских взаимодействий.
Таким образом, в основном это означает, как ваша веб-страница реагирует на основное взаимодействие с пользователем, если ваша страница не застревает на взаимодействии с пользователем и работает гладко в ответ на это взаимодействие, то в основном ваш INP низкий.
Чтобы определить его в одной строке: -
Взаимодействие с следующей отрисовкой измеряет время, прошедшее между кликом пользователя или любым событием пользователя и представлением следующего труднообрабатываемого кадра на веб-странице.
Вы можете думать об этом с точки зрениязадержки взаимодействия. Основываясь на этом, вы также можете классифицировать это по двум аспектам.
- Задержка, вызванная блокировкой JS на стороне клиента, что может привести к задержке рендеринга.
- Задержка, вызванная последующим вызовом API, которая связана с этим событием, инициированным пользователем, и обязательна для создания следующего кадра.
Мир браузера @redBus Я был очень уверен в своем приложении, что INP довольно хорош, и это было также хорошо, пока я не увидел цифры для 95-го процентиля пользователей, моя уверенность немного снизилась, когда я разбился на сетевые категории ……
Поскольку это очень новая и интересная тема в то время, когда я пишу эту статью, я хотел бы разбить ее на 4 основные категории:
- Как определить ИНП?
- Области воздействия, созданные INP на систему (интерфейс и серверная часть)?
- конечное влияние результата на пользователя и бизнес.
- Точные примеры использования RedBus для задержки взаимодействия на стороне клиента и задержки на основе API.
Как определить ИНП?
Есть несколько способов определить баллы INP на вашей странице. Я кратко опишу некоторые из них, а затем мы обсудим, как RedBus работал над его баллами INP.
- Используйте модуль JS https://unpkg.com/[email protected]/dist/web-vitals.attribution.js?module». Эта библиотека достаточно хороша, чтобы начать поиск ваши баллы INP на ваших веб-страницах.
Давайте сразу начнем с примера кода: -
<script>
import { onINP, onFCP, onCLS, onFID, onLCP } from 'https://unpkg.com/[email protected]/dist/web-vitals.attribution.js?module';
const sendDataToLogRUM = (metrics, metricName) => {
const { attribution, id, value, rating } = metrics;
if((metricName === 'INP' && value < 40) || (metricName === 'CLS' && value < 0.1)) return;
const {eventType, eventTarget, element, largestShiftTarget } = attribution;
const stringifiedAttribution = JSON.stringify({
eventType,
eventTarget,
element,
largestShiftTarget
});
const vitalData = {
id,
value: value.toFixed(3),
rating,
attribution: stringifiedAttribution,
};
if(value > 0 && window.yourxxxxApm) {
const transaction = window.yourxxxxxxxApm.startTransaction(metricName, 'custom', { managed: true })
transaction.addLabels(vitalData);
setTimeout(() => {
transaction.end()
/**
* This would also end the managed transaction once all the blocking spans are completed and
* transaction would also contain other timing information and spans similar to auto
* instrumented transactions like `page-load` and `route-change`.
*/
}, 1000)
}
};
onFCP((metrics) => sendDataToLogRUM(metrics,'FCP'));
onFID((metrics) => sendDataToLogRUM(metrics,'FID'));
onLCP((metrics) => sendDataToLogRUM(metrics,'LCP'));
onCLS((metrics) => sendDataToLogRUM(metrics,'CLS'),{reportAllChanges: true});
onINP((metrics) => sendDataToLogRUM(metrics,'INP'),{reportAllChanges: true});
</script>
Система ведения журнала, которая использовалась здесь, — это ELK, вы можете отправлять данные в свою систему ведения журнала по мере необходимости. @redBus мы начали собирать эти данные в нашей системе ведения журнала, и мы анализируем INP для каждой страницы и для каждого взаимодействия и классифицируем его на основе сети. также.
Просто потрясающе анализировать эти данные и понимать проблемы взаимодействия с пользователями. Кстати, важно понимать, что вы не получите точных проблем или номеров INP из одних и тех же событий, но вы обязательно получите направление для изучения.
Образцы данных, собранные в RUM: -
2. Другой подход к получению этих данных — использование модуля webpack.
import {onLCP, onFID, onCLS} from 'web-vitals';
onCLS(console.log);
onFID(console.log);
onLCP(console.log);
Это более предпочтительный подход, но единственный момент, на котором нам нужно сосредоточиться, это: - Он будет добавлен ко всем пакетам, где бы вы ни хотели отслеживать INP, и усилия по интеграции выполняются на всех страницах (зависит от архитектуры).
Это подводит нас к следующей части: - Области воздействия, созданные INP на систему (интерфейс и серверная часть)?
Это может показаться немного спорным, но, поверьте мне, эта жизненно важная информация направит вас таким образом, чтобы вы могли исправить свой API, который поддерживает ваш интерфейс. Изменения, которые сделал redBus: -
- Оптимизированы первые точки взаимодействия пользователя, которые являются обязательными для перехода к следующему экрану для бронирования.
2. Сделали наши API более легкими, которые привязаны ко всем взаимодействиям с пользователем.
3. Сокращено время отклика API и данные, передаваемые через вызовы API (это зависит от варианта использования), например, на нашей странице поиска пользователь может видеть только 3 шины одновременно, поэтому создание большего количества результатов поиска может быть отложено по требованию, что означает, что пользователь прокрутить.
Точные примеры использования redBus.
Давайте посмотрим некоторые варианты использования: -
- При щелчке пользователя по изменению даты на странице поиска мы вызываем все соответствующие данные для этого источника и назначения на следующую дату. У него был плохой INP.
2. При прокрутке инвентаряredBus выполняет ленивую загрузку инвентаря и вызывает следующий набор инвентаря из следующего смещения (например: начальная загрузка пакета 0–10 шин, затем ответ следующего пакета API 11–20).
Исправления.
Чтобы улучшить значение INP и производительность страницы поиска, мы внесли несколько улучшений, в том числе:
- Добавление обратного вызова функции для вызовов методов прослушивателя прокрутки и выполнение однократных вычислений из методов прослушивателя прокрутки, чтобы уменьшить повторные вычисления браузера и частоту перерисовки.
- Вы также можете использовать `requestAnimationFrame`. Он сообщает браузеру, что вы хотите выполнить анимацию, и запрашивает, чтобы браузер вызывал указанную функцию для обновления анимации перед следующей перерисовкой. Метод принимает обратный вызов в качестве аргумента, который должен быть вызван перед перерисовкой.
- Получение новых пакетов результатов на предпоследней карточке на странице SRP для улучшения UX и визуальной производительности.
- Уменьшение начального размера пакета результатов поиска с 30 до 10 для всех маршрутов. После внесения только этого изменения мы проверили 95-й процентиль полевых данных из ELK и обнаружили, что показатели значительно улучшились с 870–900 до 350–370.
Вывод.
Внеся несколько изменений, в том числе добавив отклоненный вызов функции, изменив начальный размер пакета и улучшив UX за счет предварительного получения новых результатов, мы значительно улучшили показатель INP и общую производительность. страницы поиска. Изменения привели к более плавному и быстрому взаимодействию с пользователем и повышению производительности.
3. Поля ввода на странице информации о клиенте
Проблема.
Функция onChange в полях ввода вызывала редюсер для каждого изменения, что приводило к нежелательному повторному рендерингу и плохим значениям INP.
Исправления:
Чтобы улучшить значение INP полей ввода на странице информации о клиенте, мы локально управляли состоянием компонентов ввода и синхронизировали его с хранилищем избыточности только при запуске события onBlur. . Это изменение уменьшило количество повторных рендеров и устранило нежелательный повторный рендеринг, вызванный вызовом редьюсера для каждого изменения.
Вывод.
Управляя состоянием компонентов ввода локально и синхронизируя их с хранилищем избыточности только при срабатывании события onBlur, мы значительно улучшили значение INP для полей вводана 72. %. Это изменение привело к более быстрому и плавному взаимодействию с пользователем и устранило нежелательный повторный рендеринг, вызванный вызовом редьюсера для каждого изменения.
конечное влияние результата на пользователя и бизнес.
Наступает самая интересная часть, которая важна для каждого, чтобы понять, какое влияние это может создать.
RedBus не устранил все проблемы, связанные с INP, на разных страницах воронки бронирования, для разных сетевых подразделений и т. д., но мы определили основные узкие места, которые мешают нашему пользователю углубляться в воронку бронирования, это помогло нам увеличить конверсию страницы на страницу. скорость, но основное влияние было, когда наш CR улучшился примерно на 6% - 7,2% примерно для одной страны, в которой мы работаем, а также приличный прирост для других географических регионов.
Надеюсь, это выявит важность хорошего пользовательского опыта, и INP в значительной степени помог нам в решении этой проблемы.
ЗАКЛЮЧИТЕЛЬНЫЕ СЛОВА
В заключение я бы сказал, что если вы действительно хотите разобраться в проблемах взаимодействия с пользователем, то этот жизненно важный пункт является идеальной отправной точкой. Проанализируйте эти цифры, и вы получите четкое представление о проблемах с потоком пользователей.
Следуйте за мной на https://amitkumar-v.medium.com/
Спасибо за чтение, хорошего дня!
Есть конкретный вопрос? Напишите нам твит.
Соавтор:- https://harshkc.medium.com
