Веб-команда Zalando обнаружила, что интеграция Lighthouse CI обеспечивает упреждающий подход к производительности с автоматическими проверками статуса, позволяющими сравнивать текущий коммит с основной веткой, чтобы предотвратить снижение производительности.
Zalando — ведущая европейская онлайн-платформа о моде, имеющая более 35 миллионов активных клиентов. В этом посте мы объясняем, почему мы начали использовать Lighthouse CI, простоту внедрения и преимущества для нашей команды.
В Zalando мы знаем взаимосвязь между производительностью веб-сайта и доходом. Ранее мы тестировали, как искусственное увеличение времени загрузки страниц каталога влияет на показатели отказов, коэффициенты конверсии и доход на одного пользователя. Результаты были очевидны. Увеличение времени загрузки страницы на 100 миллисекунд привело к увеличению вовлеченности при более низком показателе отказов и увеличению дохода за сеанс на 0,7%.
100 мс
Улучшение времени загрузки страницы
0,7 %
Увеличение дохода за сеанс
Заинтересованность компании не всегда приводит к результатам
Несмотря на сильную заинтересованность в производительности внутри компании, если производительность не является критерием доставки продукта, она может легко ускользнуть. Когда мы занимались редизайном веб-сайта Zalando в 2020 году, мы сосредоточились на предоставлении новых функций , сохраняя при этом превосходный пользовательский опыт, а также обновили веб-сайт с помощью специальных шрифтов и более ярких цветов. Однако, когда обновленный веб-сайт и приложение были готовы к выпуску, показатели первых пользователей показали, что новая версия работает медленнее. Первая Contentful Paint работала на 53 % медленнее, а измеренное время взаимодействия показало на 59 % медленнее.
Интернет в Zalando
Веб-сайт Zalando создается основной командой, разрабатывающей структуру, и более 15 функциональных групп создают микросервисы внешнего интерфейса . Поддерживая новую версию, мы также перевели часть нашего веб-сайта на более централизованную архитектуру.
Предыдущая архитектура под названием Mosaic включала способ измерения производительности страницы с помощью собственных показателей. Однако перед внедрением на реальных пользователей было сложно сравнить показатели производительности, поскольку у нас не было внутренних лабораторных инструментов мониторинга производительности. Несмотря на ежедневное развертывание, обратная связь от разработчиков, работающих над улучшением производительности, длилась около одного дня.
Web Vitals и Lighthouse спешат на помощь
Мы не были полностью удовлетворены нашими собственными показателями, поскольку они плохо адаптировались к нашей новой настройке. Что еще более важно, они не были ориентированы на качество обслуживания клиентов. Мы перешли на Core Web Vitals , поскольку они предоставляют сжатый, но при этом полный и ориентированный на пользователя набор показателей.
Чтобы улучшить производительность перед выпуском, нам нужно было создать подходящую лабораторную среду . Это обеспечило воспроизводимые измерения в дополнение к условиям тестирования, представляющим наш 90-й процентиль полевых данных. Теперь инженеры, работающие над повышением производительности, знали, на чем сосредоточить свои усилия, чтобы добиться максимального эффекта. Мы уже использовали отчеты аудита Lighthouse локально. Итак, нашей первой итерацией была разработка сервиса на основе модуля узла Lighthouse , где изменения можно было бы протестировать из нашей промежуточной среды. Это дало нам надежный цикл обратной связи по производительности продолжительностью около часа, что позволило нам привести производительность на один уровень и сохранить наш релиз!
Предоставление обратной связи по производительности разработчикам по запросам на включение
Мы не хотели останавливаться на достигнутом, поскольку хотели воспользоваться возможностью не только реагировать на производительность, но и проявлять инициативу. Переход от модуля узла Lighthouse к серверу Lighthouse CI (LHCI) оказался не слишком сложным. Мы выбрали самостоятельное решение, чтобы обеспечить лучшую интеграцию с существующими услугами компании. Наше серверное приложение LHCI создается в виде образа Docker, который затем развертывается в нашем кластере Kubernetes вместе с базой данных PostgreSQL и отправляет отчеты на наш GitHub.
Наша платформа уже предоставляла разработчикам некоторую информацию о производительности — размеры пакетов компонентов сравнивались с пороговыми значениями при каждом коммите. Теперь мы можем сообщать метрики Lighthouse в виде проверок статуса GitHub. Это приводит к сбою конвейера CI, если они не соответствуют пороговым значениям производительности, со ссылкой на подробные отчеты Lighthouse, как показано на следующих изображениях.
Расширение охвата производительности
Мы начали с очень прагматичного подхода. В настоящее время Lighthouse работает только на двух наших наиболее важных страницах: домашней странице и странице сведений о продукте. К счастью, Lighthouse CI позволяет легко расширять конфигурации запуска. Функциональные группы, работающие над конкретными страницами нашего веб-сайта, могут настроить соответствующие шаблоны URL-адресов и утверждения. Благодаря этому мы вполне уверены, что охват нашей производительности увеличится.
Теперь мы гораздо увереннее создаём более крупные релизы, а разработчики могут наслаждаться гораздо более коротким циклом обратной связи по производительности своего кода.