Разбор регрессии скорости
После изменения сайта показатель может стать хуже, хотя автор рассчитывал на ускорение. Иногда причина находится в новом коде, иногда — в составе наблюдений или ошибке инструмента. Регрессией удобно назвать ухудшение сопоставимого результата, но эта формулировка сама по себе ещё не указывает виновный файл. В заключительном уроке продолжения научимся строить причинный разбор.
Используем знакомые стенды, синтетический CSV и пустую карточку advanced/notes/regression-record.md из архива примеров. Ни один приведённый сигнал не получен в измерениях ProfessorWeb. Мы подготовим порядок исследования и условия решения; команды, стенды и измерения автором не выполнялись.
Сначала сформулируем пользовательский результат
Представим учебное изменение каталога: дополнительный модуль помогает выбрать материал, но после его добавления читатель позже получает доступный список. Нельзя ограничиться фразой «страница стала медленной». Нужно назвать действие: открыть каталог, прочитать названия, найти конкретный урок или перейти на его страницу. Разные действия могут зависеть от разных частей системы.
Для разбора запишите начало и конец сценария, необходимое содержимое и прежнее поведение. Если кнопка раньше показывала все материалы, а новая версия скрывает половину записей, более быстрое отображение не сохраняет исходную функцию. Проверка производительности должна сопровождаться проверкой полноты результата. Это особенно важно для учебного сайта, где старые ссылки остаются путями к содержимому.
Бюджет производительности задаёт условия до изменения. Разбор регрессии работает с уже замеченным сигналом и выясняет, почему условие нарушено либо выглядит нарушенным. Не переписывайте бюджет задним числом, чтобы новая версия автоматически считалась приемлемой. Если условия действительно изменились, обоснуйте это отдельным решением.
Проверим договор источника
Первый вопрос — каким способом появился показатель. Полевые данные, лабораторная запись и диагностический снимок имеют разные границы. Условное значение lcp_like_ms из нашего CSV вообще придумано для арифметики. Оно не превращается в измеренный LCP после загрузки в таблицу. Название поля, источник и метод должны сохраниться в отчёте.
В плане диагностического сбора наблюдатель прекращает запись при первом скрытии или pagehide. Если другая версия продолжила считать события после восстановления, сравниваются разные жизненные циклы. Аналогично смена формулы CLS или способа выбора навигаций может изменить результат без изменения страницы. До поиска проблемы в интерфейсе проверьте версии самого инструмента.
Запишите объём группы, пропуски поддержки и правила исключения. Отсутствующая запись не равна быстрому посещению, а выбор только медленных наблюдений не описывает обычную аудиторию. Если неизвестно, почему строка попала в набор, вывод о версии становится слабым. Сначала восстановите договор данных, затем переходите к причинным гипотезам.
Разберём знакомый синтетический сигнал
В учебном CSV две группы по восемь строк. По методу ближайшего ранга p75 у условной версии B меньше, чем у A, но верхние значения B больше. Арифметика подробно разобрана в уроке о процентилях. Эти числа не описывают реальную аудиторию и не дают статистической уверенности в регрессии.
Тем не менее пример показывает полезный вопрос: одинаково ли изменились типичный сценарий и хвост? Один агрегат может скрыть неоднородность. Просмотрите распределение и число записей, не делайте вывод только по средней величине. При малом наборе высокий процентиль зависит от отдельных строк и особенно чувствителен к случайному составу.
В настоящем разборе разделите шаблоны страниц, условия устройства и типы навигаций. Если новая группа содержит больше холодных загрузок, смешанный показатель способен ухудшиться даже при прежнем поведении каждой категории. Сопоставляйте одинаковые сегменты; итоговый состав аудитории обсуждайте отдельно от скорости внутри сегмента.
Построим несколько причинных гипотез
Теперь вернёмся к условному каталогу. Новая функция могла добавить запрос, увеличить выполнение программы или расширить DOM. Эти причины дают разные следы. Для каждой сформулируйте ожидаемое изменение цепочки и наблюдение, которое могло бы опровергнуть объяснение. Не называйте виновным самый большой файл только потому, что он заметен в списке.
| Учебная гипотеза | Ожидаемый след | Раздельное сравнение |
|---|---|---|
| Ресурс обнаруживается поздно | Начало запроса сдвигается за зависимость | Сохранить код и изменить только путь обнаружения |
| Доставляется больше байтов | Увеличивается переданное тело | Сохранить содержимое и исследовать представление |
| Добавилась тяжёлая обработка | Данные готовы, но действие ждёт Main | Сохранить доставку и отложить конкретную работу |
| Расширился отображаемый список | Больше элементов, стилей и размещения | Сохранить набор данных и изменить представление |
Таблица — карта проверки, а не полученный trace. Для анализа собственной записи используйте документацию Chrome Performance. Сопоставляйте события Network и работу главного потока с пользовательским действием. Длительность одной функции не равна автоматически всей задержке взаимодействия.
Изменим одну причину в управляемом опыте
В resource-lab виджет загружается по отдельной кнопке. Можно сравнивать момент загрузки модуля и момент его монтирования, но эти две операции следует разделить. Если одновременно убрать виджет, сократить карточки и изменить сеть, опыт покажет новую комбинацию, а не стоимость одной зависимости. Для дальнейшего решения такой результат недостаточно определён.
Сохраните одинаковую версию текста, viewport, CPU, сеть и способ навигации. Отдельно укажите HTTP-кеш и восстановление из bfcache: это разные механизмы. Чередуйте условия в повторной ручной серии, чтобы временная нагрузка устройства не совпадала всегда с одной версией. Не выбирайте удачную попытку исправления против неудачной исходной.
Ожидаемый эффект нужно записать до наблюдения. Например: «исключение автоматического монтирования должно убрать соответствующую работу до чтения списка; функция остаётся доступной кнопкой». После выполнения читатель отмечает, изменился ли именно этот участок. Если след не совпал с ожиданием, гипотезу пересматривают, даже когда общий показатель случайно выглядит лучше.
Функция ограничивает допустимое исправление
Уменьшение DOM через постраничный список сохраняет доступ к данным при наличии работающей навигации. Виртуальное окно требует более сложного договора: поиск по странице не видит отсутствующие строки, фокус и доступность нуждаются в отдельной реализации. Нельзя принять такое изменение только потому, что элементов стало меньше.
Для учебного каталога проверьте названия, обычные ссылки, переходы между частями и чтение клавиатурой. Старая статья должна оставаться достижимой по своему URL. Для отложенных ресурсов важна работоспособность после прокрутки и при неподдерживаемом дополнительном API. Перечислите эти условия рядом с показателем, чтобы отчёт не поощрял ускорение ценой исчезнувшего содержимого.
Бывает, что исправление помогает одной категории и ухудшает другую. Тогда запишите обе стороны и причину компромисса. Предварительная загрузка может сократить ожидание одного ресурса и занять канал раньше; изменение списка может облегчить отображение, но добавить действие перехода. Решение должно описывать именно сохранённый пользовательский путь.
Оформим решение и предел уверенности
Заполните карточку разбора: источник сигнала, сопоставимые условия, метод, гипотеза, независимое изменение, фактическое наблюдение читателя и функциональная проверка. Синтетические числа оставьте в отдельном файле. Если опыт ещё не проведён, поле результата остаётся пустым, а вывод называется ожидаемым, а не подтверждённым.
Укажите условие возврата к прежнему варианту. В учебном проекте это сохранение исходной версии отдельного изменения и понятного способа восстановить её функцию. Производственный выпуск и откат требуют собственной процедуры; данный урок их не выполняет. Не удаляйте старые материалы или ресурсы только ради того, чтобы скрыть обнаруженное ухудшение.
Финальная формулировка должна связывать причину и наблюдение: при каких условиях изменился нужный участок, что сохранилось и что остаётся неизвестным. Если данные недостаточны, правильный следующий шаг — уточнить наблюдение или повторить сопоставимый сценарий. Подготовленный отчёт уже является полезным результатом: другой разработчик понимает, почему выбранное действие обосновано и где заканчивается его доказательство.