Эта статья была впервые опубликована в журнале Ben Fei Zhai.блоги ЧжихуКолонка интерфейса Ele.me
Сегодня я познакомлю вас с младшим братом семейства инструментов разработчика Chrome. До Chrome 57 он назывался «Временная шкала», а теперь у него более длинный жилет — «Производительность». Ведь имя «длинное~~~~~». ~~~~~~ ～～» может привлечь больше внимания.
Возможно, вы случайно запустили этот инструмент и у вас так же кружится голова, как и у меня, когда вы видите красочные диаграммы внутри. Но, представив его сегодня, я уверен, что вы будете знакомы с ним так же хорошо, как со швейцарским армейским ножом.
Эта панель называется «Производительность», но в названии не указано, что это за производительность. Поскольку это инструмент отладки Chrome, он должен быть связан со страницей, поэтому давайте начнем с производительности страницы.
Что влияет на эффективность вашей страницы
В последние годы веб-разработчики разработали ряд решений, позволяющих сократить время ожидания пользователей, чтобы «сокращать время». например сPWAКэшируйте больше доступных автономных ресурсов, чтобы веб-приложения открывались быстрее;WebAssemblyСпецификации уменьшают размер ресурсов и повышают эффективность выполнения. Эти решения сосредоточены на сетевых соединениях, скорости обработки внешних ресурсов и других параметрах и направлены на улучшение взаимодействия с пользователем.
Как веб-разработчик, я считаю, что производительность страницы тесно связана с несколькими параметрами: сетевые ссылки, ресурсы сервера, эффективность рендеринга внешних ресурсов и клиентское оборудование.
сетевая ссылка
Сетевые ссылки часто являются решающим фактором для производительности страницы.Разрешение доменных имен, коммутаторы, маршрутизаторы, поставщики сетевых услуг, сети распространения контента, серверы и узлы на ссылке неисправны или реагируют слишком медленно, и все это будет иметь негативные последствия.
ресурсы сервера
В среде HTTP все запросы в конечном итоге обрабатываются сервером, и если сервер не отвечает или отвечает слишком медленно, это напрямую влияет на взаимодействие между страницей и пользователем.
Внешний рендеринг ресурсов
Процесс, в котором браузер получает необходимые статические ресурсы, такие как HTML, CSS, скрипты и изображения, рисует первый экран и представляет его пользователю; или после того, как пользователь взаимодействует со страницей, браузер пересчитывает содержимое, которое необходимо для представления, а затем перерисовывает его. Эффективность обработки этих процессов также является важным фактором, влияющим на производительность.
Пользовательское оборудование
Инициирование сетевых запросов, синтаксический анализ сетевых ответов и рендеринг страниц потребляют аппаратные ресурсы компьютера. Таким образом, ресурсы компьютера, особенно когда ресурсов ЦП и ГП не хватает (например, игра в игры-убийцы видеокарты), также будут влиять на производительность страницы.
Конечно, вышеперечисленные размеры не рулят писаниной, это скорее соотношение собачий зуб. Например, во время рендеринга очень медленный отклик браузера.Возможно, скрипт написан слишком плохо и сталкивается с узкими местами в производительности.Также может быть, что игра-убийца видеокарты занимает слишком много ресурсов компьютера, например, когда анализируя отрисовку фронтенд-ресурсов, часто приходится совмещатьДиаграмма водопада сетиПроанализируйте время получения ресурсов, поскольку рендеринг страницы также является динамическим процессом, некоторые ключевые ресурсы нужно ждать, а некоторые могут быть загружены одновременно с рендерингом.
Зачем жертвовать производительностью
Каждый инструмент разработчика Chrome имеет свою собственную направленность. Например, каскадная диаграмма инструмента «Сеть» содержит подробную информацию о порядке извлечения ресурсов и фокусируется на анализе сетевых ссылок. Инструмент "Производительность" ориентирован на внешний процесс рендеринга. Он содержит такие модули, как гистограмма частоты кадров, диаграмма области использования ЦП, каскадная диаграмма ресурсов, диаграмма пламени основного потока и обзор событий. Они тесно связаны с рендерингом. Весь этап рендеринга. Однако вам не нужно беспокоиться об именах модулей, упомянутых выше, потому что на следующих страницах я буду представлять их один за другим.
Начните выступление с правильной осанки
Открытая производительность
Сначала открываем анонимное окно Chrome, в анонимной среде в браузере не будет дополнительных плагинов, пользовательских фич, кешей и прочих факторов, влияющих на повторяемость эксперимента. Затем запустите инструменты разработчика.Если ваше окно достаточно широкое, вы можете увидеть Производительность в 5-м столбце верхней панели вкладок.Если ширины недостаточно, вы можете использовать верхний правый>>кнопку, чтобы открыть вкладку «Дополнительно» и найти ее.
На данный момент мы видим загрузочную страницу производительности по умолчанию. Операция, соответствующая первой подсказке, заключается в том, чтобы немедленно начать запись всех событий, происходящих на текущей странице, а нажатие кнопки «Стоп» остановит запись. Соответствующая операция второго предложения - перезагрузить страницу и записать событие. Инструмент автоматически остановит запись, когда страница загружена и находится в интерактивном состоянии. Оба в конечном итоге сгенерируют отчет (генерация отчета требует много вычислений и займет некоторое время).
Теперь инструмент готов начать анализ страницы.
Простой анализ страницы
Во-первых, мы анализируем процесс простой страницы от пустой страницы до рендеринга. Все примеры страниц в этой статье помещаем в следующий репозиторий, клонируем и переключаемся в корневую директорию репозитория командой:
git clone git@github.com:pobusama/chrome-preformance-use-demo.git && cd chrome-preformance-use-demo
Затем установите зависимости:npm i
Наконец, запустите пример страницы:npm run demo1
Так как сложно понять время рендеринга страницы, мы собираем данные рендеринга с помощью второго метода перезагрузки и записываем процесс beforeunload -> unload -> Send Request (первый запрос ресурсов) -> load.
После того, как инструмент автоматически остановил запись, мы получили такой отчет:
Четыре области, очерченные на рисунке:
1: Панель управления, используемая для управления характеристиками инструмента. «Сеть» и «ЦП»: ограничение сетевых и вычислительных ресурсов соответственно, имитация различных терминальных сред и упрощение наблюдения за узкими местами в производительности. Включение параметра «Отключить образцы JavaScript» приведет к тому, что инструмент будет игнорировать регистрацию стека вызовов JS, к которому мы вернемся позже. Включение «Включить расширенные инструменты рисования» приведет к подробной записи деталей некоторых событий рендеринга. Мы поговорим об этой функции после того, как разберемся с этими событиями.
2: Обзорная панель с 3 графиками, описывающими частоту кадров (FPS), загрузку ЦП и сетевые ресурсы.частота кадровЭто индикатор, показывающий, сколько кадров изображения обрабатывается в секунду. Чем выше частота кадров, тем плавнее внешний вид. Ситуация в сети представлена в виде каскадной диаграммы, на которой прослеживается время загрузки и последовательность каждого ресурса. Диаграмма областей использования ЦП на самом деле представляет собой непрерывную гистограмму с накоплением (увеличенная версия диаграммы областей ЦП ниже представляет собой схематическую диаграмму, и данные не соответствуют строго):
Вертикальная ось — это загрузка ЦП, горизонтальная ось — время, а разные цвета представляют разные типы событий, среди которых:
- Синий: загрузка события
- Желтый: сценарии событий
- Фиолетовый: событие рендеринга
- Зеленый: событие рисования
- Серый: Другой
- Idle: браузер бездействует
Например, первый столбец диаграммы: общая загрузка ЦП равна 18, а события загрузки (синие) и события работы скрипта (желтые) разделены пополам (9). По мере увеличения времени использование ЦП событиями операций сценария постепенно увеличивается, в то время как использование событий загрузки падает до 0 примерно через 600 мс; с другой стороны, использование событий рендеринга (фиолетовый) сначала увеличивается, а затем падает, и становится равным 0 около 1100 мс. Общая картина может четко отражать, какой процент использования ЦП занят какими событиями в какой период времени.
3: Панель потока используется для наблюдения за подробными событиями.Вы можете увидеть детали графика потока, сузив диапазон наблюдения на панели обзора. График пламени основного потока — это основной график, используемый для анализа производительности рендеринга. В отличие от «обычного» флейм-графа, флейм-граф, показанный здесь, инвертирован, то есть верхний слой — это родительская функция или приложение (выглядит как небольшая вертикальная черточка) представляет вершину стека вызовов функций. По умолчанию график пламени будет записывать каждый слой функций в стеке вызовов исполняемой JS-программы (с точностью до детализации одной функции), что очень подробно. Когда «Отключить образцы JS» включено, график пламени будет точным только до уровня события (вызов функции в файле JS является событием), игнорируя все стеки вызовов функций в событии.
Кроме того, диаграмма последовательности потоков кадров (Кадры) и каскадная диаграмма сети (Сеть) могут отображать нарисованную страницу и загрузку ресурсов с временного измерения соответственно.
4: Панель сведений. Инцидент уже упоминался много раз, и я думаю, что если я не объясню его, мне могут прислать клинок. В инструменте «Производительность» самым детальным уровнем всех записей являются события. Событие здесь относится не к событию в JS, а к абстрактному понятию, мы открываем флейм-граф основного треда, нажимаем квадрат по желанию, после чего можем посмотреть детали события в панели деталей, включая название события, время события, информация о запуске и т. д. Приведем несколько примеров: Parse HTML — это событие загрузки (синий цвет), которое указывает, что во время события Chrome выполняет свой алгоритм синтаксического анализа HTML; событие — это событие Scripting (желтый цвет), которое указывает, что выполняется событие JS ( Например, щелчок); Paint — это событие рисования (зеленое), означающее, что Chrome будет рисовать составной слой.
Ниже приведены некоторые общие события. Хорошо иметь впечатление. Поскольку мы должны иметь дело с ними каждый раз, когда проводим анализ производительности, нам трудно их не помнить.
Другой очень важной частью панели сведений является круговая диаграмма времени события, в которой перечислены период времени по вашему выбору, различные типы событий (загрузка, операции скрипта, рендеринг, рисование, другие события, оцепенение :)) и затраченное время. Анализ соотношения имеет то же значение, что и анализ графика площади ЦП — какое событие вызывает узкое место в производительности.
До сих пор мы просмотрели основные функции инструмента «Производительность», хотя и не исчерпывающие, но этого достаточно, чтобы начать путешествие по анализу производительности. Далее, давайте проанализируем немного более сложную анимационную страницу, чтобы действительно понять, как эти данные диаграммы могут выявить проблемы с производительностью.
Недовольство процессом рендеринга в браузере
Знание процесса рендеринга браузера очень важно для нашего понимания и анализа Вот краткое введение в процесс рендеринга браузера:
При рендеринге первого экрана браузер анализирует файлы HTML и CSS соответственно и генерирует объектную модель документа (DOM) и объектную модель CSS (CSSOM); объединяет DOM и CSSOM в дерево рендеринга; вычисляет стиль; вычисляет каждую из них. точное положение и размер узла на экране (Layout); дерево рендеринга рисуется на слое в соответствии с положением, рассчитанным на предыдущем шаге (Paint); движок рендеринга синтезирует все слои и, наконец, виден человеческому глазу (Composite Слои).
Если вы меняете макет страницы, вы сначала обновляете DOM через JS, а затем переходите от процесса расчета стилей к синтезу изображений. Если это просто негеометрические изменения (цвет, видимость, преобразование), вы можете пропустить шаг компоновки.
Анализ анимации
Я полагаю, что после вышеупомянутых приготовлений вы начали готовиться. Давайте запустим еще одно демо в примере репозитория:cd chrome-preformance-use-demo && npm run demo2
В исходном состоянии 10 маленьких квадратов будут двигаться вверх и вниз с постоянной скоростью соответственно и возвращаться на исходный путь после попадания в границу браузера. «Добавить 10» — добавить 10 таких маленьких квадратов, «Вычесть 10» — уменьшить 10, «Стоп/Старт» — приостановить/начать движение всех маленьких квадратиков, а «Оптимизировать/Неоптимизировать» — оптимизировать/неоптимизировать анимацию.
Как браузер рисует кадр анимации
По умолчанию мы нажимаем кружок в левом верхнем углу, чтобы записывать события, а через несколько секунд мы можем нажать «Стоп» в разделе «Производительность», чтобы сгенерировать данные аналитики. На панели обзора мы видим, что после первых нескольких сотен миллисекунд доля различных событий на графике площади ЦП изменяется в соответствии с фиксированным периодом.Мы нажимаем на небольшой участок, чтобы наблюдать, и вы можете увидеть аналогичный участок на графике. основной поток поток группа событий. После наблюдения за несколькими группами событий мы обнаружили, что состав этих групп событий следующий: 10 циклов Пересчет стиля + Макет -> Обновить дерево слоев -> Рисовать -> Составные слои. Мы знаем, что после события Composite Layers человеческий глаз может видеть новый слой страницы, то есть после такого набора событий перед глазами рисуется рамка картинки.
Мы нажимаем на «Framse» в предыдущем столбце диаграммы пламени основного потока и обнаруживаем, что пунктирная линия вскоре после события Composite Layers — это узел, в котором появляется следующий кадр.
Когда появляются узкие места
Текущая анимация ничего не посмотрела, мы нажимаем кнопку DOUZEN Times «Добавить 10», чтобы увеличить количество квадратов, вы можете увидеть анимацию, есть четкий CATON (если оно не появляется, вы можете уменьшить оператор мощности CPU в управлении панель). Затем мы снова записали данные о производительности:
В отчете мы увидели много ярких красных точек, в том числе большую красную полосу на графике частоты кадров и маленькую угловую отметку на графике основного потока. Снова следуя предыдущей идее, просмотрев детали основного потока, мы обнаружили, что и события Recalculate Style, и события Layout, которые произошли в функции app.update, имеют предупреждения, указывающие на то, что узким местом производительности может быть принудительная перестановка. Введите файл js, чтобы просмотреть подробный код.В левом столбце вы можете видеть, что строки кода, которые занимают много времени, выделены темно-желтым цветом, поэтому эти коды, вероятно, будут ключевыми.
Примечание. Для автоматического расчета времени выполнения строки кода необходимо снять флажок «Отключить образцы JavaScript» в панели управления.
Итак, что не так с этой строкой кода и в чем заключается перестановка?
Поговорим о перестановке и перекраске
Короче говоря, перекомпоновка и перерисовка — это шаги, которые изменяют стиль страницы. Шаг переупорядочивания включает события типа рендеринга, такие как «Пересчет стиля», «Макет» и «Обновить дерево слоев», а шаг перерисовки включает события типа рисования, такие как «Рисование» и «Композитные слои». После переупорядочения неизбежно произойдет перерисовка, а операции, вызывающие перерисовку, не обязательно приведут к перерисовке. Ниже перечислены некоторые распространенные операции, вызывающие перекомпоновку или перерисовку, другие операции можно найти вcsstriggers
Поскольку для расчета макета займет много времени, накладные расходы на гораздо больше, чем у перераспределения. В случае достижения того же эффекта, мы должны избегать максимально возможной перестановки. Например, если оба дисплея: ни одна и видимость: скрыты достаточно, то последнее лучше.
Устранение узких мест
Оглядываясь назад на нашу демонстрацию анимации, на панели сведений о производительности круговая диаграмма показывает большую часть доли рендеринга (перестановки) в процессе рисования анимации.Объединив с кодом, мы нашли причину: цикл только что дал DOM Много раз Получите позицию DOM через offsetTop сразу после обновления позиции стиля. Такая операция заставит начать перекомпоновку, потому что браузер не знает, изменилась ли позиция DOM в предыдущем цикле, и должен немедленно переразметить, чтобы вычислить позицию DOM. Не волнуйтесь, как вы могли заметить, у нас также есть кнопка «Оптимизировать».
В ответ на эту проблему наш план оптимизации состоит в том, чтобы заменить offsetTop на style.top.Хотя последний принимает позицию элемента предыдущего кадра анимации, он не влияет на вычисление позиции следующего кадра анимации, устраняя необходимо переставить и получить положение процесса, сокращая ненужные перестановки.
Примечание: В этом примере есть еще одна оптимизация, которая делается в случае неоптимизации, то есть черезrequestAnimationFrameФункция изменит все стили в цикле кадров (
m.style.top = pos + 'px';) накапливается и равномерно обрабатывается на следующем чертеже. Помимо оптимизации стиля операций записи, это позволяет более четко наблюдать проблемы, вызванные операцией чтения offsetTop.
Сравним отчеты до и после оптимизации:
Прежде всего, на круговой диаграмме и диаграмме области ЦП доля событий рендеринга снизилась, а доля событий рисования увеличилась. Из графика частоты кадров и графика потока кадров видно, что частота кадров значительно увеличилась, а время отрисовки одного кадра изображения значительно уменьшилось, что означает, что плавность анимации значительно улучшилась, а оптимизация цель достигнута. Присмотревшись к деталям, мы обнаружили, что в группе событий, отрисовывающей кадр анимации, отсутствуют события Recalculate style и Layout в функции app.update, а время выполнения всей функции значительно сокращается, что доказывает, что наша схема оптимизации сработала.
Ретроспектива и примечания
В этом обсуждении инструментов производительности мы начнем с факторов, влияющих на производительность страницы, а затем представим параметры, в которых хороши инструменты производительности:Внешний рендеринг ресурсов. Далее мы узнали о 4 основных панелях инструмента «Производительность»: «Управление», «Предварительный просмотр», «Поток», «Подробности» и нескольких полезных диаграммах: гистограмма частоты кадров, диаграмма области ЦП, диаграмма пламени основного потока, диаграмма времени потока кадров, круговая диаграмма времени потребления событий. Диаграмма. Затем они использовали их для обнаружения проблем с производительностью и работы над их устранением.
Однако проблемы с производительностью в реальной среде более сложны.При умелом использовании производительности нам необходимо запоминать факторы, влияющие на производительность.Эту часть знаний и опыта необходимо накапливать в реальном бою в течение длительного времени. Улучшение веб-производительности — интересная тема,Сайт веб-разработчика GoogleЕсть много хороших блогов, в которых это обсуждается, но в браузере нет никакой магии, просто выберите Performance и получайте удовольствие~
Ссылаться на
Подробное объяснение управления производительностью веб-страницы