Обновленная информация о наших планах по измерению скорости реагирования в Интернете.
Ранее в этом году команда Chrome Speed Metrics поделилась некоторыми идеями, которые мы рассматривали для нового показателя отзывчивости. Мы хотим разработать метрику, которая лучше отражала бы сквозную задержку отдельных событий и предлагала бы более целостную картину общей отзывчивости страницы на протяжении всего ее существования.
За последние несколько месяцев мы добились большого прогресса в этом показателе и хотели бы поделиться обновленной информацией о том, как мы планируем измерять задержку взаимодействия, а также представить несколько конкретных вариантов агрегирования, которые мы рассматриваем для количественной оценки общей скорости реагирования. веб-страницы.
Мы хотели бы получить отзывы от разработчиков и владельцев сайтов о том, какой из этих вариантов будет наиболее репрезентативным для общей отзывчивости их страниц.
Измерение задержки взаимодействия
В качестве обзора метрика первой входной задержки (FID) фиксирует задержку входной задержки. То есть время между взаимодействием пользователя со страницей и моментом, когда обработчики событий могут запускаться.
С помощью этой новой метрики мы планируем расширить ее, чтобы фиксировать полную продолжительность события : от первоначального ввода пользователя до отрисовки следующего кадра после запуска всех обработчиков событий.
Мы также планируем измерять взаимодействия , а не отдельные события. Взаимодействия — это группы событий, которые отправляются как часть одного и того же логического жеста пользователя (например: pointerdown , click , pointerup ).
Чтобы измерить общую задержку взаимодействия по группе продолжительностей отдельных событий, мы рассматриваем два потенциальных подхода:
- Максимальная продолжительность события: задержка взаимодействия равна наибольшей продолжительности отдельного события из любого события в группе взаимодействия.
- Общая продолжительность события: задержка взаимодействия представляет собой сумму всех длительностей событий без учета перекрытия.
В качестве примера на диаграмме ниже показано взаимодействие нажатия клавиши , состоящее из keydown и события keyup . В этом примере между этими двумя событиями наблюдается перекрытие продолжительности. Чтобы измерить задержку взаимодействия с нажатием клавиши, мы могли бы использовать max(keydown duration, keyup duration) или sum(keydown duration, keyup duration) - duration overlap :
У каждого подхода есть свои плюсы и минусы, и мы хотели бы собрать больше данных и отзывов , прежде чем окончательно определить задержку.
Объедините все взаимодействия на странице
Как только мы сможем измерить сквозную задержку всех взаимодействий, следующим шагом будет определение совокупной оценки посещения страницы, которая может содержать более одного взаимодействия.
Изучив ряд вариантов, мы сузили выбор до стратегий, изложенных в следующем разделе, по каждой из которых мы в настоящее время собираем данные реальных пользователей в Chrome. Мы планируем опубликовать результаты наших выводов, как только у нас будет время собрать достаточно данных, но мы также ждем прямых отзывов от владельцев сайтов о том, какая стратегия наиболее точно отразит шаблоны взаимодействия на их страницах.
Варианты стратегий агрегирования
Чтобы объяснить каждую из следующих стратегий, рассмотрим пример посещения страницы, состоящий из четырех взаимодействий:
| Взаимодействие | Задержка |
|---|---|
| Нажмите | 120 мс |
| Нажмите | 20 мс |
| Нажатие клавиши | 60 мс |
| Нажатие клавиши | 80 мс |
Самая большая задержка взаимодействия
Самая большая задержка отдельного взаимодействия, произошедшая на странице. Учитывая приведенные выше примеры взаимодействий, наихудшая задержка взаимодействия составит 120 мс.
Бюджетные стратегии
Исследования пользовательского опыта показывают, что пользователи могут не воспринимать задержки ниже определенных пороговых значений как негативные. На основе этого исследования мы рассматриваем несколько бюджетных стратегий, использующих следующие пороговые значения для каждого типа событий:
| Тип взаимодействия | Порог бюджета |
|---|---|
| Нажмите/коснитесь | 100 мс |
| Тащить | 100 мс |
| Клавиатура | 50 мс |
Каждая из этих стратегий будет учитывать только задержку, превышающую порог бюджета на взаимодействие. Если использовать приведенный выше пример посещения страницы, суммы превышения бюджета будут следующими:
| Взаимодействие | Задержка | Задержка сверх бюджета |
|---|---|---|
| Нажмите | 120 мс | 20 мс |
| Нажмите | 20 мс | 0 мс |
| Нажатие клавиши | 60 мс | 10 мс |
| Нажатие клавиши | 80 мс | 30 мс |
Наихудшая задержка взаимодействия по сравнению с бюджетом
Самая большая задержка отдельного взаимодействия сверх бюджета. Используя приведенный выше пример, оценка будет max(20, 0, 10, 30) = 30 ms .
Общая задержка взаимодействия сверх бюджета
Сумма всех задержек взаимодействия сверх бюджета. В приведенном выше примере оценка будет равна (20 + 0 + 10 + 30) = 60 ms .
Средняя задержка взаимодействия сверх бюджета
Общая задержка взаимодействия, превышающая бюджет, деленная на общее количество взаимодействий. В приведенном выше примере оценка будет равна (20 + 0 + 10 + 30) / 4 = 15 ms .
Приближение высокого квантиля
В качестве альтернативы вычислению наибольшей задержки взаимодействия в рамках бюджета мы также рассмотрели возможность использования аппроксимации с высоким квантилем, которая должна быть более справедливой для веб-страниц, на которых происходит много взаимодействий, и с большей вероятностью будет иметь большие выбросы. Мы определили две потенциальные стратегии аппроксимации с высокими квантилями, которые нам нравятся:
- Вариант 1. Отслеживайте самые крупные и вторые по величине взаимодействия, превышающие бюджет. После каждых 50 новых взаимодействий удаляйте самое большое взаимодействие из предыдущего набора из 50 и добавляйте самое большое взаимодействие из текущего набора из 50. Окончательным значением будет максимальное оставшееся взаимодействие сверх бюджета.
- Вариант 2. Рассчитайте 10 наибольших взаимодействий сверх бюджета и выберите значение из этого списка в зависимости от общего количества взаимодействий. Учитывая общее количество взаимодействий N, выберите (N / 50 + 1)-е наибольшее значение или 10-е значение для страниц с более чем 500 взаимодействиями.
Измерьте эти параметры в JavaScript
Следующий пример кода можно использовать для определения значений первых трех стратегий, представленных выше. Обратите внимание, что пока невозможно измерить общее количество взаимодействий на странице в JavaScript, поэтому этот пример не включает стратегию среднего взаимодействия по бюджету или стратегии аппроксимации высокого квантиля.
const interactionMap = new Map();
let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;
new PerformanceObserver((entries) => {
for (const entry of entries.getEntries()) {
// Ignore entries without an interaction ID.
if (entry.interactionId > 0) {
// Get the interaction for this entry, or create one if it doesn't exist.
let interaction = interactionMap.get(entry.interactionId);
if (!interaction) {
interaction = {latency: 0, entries: []};
interactionMap.set(entry.interactionId, interaction);
}
interaction.entries.push(entry);
const latency = Math.max(entry.duration, interaction.latency);
worstLatency = Math.max(worstLatency, latency);
const budget = entry.name.includes('key') ? 50 : 100;
const latencyOverBudget = Math.max(latency - budget, 0);
worstLatencyOverBudget = Math.max(
latencyOverBudget,
worstLatencyOverBudget,
);
if (latencyOverBudget) {
const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
}
// Set the latency on the interaction so future events can reference.
interaction.latency = latency;
// Log the updated metric values.
console.log({
worstLatency,
worstLatencyOverBudget,
totalLatencyOverBudget,
});
}
}
// Set the `durationThreshold` to 50 to capture keyboard interactions
// that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});
Обратная связь
Мы хотим призвать разработчиков опробовать эти новые показатели оперативности на своих сайтах и сообщить нам, если вы обнаружите какие-либо проблемы.
Отправьте общий отзыв об изложенных здесь подходах в группу Google, посвященную веб-показаниям, указав в теме письма «[Показатели реагирования]». Мы очень ждем вашего мнения!
,Обновленная информация о наших планах по измерению скорости реагирования в Интернете.
Ранее в этом году команда Chrome Speed Metrics поделилась некоторыми идеями, которые мы рассматривали для нового показателя отзывчивости. Мы хотим разработать метрику, которая лучше отражала бы сквозную задержку отдельных событий и предлагала бы более целостную картину общей отзывчивости страницы на протяжении всего ее существования.
За последние несколько месяцев мы добились большого прогресса в этом показателе и хотели бы поделиться обновленной информацией о том, как мы планируем измерять задержку взаимодействия, а также представить несколько конкретных вариантов агрегирования, которые мы рассматриваем для количественной оценки общей скорости реагирования. веб-страницы.
Мы хотели бы получить отзывы от разработчиков и владельцев сайтов о том, какой из этих вариантов будет наиболее репрезентативным для общей отзывчивости их страниц.
Измерение задержки взаимодействия
В качестве обзора метрика первой входной задержки (FID) фиксирует задержку входной задержки. То есть время между взаимодействием пользователя со страницей и моментом, когда обработчики событий могут запускаться.
С помощью этой новой метрики мы планируем расширить ее, чтобы фиксировать полную продолжительность события : от первоначального ввода пользователя до отрисовки следующего кадра после запуска всех обработчиков событий.
Мы также планируем измерять взаимодействия , а не отдельные события. Взаимодействия — это группы событий, которые отправляются как часть одного и того же логического жеста пользователя (например: pointerdown , click , pointerup ).
Чтобы измерить общую задержку взаимодействия по группе продолжительностей отдельных событий, мы рассматриваем два потенциальных подхода:
- Максимальная продолжительность события: задержка взаимодействия равна наибольшей продолжительности отдельного события из любого события в группе взаимодействия.
- Общая продолжительность события: задержка взаимодействия представляет собой сумму всех длительностей событий без учета перекрытия.
В качестве примера на диаграмме ниже показано взаимодействие нажатия клавиши , состоящее из keydown и события keyup . В этом примере между этими двумя событиями наблюдается перекрытие продолжительности. Чтобы измерить задержку взаимодействия с нажатием клавиши, мы могли бы использовать max(keydown duration, keyup duration) или sum(keydown duration, keyup duration) - duration overlap :
У каждого подхода есть свои плюсы и минусы, и мы хотели бы собрать больше данных и отзывов , прежде чем окончательно определить задержку.
Объедините все взаимодействия на странице
Как только мы сможем измерить сквозную задержку всех взаимодействий, следующим шагом будет определение совокупной оценки посещения страницы, которая может содержать более одного взаимодействия.
Изучив ряд вариантов, мы сузили выбор до стратегий, изложенных в следующем разделе, по каждой из которых мы в настоящее время собираем данные реальных пользователей в Chrome. Мы планируем опубликовать результаты наших выводов, как только у нас будет время собрать достаточно данных, но мы также ждем прямых отзывов от владельцев сайтов о том, какая стратегия наиболее точно отразит шаблоны взаимодействия на их страницах.
Варианты стратегий агрегирования
Чтобы объяснить каждую из следующих стратегий, рассмотрим пример посещения страницы, состоящий из четырех взаимодействий:
| Взаимодействие | Задержка |
|---|---|
| Нажмите | 120 мс |
| Нажмите | 20 мс |
| Нажатие клавиши | 60 мс |
| Нажатие клавиши | 80 мс |
Самая большая задержка взаимодействия
Самая большая задержка отдельного взаимодействия, произошедшая на странице. Учитывая приведенные выше примеры взаимодействий, наихудшая задержка взаимодействия составит 120 мс.
Бюджетные стратегии
Исследования пользовательского опыта показывают, что пользователи могут не воспринимать задержки ниже определенных пороговых значений как негативные. На основе этого исследования мы рассматриваем несколько бюджетных стратегий, использующих следующие пороговые значения для каждого типа событий:
| Тип взаимодействия | Порог бюджета |
|---|---|
| Нажмите/коснитесь | 100 мс |
| Тащить | 100 мс |
| Клавиатура | 50 мс |
Каждая из этих стратегий будет учитывать только задержку, превышающую порог бюджета на взаимодействие. Если использовать приведенный выше пример посещения страницы, суммы превышения бюджета будут следующими:
| Взаимодействие | Задержка | Задержка сверх бюджета |
|---|---|---|
| Нажмите | 120 мс | 20 мс |
| Нажмите | 20 мс | 0 мс |
| Нажатие клавиши | 60 мс | 10 мс |
| Нажатие клавиши | 80 мс | 30 мс |
Наихудшая задержка взаимодействия по сравнению с бюджетом
Самая большая задержка отдельного взаимодействия сверх бюджета. Используя приведенный выше пример, оценка будет max(20, 0, 10, 30) = 30 ms .
Общая задержка взаимодействия сверх бюджета
Сумма всех задержек взаимодействия сверх бюджета. В приведенном выше примере оценка будет равна (20 + 0 + 10 + 30) = 60 ms .
Средняя задержка взаимодействия сверх бюджета
Общая задержка взаимодействия, превышающая бюджет, деленная на общее количество взаимодействий. В приведенном выше примере оценка будет равна (20 + 0 + 10 + 30) / 4 = 15 ms .
Приближение высокого квантиля
В качестве альтернативы вычислению наибольшей задержки взаимодействия в рамках бюджета мы также рассмотрели возможность использования аппроксимации с высоким квантилем, которая должна быть более справедливой для веб-страниц, на которых происходит много взаимодействий, и с большей вероятностью будет иметь большие выбросы. Мы определили две потенциальные стратегии аппроксимации с высокими квантилями, которые нам нравятся:
- Вариант 1. Отслеживайте самые крупные и вторые по величине взаимодействия, превышающие бюджет. После каждых 50 новых взаимодействий удаляйте самое большое взаимодействие из предыдущего набора из 50 и добавляйте самое большое взаимодействие из текущего набора из 50. Окончательным значением будет максимальное оставшееся взаимодействие сверх бюджета.
- Вариант 2. Рассчитайте 10 наибольших взаимодействий сверх бюджета и выберите значение из этого списка в зависимости от общего количества взаимодействий. Учитывая общее количество взаимодействий N, выберите (N / 50 + 1)-е наибольшее значение или 10-е значение для страниц с более чем 500 взаимодействиями.
Измерьте эти параметры в JavaScript
Следующий пример кода можно использовать для определения значений первых трех стратегий, представленных выше. Обратите внимание, что пока невозможно измерить общее количество взаимодействий на странице в JavaScript, поэтому этот пример не включает стратегию среднего взаимодействия по бюджету или стратегии аппроксимации высокого квантиля.
const interactionMap = new Map();
let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;
new PerformanceObserver((entries) => {
for (const entry of entries.getEntries()) {
// Ignore entries without an interaction ID.
if (entry.interactionId > 0) {
// Get the interaction for this entry, or create one if it doesn't exist.
let interaction = interactionMap.get(entry.interactionId);
if (!interaction) {
interaction = {latency: 0, entries: []};
interactionMap.set(entry.interactionId, interaction);
}
interaction.entries.push(entry);
const latency = Math.max(entry.duration, interaction.latency);
worstLatency = Math.max(worstLatency, latency);
const budget = entry.name.includes('key') ? 50 : 100;
const latencyOverBudget = Math.max(latency - budget, 0);
worstLatencyOverBudget = Math.max(
latencyOverBudget,
worstLatencyOverBudget,
);
if (latencyOverBudget) {
const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
}
// Set the latency on the interaction so future events can reference.
interaction.latency = latency;
// Log the updated metric values.
console.log({
worstLatency,
worstLatencyOverBudget,
totalLatencyOverBudget,
});
}
}
// Set the `durationThreshold` to 50 to capture keyboard interactions
// that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});
Обратная связь
Мы хотим призвать разработчиков опробовать эти новые показатели оперативности на своих сайтах и сообщить нам, если вы обнаружите какие-либо проблемы.
Отправьте общий отзыв об изложенных здесь подходах в группу Google, посвященную веб-показаниям, указав в теме письма «[Показатели реагирования]». Мы очень ждем вашего мнения!