Лабораторные и полевые данные производительности

В предыдущем уроке мы задали сценарий загрузки speed-lab и условия сравнения. Такой эксперимент отвечает на вопрос: что происходит при выбранном устройстве, сети и состоянии страницы? Он ещё не отвечает на вопрос о большинстве посетителей настоящего сайта. Чтобы не смешивать эти результаты, рассмотрим лабораторные и полевые данные.

Для этой страницы не нужны реальные посещения ProfessorWeb. Мы используем придуманный набор наблюдений и объясняем способ его чтения. Лабораторные исходники серии не запускались автором, а учебные таблицы не являются отчётом сайта. Практический результат урока — правильно выбрать источник данных для конкретного вывода и заметить границы его применимости.

Условия эксперимента и условия аудитории

Лабораторное исследование намеренно фиксирует условия. Вы открываете известный документ, выбираете профиль CPU и сети, выполняете одинаковые действия. Такой подход позволяет искать механизм: какая задача задерживает кадр, почему изображение обнаружено поздно, что изменилось после переноса одной операции. Если условия плавают одновременно с исходниками, причинное объяснение теряется.

Полевые данные формируются при настоящих посещениях. У людей различаются устройства, сети, кеш, положение вкладки и сценарии чтения. Один читатель сразу откроет карточки, другой прокрутит половину статьи, третий вернётся по истории. Распределение этих ситуаций и составляет опыт аудитории. Контролируемая трасса остаётся полезной, но описывает только часть возможных условий. Различие lab и field.

У большой учебной библиотеки различаются и типы документов. Главная содержит подборки, текстовый урок — много абзацев, глава с диаграммами — изображения. Если хорошее значение получено для главной, его нельзя автоматически переносить на все статьи. Сначала разделите страницы на группы по шаблону и сценарию; затем выбирайте характерные документы внутри каждой группы.

Точно так же настольный результат не заменяет мобильный. На широком экране крупнейшим элементом может быть схема, а на узком — заголовок. Процессор компьютера быстрее обрабатывает сценарии карточек; состояние кеша у постоянного читателя отличается от нового перехода из поиска. Такие различия не являются ошибкой инструмента: он исследует своё окружение.

Как прочитать процентиль

Процентиль — граница упорядоченного набора, относительно которой находится выбранная доля наблюдений. Он нужен потому, что одно среднее значение плохо описывает опыт медленной части аудитории. Для Core Web Vitals используется 75-й процентиль посещений в соответствующей группе устройств. Рассмотрим учебный массив для освоения самой идеи; это не статистика реального сайта.

const illustrativeLcpMs = [900, 1100, 1400, 1600, 1900, 2300, 3100, 4700];
const sorted = [...illustrativeLcpMs].sort((a, b) => a - b);
const nearestRank = sorted[Math.ceil(sorted.length * 0.75) - 1];
console.log(nearestRank); // Ожидаемое учебное значение: 2300.

Для восьми придуманных чисел метод ближайшего ранга выбирает шестой элемент. Шесть наблюдений не превышают 2300 миллисекунд, а два превышают. Обратите внимание: это не максимальное значение и не время каждого читателя. Метод расчёта назван явно, поскольку разные способы интерполяции на маленьком массиве способны дать другие числа.

В настоящем отчёте учитываются правила источника данных и достаточность набора. Наш листинг показывает арифметическую идею, но не воспроизводит весь процесс CrUX или собственного мониторинга. Нельзя загрузить несколько ручных запусков и назвать полученный процентиль полевым. Название источника связано с тем, где и при каких посещениях были собраны записи.

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

Почему два отчёта расходятся

У PageSpeed Insights могут быть лабораторный результат и доступные данные CrUX. Не следует читать оба как повтор одного эксперимента. CrUX описывает допущенные в набор реальные посещения и временное окно, а лабораторная загрузка относится к конкретному прогону. Кроме того, данные могут относиться к URL либо ко всему origin; подпись области отчёта является частью результата. Состав отчёта PageSpeed Insights.

Если у страницы недостаточно подходящих данных, отсутствие полевого значения не означает ни прекрасную скорость, ни отсутствие пользователей. Это означает, что данный источник не показывает достаточный набор для выбранной области. В новом учебном стенде на localhost полевого отчёта ожидать не нужно: его назначение — ручное исследование собственных действий.

Частая ситуация: свежая лабораторная версия стала быстрее, а полевой отчёт пока почти не меняется. Прежние посещения ещё участвуют в окне, часть людей получает старые ресурсы, а новая версия могла затронуть только отдельный шаблон. Сначала проверьте даты, область и доставленную версию, затем связывайте изменение со статистикой. Нельзя приписывать эффект публикации одному совпадению дат.

Другая ситуация возникает с INP. Обычная лабораторная загрузка без взаимодействий не содержит сценария ввода в наш фильтр. Низкая нагрузка при старте не доказывает быстрый ответ после набора запроса. Нужна отдельная запись действий. Метрика TBT способна помочь обнаружить блокирование, но она не является заменой полного полевого INP. Назначение Total Blocking Time.

Сведение источников в одну задачу

Для speed-lab начнём с гипотезы о фильтре: синхронная обработка карточек может задерживать реакцию на ввод. Лабораторная трасса позволит увидеть участок работы и сравнить порционную обработку. Позднее в настоящем приложении полевые данные помогут понять, насколько часто этот сценарий оказывается проблемным и на каких устройствах. Эти шаги дополняют друг друга.

Создадим небольшую карточку расследования. Она соединяет пользовательскую группу с воспроизводимым экспериментом:

Область: страницы с фильтром карточек
Полевой сигнал: пока отсутствует; не подставлять учебные числа
Лабораторный сценарий: ввод Markdown, затем CSS
Независимая переменная: размер порции обработки
Проверяемый механизм: длительность работы Main и следующий кадр
Результат функции: текущий запрос, одинаковое количество совпадений

Пустая строка полевого сигнала здесь честнее выдуманной метрики. Для локального черновика достаточно объяснить механизм и оставить явное ограничение. Когда появится разрешённый процесс мониторинга, нужно заранее определить, какие данные собираются, как группируются страницы и как не включать чувствительные пользовательские значения. Сбор аналитики — самостоятельная задача, для которой есть курс аналитики.

Размер группы и смысл сравнения

Если мобильная группа содержит мало наблюдений, необычное посещение может заметно изменить её процентиль. Поэтому рядом с итоговой величиной полезно понимать достаточность набора и правила источника. Для собственной аналитики этот вопрос требует заранее заданного метода; нельзя менять способ отбора после каждого неудобного значения. Учебный массив из восьми чисел иллюстрирует операцию, но именно по этой причине не является надёжной моделью аудитории.

Сравнивая два периода, также проверьте состав посещений. Например, стало больше переходов на главы с изображениями, хотя сами шаблоны не изменились. Итог группы может ухудшиться из-за другого набора страниц. Разделение по характерным типам помогает отличить такое изменение от регрессии кода. Затем лабораторная трасса конкретного шаблона даёт возможность исследовать механизм найденной проблемы.

Завершите урок разделением трёх утверждений. Первое: «в моей трассе операция занимает определённое время». Второе: «у выбранной аудитории есть распределение задержек». Третье: «изменение исходников повлияло на это распределение». Каждое требует собственного основания. С таким разделением вы сможете читать даже расходящиеся отчёты, сохраняя полезные сведения из каждого, и перейти к исследованию сетевой цепочки.

Оглавление курса