Диагностика медленных взаимодействий вручную в лаборатории

Узнайте, как перенести полевые данные в лабораторию, чтобы воспроизвести и выявить причины медленного взаимодействия с помощью ручного тестирования.

Jeremy Wagner

Опубликовано: 9 мая 2023 г.

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

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

Что делать, если у вас нет данных о полях?

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

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

Чтобы выяснить TBT вашей страницы, вы можете использовать Lighthouse . Если TBT страницы высокий, существует вероятность того, что основной поток слишком занят во время загрузки страницы, и это может повлиять на скорость отклика страницы в этот решающий момент ее жизненного цикла.

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

Независимо от того, есть ли у вас полевые данные или нет, следующим шагом будет вручную протестировать и воспроизвести медленное взаимодействие, потому что только тогда, когда вы сможете воспроизвести медленное взаимодействие, вы сможете его исправить.

Воспроизводите медленные взаимодействия в лаборатории

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

Живые показатели панели «Производительность» DevTools

Профилировщик производительности DevTools — это рекомендуемый подход к диагностике заведомо медленных взаимодействий, но определение медленных взаимодействий может занять время, если вы не знаете, какие взаимодействия являются для вас проблемными.

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

Экран показателей в реальном времени на панели «Производительность».

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

Записать след

Профилировщик производительности Chrome — рекомендуемый инструмент для диагностики и устранения неполадок медленного взаимодействия. Чтобы профилировать взаимодействие в профилировщике производительности Chrome, выполните следующие действия:

1. Откройте страницу, которую хотите протестировать.
2. Откройте Chrome DevTools и перейдите на панель «Производительность» .
3. Нажмите кнопку «Запись» в левом верхнем углу панели, чтобы начать трассировку.
4. Выполните действия, которые вы хотите устранить.
5. Нажмите кнопку «Запись» еще раз, чтобы остановить отслеживание.

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

Сводная информация о действиях в верхней части профилировщика производительности Chrome. Длинные задачи выделяются красным цветом над диаграммой активности. В этом случае большая часть работы в длительной задаче выполнялась значительной работой по написанию сценариев.

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

После того как вы сосредоточились на том, где произошло взаимодействие, дорожка «Взаимодействия» поможет вам выровнять взаимодействие и действие, произошедшее на дорожке основного потока под ней:

Взаимодействие, профилированное в профилировщике производительности в Chrome DevTools. На дорожке «Взаимодействия» отображается серия событий, соответствующих взаимодействию с щелчком мыши. Записи отслеживания взаимодействий охватывают задачи, отвечающие за управление взаимодействием.

Вы можете получить дополнительную информацию о том, какая часть взаимодействия была самой продолжительной, наведя указатель мыши на взаимодействие на дорожке взаимодействий:

Всплывающая подсказка, которая появляется при наведении курсора на взаимодействие на дорожке взаимодействий панели производительности. В подсказке отображается, сколько времени было потрачено на каждую часть взаимодействия.

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

1. Входная задержка — отображается левым усом.
2. Продолжительность обработки — отображается сплошным блоком между левым и правым усами.
3. Задержка презентации — визуализируется правым усом.

Отсюда следует углубиться в проблему(ы), вызывающую медленное взаимодействие, которая рассматривается далее в этом руководстве.

Как определить, какая часть взаимодействия происходит медленно

Взаимодействия состоят из трех частей: задержки ввода, продолжительности обработки и задержки представления. То, как вы оптимизируете взаимодействие для снижения INP страницы, зависит от того, какая его часть занимает больше всего времени.

Как определить длительные задержки ввода

Задержки ввода могут привести к высокой задержке взаимодействия. Задержка ввода — это первая часть взаимодействия. Это период времени с момента, когда действие пользователя впервые получено операционной системой, до момента, когда браузер может начать обработку первого обратного вызова обработчика событий этого взаимодействия.

Определить задержки ввода в профилировщике производительности Chrome можно, найдя взаимодействие на дорожке взаимодействий. Длина левого уса указывает на часть задержки ввода взаимодействия, а точное значение можно найти во всплывающей подсказке, наведя курсор на взаимодействие в профилировщике производительности.

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

Задержка ввода, вызванная задачей, запущенной таймером из стороннего скрипта. Левая часть усика во взаимодействии, показанном на дорожке взаимодействий, визуализирует задержку ввода.

На предыдущем рисунке задача из стороннего скрипта выполняется, когда пользователь пытается взаимодействовать со страницей, и, следовательно, увеличивает задержку ввода. Расширенная задержка ввода влияет на задержку взаимодействия и, следовательно, может повлиять на INP страницы.

Прочтите, чтобы узнать больше: Для получения дополнительной информации о том, как устранить длительные задержки ввода, прочтите о том, как можно определить и уменьшить задержку ввода .

Как определить длительную продолжительность обработки

Обратные вызовы событий запускаются сразу после задержки ввода, и время, необходимое для их завершения, называется длительностью обработки . Если обратные вызовы событий выполняются слишком долго, они задерживают представление браузером следующего кадра и могут значительно увеличить общую задержку взаимодействия. Длительная длительность обработки может быть результатом дорогостоящего использования собственного или стороннего JavaScript, а в некоторых случаях и того, и другого. В профилировщике производительности это представлено сплошной частью взаимодействия на дорожке взаимодействий.

Обратные вызовы событий, которые выполняются в ответ на нажатие кнопки мыши, как показано в профилировщике производительности в Chrome DevTools. Обратите внимание на большую продолжительность обработки.

Обнаружение дорогостоящих обратных вызовов событий можно выполнить, наблюдая в трассировке определенного взаимодействия следующее:

1. Определите, является ли задача, связанная с обратными вызовами событий, длинной задачей . Чтобы более надежно отображать длинные задачи в лабораторных условиях, вам может потребоваться включить регулирование ЦП на панели производительности или подключить Android-устройство низкого или среднего уровня и использовать удаленную отладку .
2. Если задача, запускающая обратные вызовы событий, является длинной задачей, найдите записи обработчика событий — например, записи с такими именами, как «Событие: щелчок», — в стеке вызовов, которые имеют красный треугольник в правом верхнем углу записи.

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

1. Делайте как можно меньше работы. Все ли, что происходит при дорогостоящем обратном вызове события, строго необходимо? Если нет, рассмотрите возможность полного удаления этого кода, если это возможно, или отложите его выполнение на более поздний момент, если вы не можете. Вы также можете воспользоваться функциями фреймворка. Например, функция мемоизации React может пропустить ненужную работу по рендерингу компонента, если его реквизиты не изменились.
2. Отложите работу, не связанную с рендерингом, в обратном вызове события на более поздний момент времени. Длинные задачи можно разбить, передав их основному потоку . Всякий раз, когда вы уступаете основному потоку, вы завершаете выполнение текущей задачи и разбиваете оставшуюся часть работы на отдельную задачу. Это дает средству визуализации возможность обрабатывать обновления пользовательского интерфейса, которые были выполнены ранее в обратном вызове события. Если вы используете React, его функция переходов может сделать это за вас.

Эти стратегии должны помочь вам оптимизировать обратные вызовы событий, чтобы их запуск занимал меньше времени.

Как определить задержки презентации

Длительные задержки ввода и длительность обработки — не единственные причины плохого INP. Иногда обновления рендеринга, которые происходят в ответ даже на небольшие объемы кода обратного вызова событий, могут быть дорогостоящими. Время, необходимое браузеру для отображения визуальных обновлений пользовательского интерфейса, отражающих результат взаимодействия, называется задержкой представления .

Важно: Руководство по производительности рендеринга — хорошее руководство для понимания того, как браузер отображает страницу. В книге «Жизнь пикселя» подробно рассказывается о том, как работает рендеринг в браузерах на базе Chromium.

Задачи рендеринга, как показано в профилировщике производительности Chrome. Правый ус визуализирует длительность задержек презентации.

Работа по рендерингу чаще всего состоит из таких задач, как пересчет стиля, компоновка, покраска и компоновка, и они представлены фиолетовыми и зелеными блоками на диаграмме пламени профилировщика. Общая задержка представления представлена ​​правым усом взаимодействия на дорожке взаимодействий.

Важно: при профилировании медленных взаимодействий из-за дорогостоящих работ по рендерингу следует включить флажок «Снимки экрана» в верхней части профилировщика производительности. Это поможет вам согласовать обновления пользовательского интерфейса с соответствующей работой по рендерингу в основном потоке.

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

• Большие размеры DOM. Работа по рендерингу, необходимая для обновления представления страницы, часто увеличивается вместе с размером DOM страницы. Дополнительные сведения см. в статье «Как большие размеры DOM влияют на интерактивность и что с этим можно сделать» .
• Принудительная перекомпоновка. Это происходит, когда вы применяете изменения стиля к элементам в JavaScript, а затем немедленно запрашиваете результаты этой работы. В результате браузер должен выполнить работу по макету, прежде чем делать что-либо еще, чтобы браузер мог вернуть обновленные стили. Дополнительные сведения и советы о том, как избежать принудительного перекомпонования, см. в статье «Избегайте больших, сложных макетов и их искажений» .
• Чрезмерная или ненужная работа в обратных вызовах requestAnimationFrame . Обратные вызовы requestAnimationFrame() запускаются на этапе рендеринга цикла событий и должны завершиться, прежде чем можно будет представить следующий кадр. Если вы используете requestAnimationFrame() для выполнения работы, не связанной с изменением пользовательского интерфейса, помните, что вы можете задержать следующий кадр.
• Обратные вызовы ResizeObserver . Такие обратные вызовы выполняются до рендеринга и могут задержать представление следующего кадра, если работа над ними дорогая. Как и в случае с обратными вызовами событий, отложите любую ненужную логику для следующего кадра.

Важно! Устранение неполадок можно упростить, включив эксперимент «Временная шкала: инициаторы событий» в Chrome DevTools. Включение этого эксперимента приведет к отображению стрелки от любой задачи пересчета стиля к задаче JavaScript, которая ее запустила. Чтобы включить этот эксперимент, зайдите в настройки Chrome DevTools, нажмите «Эксперименты» в меню слева, затем установите флажок «Временная шкала: инициаторы событий» и перезапустите DevTools.

Что делать, если вы не можете воспроизвести медленное взаимодействие?

Что, если ваши полевые данные показывают, что конкретное взаимодействие происходит медленно, но вы не можете вручную воспроизвести проблему в лаборатории? Есть несколько причин, по которым это может быть так, но одна важная причина заключается в том, что ваши обстоятельства при тестировании взаимодействия зависят от вашего оборудования и сетевого подключения. Вы можете использовать быстрое устройство с быстрым соединением, но это не значит, что ваши пользователи тоже. Вы можете попробовать одну из трех вещей, если это применимо к вам:

1. Если у вас есть физическое устройство Android, используйте удаленную отладку , чтобы открыть экземпляр Chrome DevTools на вашем хост-компьютере и попытаться воспроизвести там медленное взаимодействие. Мобильные устройства зачастую не так быстры, как ноутбуки или настольные компьютеры, поэтому на этих устройствах легче наблюдать медленное взаимодействие.
2. Если у вас нет физического устройства, включите функцию регулирования ЦП в Chrome DevTools .
3. Возможно, вы ждете загрузки страницы, прежде чем взаимодействовать с ней, но ваши пользователи этого не делают. Если вы используете быструю сеть, смоделируйте более медленную сеть, включив регулирование сети , а затем взаимодействуйте со страницей, как только она отобразится. Это следует сделать, поскольку основной поток часто бывает наиболее загружен во время запуска, и тестирование в этот период времени может выявить, что испытывают ваши пользователи.

Устранение неполадок INP — это итеративный процесс.

Выяснение того, что вызывает высокую задержку взаимодействия, которая способствует плохому INP, требует большой работы, но если вы сможете точно определить причины, вы уже на полпути. Следуя методическому подходу к устранению неполадок с плохим INP, вы сможете точно определить причину проблемы и быстрее найти правильное решение. Чтобы просмотреть:

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

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