Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome.
Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда.
Вкладка Performance
Думаю, многие пользователи DevTools видели эту вкладку. Некоторые, скорее всего, даже заходили внутрь, но вскоре закрывали, не поняв, чем она полезна в работе.
Вообще, основная функциональность этой вкладки ориентирована на разработчиков, а не на тестировщиков. Выискивать медленные frontend-модули в нагрузочном профиле — это в большей степени задача отладки кода, а не поиска дефектов. Но есть несколько моментов, полезных в тестировании производительности страницы для QA.
Демонстрацию проведу вот на этом специальном демо-сайте от Google. Он представляет собой анимацию с летающими вверх-вниз квадратами. Интерфейс включает в себя кнопки управления, с помощью которых можно:
добавить 10 новых летающих квадратов;
убрать 10 старых летающих квадратов;
остановить или начать движение квадратов;
включить или отключить оптимизацию анимации на сайте.
Приступим. Открываем вкладку Performance на нашем сайте и знакомимся с начальным экраном. Сразу уточню: по ходу повествования время от времени будут встречаться дополнительные пояснения, которые касаются интересующих меня моментов.
Кнопка Record. После её нажатия все последующие действия складываются в будущий нагрузочный профиль. Останавливается запись кликом по кнопке Stop в новом окне. После нажатия нагрузочный профиль будет сформирован и отобразится на этой вкладке.
Всего Performance предлагает три варианта создания профиля нагрузки: по кнопке Record, по кнопке Record and reload и по кнопке Load profile (например, от коллеги QA). Вариант с кнопкой Record подходит, когда вам хочется измерить известный сквозной сценарий нагрузочным профилем, скажем, при загрузке на сайт видео.
Кнопка Record and reload. После нажатия страница обновляется и начинается сбор активности вкладки для последующего складывания в нагрузочный профиль. Формирование профиля остановится автоматически после полной загрузки страницы, либо (как и в предыдущем варианте) при нажатии по кнопке Stop. После автоматической или ручной остановки нагрузочный профиль будет сформирован и отобразится на этой вкладке.
Эта фича хорошо подходит для тестирования производительности страницы при первом открытии и отлично сочетается с чекбоксом Disable network cache.
Кнопка Clear. При нажатии удаляются все сохраненные профили нагрузки (не только текущий!).
Кнопка Load profile. При нажатии активируется файловый менеджер вашей ОС, через него можно найти и загрузить сохранённый профиль нагрузки.
Кнопка Save profile. Нажимаете — активируется файловый менеджер вашей ОС с предложением сохранить в любую удобную вам папку профиль нагрузки.
При создании бага в производительности сайта файл профиля нагрузки с подтверждением проблемы может стать очень полезным (если не единственным) артефактом.
Активный профиль. Здесь будет отображаться выбранный профиль нагрузки. Одновременно на вкладку можно загрузить несколько профилей нагрузки — через это поле можно переключаться между ними. Каждый профиль состоит (слева направо) из маленькой превьюшки с сайтом, линии нагрузки на процессор, длительности профиля нагрузки и времени, когда этот профиль был загружен.
Чекбокс Screenshots. Активированный до записи профиля нагрузки чекбокс позволяет снимать в процессе формирования профиля скриншоты каждого кадра. Эти скриншоты можно будет посмотреть в разделе Frames на таймлайне профиля нагрузки, о которой мы поговорим ниже. Деактивированный чекбокc, соответственно, отключает запись скриншотов при формировании профиля нагрузки.
Выпадающий список профилей Network. Здесь то же самое, чем многие из вас пользовались в DevTools во вкладке Network: возможность искусственно замедлять скорость интернета. Присутствуют как встроенные профили сети (Fast 4G, Slow 4G, 3G и Offline), так и ваши кастомные. Можно переиспользовать профили, уже созданные вами во вкладке Network. Или создать новый профиль по кнопке Add. Сейчас я не буду создавать новый профиль, это тема для отдельной статьи.
Мы в команде часто пользуемся этой возможностью Chrome. При замедленном интернете все проблемы видны гораздо отчётливее. При написании плана тестирования веб-приложения надо держать в уме, что вы будете тестировать, вероятно, на быстром Wi-Fi, но гостем сайта может стать пользователь, вышедший в сеть из глухой тайги. Скорость соединения в таком случае будет напоминать далекие 2000-е, когда для входа в интернет использовали 64-килобитные модемы (многие вспомнят характерный звук его подключения). Это не говорит о том, что ваш сайт должен летать на любой, даже самой низкой скорости интернета, но он должен полностью загрузиться на любой скорости. Опцию нужно задать до старта формирования профиля нагрузки.
Выпадающий список профилей CPU. Если сайт быстро работает на вашем Macbook M3, то это не значит, что он будет так же быстро работать на более слабом компьютере или мобильном устройстве. Держать под рукой два компьютера (мощный и слабый) не всегда возможно. Эту проблему решает функция имитации медленного процессора. Можно имитировать четырёхкратное, шестикратное и двадцатикратное замедление от текущего показателя. Разумеется, выставлять это условие тоже необходимо до старта формирования профиля нагрузки.
Кнопка Settings. Открывает/скрывает возможность управления дополнительными настройками.
Чекбокс Disable network cache. При активации отключает кеш на сайте, позволяя имитировать первый заход пользователя на сайт. При отключении, соответственно, имитирует ситуацию, когда пользователь находится на сайте не первый раз.
Запись профиля
Что ж, давайте попробуем уже записать какой-нибудь профиль! Чекбоксы Screenshots и Disable network cache включены, кликаем по кнопке Record and reload… И идем заваривать чай, создание профиля может занять время.
Результат на первый взгляд покажется перегруженным информацией, на второй взгляд… Тоже. Но давайте всё-таки попробуем разобраться! Я вновь подчеркну, что в рамках этой статьи рассматриваю исключительно интересующие меня моменты.
На картинке выше представлен профиль нагрузки. Условно разделим его на три блока: верхний (красный), средний (белый) и нижний (зеленый). Дальше я так и буду их именовать.
Верхний блок профиля содержит таймлайн, при наведении на которую можно увидеть скриншот каждого кадра. Можно изменять видимую область профиля специальными ползунками по обе стороны от верхнего блока. Ими можно управлять тремя способами:
левой кнопкой мыши (растягивать и сужать);
клавишами WASD (W — сужает интервал, S — расширяет интервал, A — сдвигает интервал влево, D — сдвигает интервал вправо);
колёсиком мыши (прокрутка от себя — сужает интервал, прокрутка на себя — расширяет интервал).
Средний блок профиля содержит больше всего информации, давайте разбираться по картинке.
Здесь семь секций, но мы с вами сегодня поговорим лишь о двух первых — Network и Frames.
Секция Network. Раскроем её и пробежим по описанию, для удобства я также приближу таймлайн.
Здесь отображаются подгружаемые с сервера ресурсы: стили, JS, картинки и прочее, что видно из легенды секции. Конкретно у меня я вижу подгрузку CSS-стилей, JS-файл и логотип, который, судя по таймлайну, загружался дольше всего — примерно 200 мс.
Наведём курсор на файл с логотипом.
Видно, что из 200 мс примерно половину времени заняла обработка запроса, и ещё половину — непосредственно подгрузка логотипа.
Пользуясь этой вкладкой, можно оценить параллельность потоков подгружаемых ресурсов и скорость их загрузки (которая напрямую зависит от размера файла), а также увидеть, из чего состояло время запроса ресурса.
Увы, мне не удалось пока поймать проблемы, идём дальше.
Секция Frames
Для человеческого глаза комфортным считается отображение анимации с частотой не ниже 60 кадров в секунду, такой режим обеспечивает наиболее плавную картинку. Путём несложных арифметических вычислений получаем, что один кадр должен занимать не более 16 миллисекунд. На рендеринг каждого кадра Chrome тратит несколько миллисекунд. То есть один кадр должен занимать ещё меньше — до 10 миллисекунд. Чем большую нагрузку выдаёт сайт, тем дольше будут отрисовываться фреймы. В некоторых случаях это приводит к к фризам UI: изображение может зависнуть или начать отображаться рывками, как слайд-шоу.
В секции Frames можно покадрово разобрать весь профиль нагрузки и оценить скорость рендеринга кадров браузером. Здесь видно, что мои кадры рендерились за 8,3 мс — отличный показатель, FPS должен быть больше или60.
Все секции среднего блока строятся друг относительно друга по времени и относительно верхнего блока, что очень удобно при разборе.
Нижний блок профиля содержит графики метрик Frontend, меня интересуют пока только два: JS Heap и Nodes — отключим для удобства наблюдения остальные.
Метрика JS Heap показывает потребление ресурсов, взятых JS Heap. Бесконтрольный рост этого графика обозначает утечки памяти, на которые можно указать фронтенд-разработчику. В нашем случае потребление работает корректно.
Метрика Nodes показывает загруженность DOM-дерева тегами, атрибутами, текстом — всё это на языке браузера зовется Nodes. Чрезмерное количество нод утяжеляет страницу и снижает производительность сайта. В нашем случае всё пока в пределах нормы.
Что ж, пока что мы не обнаружили проблем на сайте! Попробуем ещё раз — на этот раз профиль будет создаваться по кнопке Record. После нажатия мы будем постепенно увеличивать количество летающих квадратов и определим, при каком количестве начнутся проблемы.
Жмем кнопку и дожидаемся плашки с информацией о начале сбора профиля. Затем нажимаем 13 раз на кнопку сайта Add 10, с интервалом примерно в секунду, и наконец нажимаем Stop. Итоговый профиль представлен на скриншоте.
Вот теперь мы нащупали проблему. Об этом свидетельствует красная линия в верхнем блоке, она появилась в тот момент, когда мы добавили 100 летающих кубиков. Эта линия означает просадку по FPS, заметную для глаза пользователя.
Для удобства работы я разметил на скриншоте в нижнем блоке моменты, когда я нажимал кнопку Add 10 — эти нажатия совпадают с пиками графика Nodes, поскольку инициируют дополнительные теги в DOM.
Причина просадки FPS понятна: на таймлайне в верхнем блоке также отображается текущая загрузка процессора. В какой-то момент (примерно после добавления 30 блоков) она стала ощутимо расти, а в момент добавления 100 блоков упёрлась в полку (100 %).
С этим можно работать. Если ожидается, что ваш сайт должен тянуть эту нагрузку без проблем, то это повод заводить баги на разработку.
Вместо заключения
Напомню ссылку на первую статью о подмене трафика в DevTools. И сейчас я готовлю третью статью о другом инструменте мониторинга производительности в DevTools — Performance monitor.
Чтобы не пропустить новые руководства, приходите в наше сообщество, там мы делимся разным полезным и публикуем вакансии.
Напишите в комментариях, какие ещё возможности DevTools вам было бы интересно разобрать? Если я работаю с этими инструментами, то включу их в цикл статей! Спасибо за внимание.