Неполное руководство по анализу производительности веб-страницы

внешний интерфейс Ресурсы изображений Icon Chrome

предисловие

Вы часто можете увидеть много статей об оптимизации производительности интерфейса в блогах или на форумах, но редко видите, как анализировать производительность веб-страницы. В конце концов, какие индикаторы (или стандарты) представляют собой хорошую или плохую производительность этой веб-страницы и как получить эти индикаторы? Поэтому в этой статье описывается, как анализировать хорошую и плохую производительность веб-страницы. Инструмент, использованный в этой статье: браузер Chrome. Давайте посмотрим на них один за другим.

Оценка производительности во время выполнения с моделями RAIL

Первое, что можно объяснить, так это то, что бегание производительности относится к производительности вашей веб-страницы во время работы, а не производительность загрузки. Модель Rail (Rescount-Animation-Load) - это центрированная пользовательская модель производительности, каждая сетевая приложение имеет четыре различных аспекта, связанных с его жизненным циклом, и эти аспекты влияют на производительность по-разному. Используйте официальную сетевую карту для подавления:

alt RAIL模型
Alt Rail модель

Далее описывается модель RAIL с четырех аспектов:

Ориентированный на пользователя

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

Задерживать Реакция пользователя
0~16 мс Люди особенно хорошо отслеживают движение, и если анимация не плавная, они будут возмущены этим. Пользователь может воспринимать плавный анимационный переход, отображающий 60 кадров в секунду, что составляет 16 миллисекунд на кадр (включая время, необходимое браузеру для отрисовки нового кадра на экране), а затем оставляя приложению всего около 10 миллисекунд на создание новый кадр.
0~100 мс Отвечайте на действия пользователей в течение этого времени, и они почувствуют немедленные результаты. Еще немного, и связь между действием и реакцией разрывается.
100~300 мс Пользователи испытывают слегка ощутимую задержку.
300~1000 мс В это время задержка ощущается как часть естественного и непрерывного развития задачи. Для большинства пользователей в Интернете загрузка страницы или изменение представления подобны выполнению задачи.
1000+ миллисекунд Через 1 секунду внимание пользователя будет отвлечено от задачи, которую он выполняет.
10 000+ миллисекунд Разочарованные пользователи могут отказаться от задания, а могут и не вернуться после этого.

Ответ: Ответ в течение 100 миллисекунд

У веб-сайта есть 100 миллисекунд, чтобы отреагировать на ввод пользователя, прежде чем пользователь заметит задержку. Это работает для большинства входных данных, таких как нажатие кнопок, переключение элементов управления формы или запуск анимации. Но не для сенсорного перетаскивания или прокрутки (поскольку сенсорное перетаскивание или прокрутка подпадают под категорию анимации). Если сайт не отвечает, связь между действием и реакцией нарушена, и пользователь это заметит. Таким образом, для операций, выполнение которых занимает более 500 мс, необходимо постоянно обеспечивать обратную связь.

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

Анимация: создание кадра за 10 мс (т. е. достижение 60 кадров в секунду)

Анимации — это не просто причудливые эффекты пользовательского интерфейса, такие как прокрутка и перетаскивание касанием, также являются типами анимации. Пользователи заметят, если изменится частота кадров анимации. Цель веб-сайта — генерировать 60 кадров в секунду, и каждый кадр должен выполнять все следующие шаги:

alt 渲染步骤
альтернативный шаг рендеринга

С чисто математической точки зрения бюджет на кадр составляет около 16 мс (1000 мс/60 кадров = 16,66 мс/кадр). Но также требуется время для отображения нового кадра на экране, поэтому на практике браузерВсего 10 мс для выполнения кода, если эта оценка не может быть достигнута, частота кадров упадет, а содержимое на экране будет дрожать, то есть заикаться, что негативно влияет на взаимодействие с пользователем. Поэтому, если возможно, лучше всего использовать 100 мс ответов для предварительной обработки дорогостоящей работы, чтобы сайты с большей вероятностью могли достичь производительности 60 кадров в секунду.

Простой: максимальное время простоя

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

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

Загрузка: рендеринг контента в течение 1000 мс

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

Сводка ключевых показателей RAIL

Чтобы оценить свой веб-сайт по показателям RAIL, вы можете использовать панель производительности Chrome DevTools (более старые версии Chrome могут использовать инструмент TimeLine) для записи действий пользователя (см. следующий раздел, объясняющий, как записывать данные о производительности). Затем проверьте время записи на панели по этим ключевым показателям RAIL.

ЖЕЛЕЗНАЯ ступень ключевой индикатор Действие пользователя
отклик Время задержки ввода (от касания до розыгрыша) составляет менее 100 мс. Пользователь нажимает кнопку (например, чтобы открыть навигацию).
анимация Каждый кадр работы (от JS до рисования) выполняется менее чем за 16 мс. Пользователь прокручивает страницу, проводит пальцем (например, чтобы открыть меню) или видит анимацию. При перетаскивании ответ приложения зависит от положения пальца (например, потяните, чтобы обновить, проведите пальцем, чтобы прокрутить). Этот показатель доступен только для непрерывной фазы перетаскивания, но не для начальной фазы.
праздный Работа основного потока JS делится на фрагменты не более 50 мс. Пользователь не взаимодействовал со страницей, но основного потока должно быть достаточно для обработки следующего пользовательского ввода.
нагрузка Страница может быть готова через 1000 мс. Пользователь загружает страницу и видит содержимое критического пути.

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

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

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

Готов к работе

Сначала открываем официальный сайтdemo, Обязательно откройте браузер в режиме инкогнито, чтобы убедиться, что браузер находится в чистой среде. В противном случае, если вы установите много расширений для браузера, это будет мешать вашим данным анализа производительности. Затем откройте DevTools, конкретный метод:Command+Option+I (Mac) or Control+Shift+I (Windows, Linux).

alt 图示
альтернативный значок

Имитация CPU мобильного телефона

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

  1. В DevTools нажмитеPerformanceпанель
  2. убедисьScreenshotsфлажок отмечен
  3. нажмитеCapture Settings(красный значок настроек в правом верхнем углу), разверните другие настройки
  4. Выбрать из процессора4x slowdown, DevTools ограничит частоту ЦП до четверти от обычной.

alt 图示
альтернативный значок

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

установить демо

  1. непрерывный щелчокAdd 10кнопку, зная, что вы можете ясно видеть, что синее поле работает медленнее, чем раньше, и это может занять около 20 нажатий на высокопроизводительных компьютерах.
  2. нажмитеOptimizeкнопку, синее поле должно двигаться быстрее и плавнее.
  3. нажмитеUn-Optimizeкнопка, синий квадрат движется медленнее и свободнее.

    ПРИМЕЧАНИЕ. Если вы не наблюдаете заметного замедления, попробуйте нажать несколько разSubtract 10кнопку, чтобы повторить предыдущие шаги. В противном случае, если вы добавите слишком много синих полей, у вас закончатся ресурсы ЦП.

Рекордные беговые показатели

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

alt 图示
альтернативный значок

  1. нажмитеRecordкнопку (см. иллюстрацию), DevTools будет собирать показатели производительности во время работы страницы.
  2. подождите несколько секунд
  3. нажмитеStopкнопку (см. иллюстрацию), DevTools останавливает запись, начинает обработку данных, а затем отображает результаты обработки вperformanceпанель, как показано ниже

alt 图示
альтернативный значок

Результаты анализа

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

График кадров в секунду

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

alt 图示
альтернативный значок

График ЦП

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

alt 图示
альтернативный значок

Кстати, независимо от того, находится ли мышь над графиком FPS, CPU или NET, DevTools отобразит скриншот в этом временном узле, двигайте мышью влево и вправо, вы можете воспроизвести запись, это называется скраббинг, потому что это полезно для анализа прогресса анимации вручную.

alt 图示
альтернативный значок

Раздел кадров

В разделе «Кадры», если вы наведете указатель мыши на зеленый квадрат, он покажет значение FPS для этого конкретного кадра, которое в этом случае может быть значительно ниже целевого значения 60 кадров в секунду на кадр. Это правда, что в этом примере производительность этой страницы низкая и ее можно четко наблюдать, но в реальном сценарии это может быть не так просто, поэтому используйте все эти инструменты для всестороннего измерения.

alt 图示
альтернативный значок

Найдите узкие места (проследите корень)

Теперь, когда вы поняли и убедились, что производительность этой веб-страницы не является хорошей с помощью различных вышеперечисленных методов, почему она плохая? Из-за чего он так плохо работает?

Summary Tab

Если события не выбраны, на вкладке «Сводка» отображается разбивка активности процесса веб-страницы. Как вы можете видеть на картинке, эта страница тратит слишком много времени на рендеринг. Поэтому ваша цель — сократить время, необходимое для рендеринга.

alt 图示
альтернативный значок

Основной раздел

Разверните раздел «Основной», и DevTools отобразит график активного пламени с течением времени в основном потоке. Ось X представляет записи с течением времени, где каждая полоса представляет собой событие, и чем шире полоса, тем дольше длится событие. Ось Y представляет стек вызовов, и когда вы видите события, расположенные друг над другом, это означает, что верхнее событие вызвало нижнее событие.

alt 图示
альтернативный значок

Вы можете выбрать часть значков FPS, CPU или NET, щелкнув, прокрутив или перетащив мышь, а в разделе «Основной» и на вкладке «Сводка» будет отображаться только информация о записи выбранной части. УведомлениеAnimation Frame FiredЗначок красного треугольника в правом верхнем углу события — это предупреждение о том, что с этим событием возникла проблема.

нажмитеAnimation Frame Firedсобытие, на вкладке «Сводка» будет отображаться информация, относящаяся к событию.

alt 图示
альтернативный значок

Уведомлениеreveal, щелкните его, он выделит триггерAnimation Frame Firedсобытие событие.

alt 图示
альтернативный значок

Уведомлениеapp.js:95, щелкните по нему, он перейдет к исходному коду, соответствующему исходной панели, и соответствующему номеру строки.

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

существуетAnimation Frame FiredПод событием находится группа фиолетовых событий. Если вы расслабите их, вы увидите, что в правом верхнем углу каждого фиолетового события есть значок красного треугольника. Нажмите на одно из фиолетовых событий (на самом деле это событие «Макет»), на вкладке «Сводка» отобразится более подробная информация. Действительно, здесь есть предупреждение для REFLOW.

alt 图示
альтернативный значок

На вкладке Сводка щелкнитеRecalculation Forcedпоследующийapp.js:71, DevTools перейдет к строке кода, которая запускает принудительное перекомпонование.

alt 图示
альтернативный значок

Проблема с этим кодом в том, что каждый кадр анимации меняет стиль синих квадратов и вычисляет положение каждого квадрата на странице. Поскольку стиль изменился, браузер не уверен, изменилась ли позиция каждого блока, поэтому браузер может только переразметить блок, чтобы вычислить позицию блока. может просматриватьAvoid forced synchronous layoutsИз этой статьи вы узнаете, как избежать больших, сложных макетов и дрожания макета.

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

Выполните оценку производительности загрузки с помощью инструментов разработчика Chrome.

  1. Откройте страницу, которую хотите оценить
  2. Откройте панель производительности
  3. нажмитеStart profiling and reload page(Синяя рамка на картинке), DevTools записывает показатели производительности при перезагрузке страницы, а затем автоматически останавливает запись через несколько секунд после завершения загрузки.
  4. Другие методы анализа аналогичны описанной выше оценке производительности во время выполнения.

alt 图示
альтернативный значок

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

Суммировать

Вы можете использовать панель «Производительность» в DevTools браузера Chrome, чтобы получить данные о производительности загрузки и производительности веб-страницы.Согласно методу анализа, описанному выше, в сочетании с моделью RAIL для оценки производительности веб-страницы. Это очень эффективный метод. Как повысить производительность веб-страниц? Это еще одна большая тема. Я считаю, что в Интернете есть много связанных сообщений в блогах, на которые вы можете сослаться. Автор также опубликует соответствующие сообщения в блогах, когда у меня будет время.

использованная литература

Get Started With Analyzing Runtime Performance