Постоянное добавление новых функций в веб-приложение - отличный способ улучшить продукт и добавить дополнительную ценность для пользователей. Но если не обращать внимание на общую производительность веб-приложения, пользовательский опыт может пострадать, поскольку веб-приложение становится более громоздким, медленным и менее доступным.
Точно так же, как разработчики обращают внимание на качество кода, написав и запустив тесты, выполняя тест производительности кода на стороне сервера и выполняя статический анализ кода, также можно непрерывно проверять различные аспекты производительности UI / UX веб-приложения.
Один из способов сделать это - использовать инструмент под названием Lighthouse от Google, который встроен в браузер Google Chrome? Вы можете получить к нему доступ, открыв инструменты разработчика Chrome и перейдя на вкладку Audits.
Постоянно проверяя производительность веб-приложения, мы можем наблюдать за тенденцией производительности и быстрее обнаруживать понижение версии. В этом посте я хотел бы показать вам, как мы можем запускать тесты по расписанию, написав небольшой скрипт узла и периодически запуская его в конвейере сборки Azure DevOps.
Начнем со сценария
Исходный код доступен на https://github.com/AndrejsAbrickis/lighthouse-azure-devops
Вот что происходит, когда мы выполняем метод run.
- Сначала chrome-launcher запускает новый экземпляр браузера Google Chrome с предоставленным
chromeFlags(мы запускаем Chrome в автономном режиме с флагом--headless) и сохраняет номер порта запущенного экземпляра Chrome в параметрах. L8-L9 - Затем мы запускаем аудит маяка, предоставляя URL-адрес для аудита и параметры и сохраняя результаты аудита локально. Lighthouse связывается с браузером через порт, который мы сохранили на предыдущем шаге. L12
- Чтобы сгенерировать отчет JSON (альтернативный вариант - HTML), мы должны использовать метод
generateReport()ReportGenerator и передать объект результатов Lighthouse из предыдущего шага и тип вывода. L13 - В этом примере вывод записывается в файл results.json с использованием API файловой системы узла -
fs. L15-L23 - И, наконец, мы убиваем экземпляр chrome перед выходом из скрипта. L27
Для просмотра результатов можно перетащить файл results.json или вставить его содержимое в программу просмотра маяка Google Chrome на странице https://googlechrome.github.io/lighthouse/viewer/.
Настройка конвейера сборки Azure DevOps
Затем мы собираемся настроить конвейер сборки и запланировать запуск теста производительности каждый день на 9 утра. Но можно также использовать эту настройку для создания задач до и после развертывания в конвейере выпуска, чтобы измерить изменение производительности до и после выпуска рабочей версии или любого другого этапа выпуска.
Сначала мы собираемся создать новый пустой конвейер сборки. Мы собираемся использовать визуальный конвейер, разработанный, но также можно определить конвейер с помощью файла yaml.
Затем мы добавим две задачи npm для установки пакетов и запустим сценарий тестирования производительности, который определен в package.json как сценарий тестирования.
Наконец, мы добавляем задачу публикации артефактов сборки. Поскольку нас интересуют результаты аудита, мы публикуем файл results.json. Этот артефакт может быть повторно использован впоследствии в следующих задачах конвейера сборки или в конвейере выпуска.
После запуска конвейера сборки мы видим, что файл results.json доступен в качестве выходного артефакта сборки.
В конце концов, мы можем перейти к разделу триггеров конвейера и обновить конвейер сборки и включить запланированные запуски, например, каждый день в 9 утра или несколько раз в день.
С помощью этого простого скрипта и конвейера сборки Azure DevOps мы настроили запланированный тест производительности, который запускает контрольные проверки Google Chrome. Теперь мы можем загрузить файл results.json в хранилище BLOB-объектов Azure или в корзину AWS S3 для сбора и анализа данных о производительности с течением времени. Это позволит нам увидеть, как изменения в коде и конфигурации веб-приложения влияют на производительность веб-приложений. И, проводя тест перед каждой производственной версией, мы можем быть уверены, что не поставляем обновление, которое могло бы снизить производительность для наших конечных пользователей.
Если вы нашли этот пост полезным и хотели бы узнать больше о случайных темах веб-разработки, просто похлопайте по этой статье или оставьте здесь комментарий. И, как всегда, вы можете найти меня в Twitter @ andrejsabrickis.
