При виде панели performance из devtools хрома у любого человека глаза начинают лезть на лоб. Пользуются ей далеко не все фронтенд разработчики, а умеют пользоваться очень немногие.
И я, к сожалению, не отношусь к таким, но некоторые моменты полезные новичкам хочу рассказать, а заодно попрошу опытных людей поделиться опытом использования. Достаточно долго я обходил этого монстра стороной, пугаясь обилия разнородной информации. Но этот график может быть чертовски полезен для определения слабых мест приложения в плане производительности. Я бы хотел на конкретном примере показать как поверхностно читать эти графики и куда смотреть, чтобы не пугаться, а получать от них пользу.
рисунок 1 — панель performance из devtools браузера chrome
На хабре есть немало материалов по этой теме, один из достаточно простых и свежих это https://habr.com/ru/companies/sberbank/articles/937334/, здесь показано как пользоваться инструментами и другие поверхностные вещи.
Но я бы хотел немного углубиться и описать как читать эти диаграммы, откуда их начинать читать, чтобы новички не пугались этих пестрящих графиков. Попробую сделать это на живом примере замера производительности на сайте dzen яндекса. Подсвечу любопытные наблюдения, несостыковки в подсказках и другие неочевидные моменты которые делают восприятие и работу с данной панелью сложной.
Начать надо с самого верха, а именно с разноцветной диаграммы вверху экрана — она относится к типу «диаграмма с областями», на ней мы можем наблюдать разноцветные графики визуализации загрузки cpu задачами из вкладки. Точно описать как считается эта загрузка, что вообще туда относить, а что нет я не могу, здесь надо погружаться в особенности не только движка браузера, но и в особенности ОС и архитектуры ПК. В моем представлении ОС и браузер выделяют некоторый ресурс cpu, и загрузка на этом графике имеет относительные значения и показывает насколько вкладка использует ресурсы выделенные именно ей. Нагруженность cpu считается суммарно по потокам, но основным потоком является main thread, загруженность которого вместе со стеком вызовов можно наблюдать на диаграмме Main, расположенной в нижней части панели в центральной части рисунка 1 (на рисунке она развёрнута).
Если приглядеться на скриншот ниже, то можно заметить, что у верхней диаграммы справа есть лейбл — cpu, внимание на рисунок 2.1, это говорит о том, что графики показывают чем в рамках вкладки был занят центральный процессор в течении времени, будем называть этот график временной диаграммой cpu.
рисунок 2.1 — метки CPU и NET на временной диаграмме
Именно эта диаграмма является временной шкалой всего пространства, именно она содержит визуальную временную информацию о производительности исследуемого сайта.
Используя её мы можем перемещаться во времени, выделять участки, создавать дочерние участки и удалять их. Сразу же стоит заметить, что на временном cpu графике шкала времени немного не совпадает с шкалой времени диаграмм ниже (у всех этих диаграмм и в том числе у Main одна шкала), виной тому скроллбар в правой части диаграмм. Это один из первых моментов, делающих работу с панелью менее удобной.
Диаграмма Main это визуализация стека вызовов из основного потока — main thread. По своему типу эта диаграмма является перевернутым flamegraph — рисунок 2.2, далее будем её называть диаграмма Main. На ней по оси X в самом верху отображаются задачи основного потока, они закрашены серым цветом и отмечены названиями Task, это корневые задачи, насколько я понимаю, это макрозадачи из очереди задач браузера, и они не должны занимать больше 50мс времени, а по оси Y вниз — отображаются дочерние задачи из стека вызовов корневой задачи.
рисунок 2.2 — таски main потока крупным планом
Цвета же позволят понять каким именно видом работы был занят процессор — увидеть что они означают можно посмотрев вкладку Summary в нижней части окна — рисунок 3, в ней будут перечислены суммарные временные затраты на активном участке диаграмме — если он выделен или за все время если участок не выделен.
Цвета на этом графике полностью идентичны цветам на некоторых других диаграммах (но не всех) и соответствуют определенному виду работы. Перед тем как вы вкратце перечислим цвета и задачи им соответствующие, стоит упомянуть что не всегда цвета на flamegraph и временной cpu диаграмме совпадают. В первую очередь потому, что на диаграмме cpu некоторые графики окрашены в серый цвет, хотя в main в это время выполнялась задача с другим цветом на flamegraph, так происходит потому, что некоторые задачи хоть и относятся к определённым типам работ и имеют цвет, но cpu напрямую не грузят. Этот момент может немного запутать новичка при работе с панелью.
рисунок 3 — расшифровка цветов
Список цветов и соответствующие типа работ:
-
Жёлтым — обозначается выполнение js кода, кстати это цвет логотипа языка js;
-
Фиолетовым — вычисление стилей (recalculate styles) и компоновка элементов (layout), это первоначальное вычисление размеров и положения и reflow — последующие вычисления размеров и положения;
-
Серым — внутренние процессы браузера, не относящиеся напрямую к коду страницы;
-
Зелёным — подготовка к отрисовке пикселей, сперва paint — подоготовка инструкций, а затем commit — отправка слоев на отрисовку gpu, там слои сформированные на этапе layout превраюащются в пиксели;
-
Синим — загрузка документов, но не сетевая, а их подготовка, сюда попадает парсинг html кода, парсинг css, обработка сетевых запросов (ожидание запросов сюда не входит);
-
Голубым — обмен сообщениями между потоками, например с iframe и web workers.
На рисунке 1 на flamegraph (диаграмма Main) вы можете заметить помимо вышеперечисленных цветов и другие цвета, в моём случае это бирюзовый, светло-зеленый и лиловые цвета, это не отдельные типы работ, это браузер выделяет отдельными цветами задачи выполнявшихся скриптов, у которых имеется sourceMap о чём говорит приписка «:sourcemap» в конце ссылки на файл, цвета же формируются на основе имени файла. То есть по идее эти задачи могли быть окрашены в цвет выполнения скриптов — в желтый. Но куда удобнее, что они имеют разный цвет чтобы не путать соседние таски.
Вернемся к временной диаграмме cpu и более детально с ней познакомимся. Мы можем выделить нужный нам участок, чтобы более детально его рассмотреть. Для этого кликнем левой кнопки мыши в том месте на диаграмме, где начинается интересующие нас события, и не отпуская передвинем курсор до той точки диаграммы в которой будет конец участка, после чего отпустим клавишу.
рисунок 4 — выделение нужной области на временной диаграмме cpu
В результате мы увидим выделенную зону, а сверху кнопку со значком лупы, нажав на неё наш участок растянется на всю ширину диаграммы, Main и остальные диаграммы также будут отображать выделенную область. Над временным графиком cpu появятся хлебные крошки — ссылки по которым можно переключаться между выделенными областями. Внутри выделенной области можно выделить свою дочернюю область. При нажатии на таску из Main на временной cpu зоне будет выделен соответствующий ему временной участок, точнее сказать вся остальная часть временной cpu зоны будет окрашена в серые цвета.
рисунок 5 — три области для рассмотрения
Давайте повнимательнее рассмотрим нашу временную диаграмму cpu и диаграмму main. Сперва напомню что разные цвета это разные типы задач которыми занимался процессов, серый цвет это не цвет фона, а браузерные процессы, которыми он занимается в свободное от наших задач время, но иногда их нет, и тогда фон будет абсолютно белый, значит процессор в это время не выполнял работу связанную с нашей вкладкой.
Сперва рассмотрим участок 1, на нём видно, что вкладка браузера полностью использовала выделенный ей ресурс cpu сперва для парсинга html — это синий график, затем на выполнение js скриптов — жёлтый график. При этом в нижней части области видим что на Main в этот момент выполнялась одна таска (серая полоса) — созданная для парсинга html (голубая полоса) и при этом, прямо во время неё, до её окончания начал выполняться скрипт (желтая полоса под синей полосой), а для этого движок браузера должен сначала скомпилировать его, поэтому опускаясь вниз вглубь стека находится ещё одна жёлтая полоса с надписью ‘Compile script’.
Как вы видите, любая вышестоящая задача по времени окончится только после того как закончится последняя нижестоящая задача. Для того чтобы точно узнать время выполнения каждой из задач надо навести мышку на задачу, при этом появится тултип с информацией об общем времени выполнении таски (оно может окончится с самой последней дочерней таской) и о длительности непосредственно процесса самой таски.
Заметьте, ситуация наблюдаемая на участке 1 наглядно демонстрирует, что при встрече браузерного движка со скриптом во время парсинга html, парсинг html будет заблокирован выполнением скрипта.
Теперь рассмотрим участок 2, на временной диаграмме cpu видны фиолетовые графики вычисления стилей (тут как я понимаю элементам html за счет каскадирования сопоставляются css свойства) и серый график системных ресурсов, можно заметить, что хоть при этом в main выполнялась длительная задача на вычисление layout, но на временной диаграмме процессор был занят системными задачами и он окрашен в серый, а не фиолетовый. Возможно вычислительных ресурсов самого cpu на layout не требуется и он освобождается под системные задачи, либо же, layout и вызвал эти системные задачи.
Также можно заметить что фиолетовые css задачи на диаграмме Main имеют красный треугольник-флажок в правом верхнем углу, это сигнал браузера о том, что данный пересчет затронул слишком много элементов и ресурсов браузера и является «узким горлышком» в производительности сайта. Если нажать на данную layout задачу, то внизу появится подробная информация по ней — рисунок 6, наверху будет warning о том, что произошёл forced reflow (принудительная перекомпоновка).
рисунок 6 — подсказка о forced reflow
Внизу панели Summary будет кнопка Insight forced reflow, если на неё нажать, то слева откроется панель с общим списком проблемных скриптов вызвавших подобные проблемы на main диаграмме, а не только связанных с данной задачей. Вернемся к панели summary, судя по подсказке-warning это принудительный пересчет макета, когда код заставляет браузер немедленно пересчитать геометрию страницы прямо во время выполнения скрипта. Но в данном случае это не так, и данная подсказка вводит в заблуждение.
Данная layout задача, это самая первая задача, она была запланирована во время начального парсинга html и чтобы в этом убедиться вы можете проследить откуда на данную задачу идёт стрелка, её конец вы можете увидеть на рисунке 6, прямо перед выделенной таской layout. А ниже, на рисунке 7 скриншот с таской откуда начинается стрелка, как вы видите это очень узкий прямоугольник, находящийся по временной отметке сразу под началом полосы parse html, это самая первая таска и находится в начале временной шкалы. При клике на этот узкий прямоугольник можно увидеть подсказку, что это и есть инициатор начального recalculate style.
рисунок 7 — проследим причину «forced reflow»
Что интересно, в начале временной диаграммы есть вертикальная чёрная полоса — это начало отсчёта времени, все что левее неё содержит отрицательные временные метки, в этот момент браузер еще не начал замерять производительность, судя по информации с гугла, в данный отрезок может входить запуск движка профилирования, выгрузка из памяти старой страницы и прочие внутренние браузерные телодвижения. Если же бы мы выделили другие проблемные фиолетовые recalculate и layout таски, вызванные не изначальным парсингом страницы, то для них можно посмотреть что конкретно привело к данному forced reflow, для этого надо посмотреть список ссылок на скрипты, которые выведутся прямо в Summary после нажатия на проблемную таску.
Вернемся к нашим recalculate и layout таскам, если снова посмотрите на область 2, её я перенес вниз на рисунок 8.1, то увидите что обе этих задачи, входят в одну серую таску выше, при этом часть этой серой таски справа заштрихована красным цветом и также имет красный треугольник флажок. Красным цветом заштрихована область такси, которая выходит за отведенное время выполнения в 50мс.
рисунок 8.1 — область 2 из рисунка 6 крупным планом
Давайте повнимательнее рассмотрим полосу на которой расположены recalculate и layout таски: помимо этих двух длинных полос, в этом же ряду есть две коротких фиолетовых и две коротких зеленых, при чем последняя зеленая очень узкая. Первая фиолетовая это pre-paint — подготовка результатов предыдущих задач к отрисовке, затем идёт зеленая paint — тут происходит формирование инструкций по отрисовке для каждого слоя, затем идет фиолетовая — layerise, тут происходит разбиение на композитные слои, а затем идёт очень узкий зелёный прямоугольник — это commit задача, она отправляет слои и инструкции на отрисовку в поток gpu. На рисунке не видно, но в самом низу панели есть полоса-диаграмма gpu, похожая на main, в ней есть только зелёные полосы — это и есть работа графического процессора по отрисовке пикселей.
Теперь обратите внимание на верхнюю часть области 2, в ней над временным графиком проходит бледно-розовая полоска с маленькими красными отрезками, эта полоса проходит ровно поверх серой таски вышедшей за временной лимит в 50 мс, а красные отрезки на ней находятся над красными флажками на тасках ниже. Таким образом эта верхняя полоса позволяет оценить насколько временной график был занят долгими задачами.
Перейдем к последней области — третей, на ней над серым графиком есть очень маленькая желтая заштрихованная область, прямо над цифрой 3. Диагональной штриховкой обозначается активность вне главного потока, в данном случае это была активность из пула фоновых потоков, на рисунке не видно, но в панели ниже диаграммы main и над диаграммой gpu есть диаграмма thread pool, на ней можно было увидеть задачи которые выполнялись как раз в этот момент, в моём случае это был парсинг и компиляция изначально загруженных скриптов, поэтому штриховка выполнена жёлтым цветом.
рисунок 8.2 — область 3 из рисунка 6 крупным планом
Последнее что я хотел бы рассмотреть в данном материале, это тонкие голубая и синяя полосы прямо под временным графиком cpu. У правой границы рисунка на уровне этих полос есть лейбл NET (рисунок 2), подсказывающий, что эти графики относятся к сети, а именно, что они являются индикаторами сетевой загрузки. Они подсказывают происходили ли сетевые загрузки в данный момент времени: если загружались критичные ресурсы, то полоса синяя, если некритичные — голубая, если полос нет, значит ничего не загружалось.
Для более подробной информации по сетевой активности можно развернуть диаграмму Network, находящуюся над диаграммой Main — рисунок 9.
рисунок 9 — сетевая активность
Рассмотрим рисунок 9, на нем в самом верху видно длинный сетевой запрос html с наивысшим приоритетом, он длился более секунды, параллельно ему ниже происходили менее приоритетные загрузки скриптов, они начались ещё до окончания его загрузки — это результат работы preload scanner он сканирует html и заранее ставит в очередь найденные скрипты. Одновременно с этим на Main диаграмме видно, что еще до окончания загрузки html происходит его парсинг, под ним видно желтые таски — это выполнение инлайн скриптов, затем фиолетовые — расчет стилей.
Интересно заметить что приоритетная загрузка изначального html на яндекс дзен занимает так много времени, попробуем понять почему. Нажмём на этот сетевой запрос, внизу в summary появится информация о сетевом запросе (рисунок 10), в том числе перечисление сетевых этапов формирующих общую длительность. Самым долгим этапом является отправка запроса и ожидание — 1.1 секунды.
рисунок 10 — панель summary и insights
Внизу панели есть три кнопки с инсайтами о сетевых запросах, нажмём первую — document request latency. Справа появится панель Insights с информацией о сетевых задержках, наверху в блоке document request latency видно подсказку с красным маркером — Server responded slowly (observed 1.10 s). Получается, что сервера яндекса очень долго отвечали при запросе документа html, возможно это связано с недавними инфраструктурными проблемами яндекса.
На этом я заканчиваю беглое рассмотрение панели performance на примере загрузки сайта dzen от яндекс, надеюсь вы смогли узнать что-то новое и полезное по работе с данной панелью, а новички стали меньше её бояться. Вполне возможно где-то я ошибся, прошу поправить.
Источник: habr.com