Привет, Хабр. Меня зовут Антон, я работаю в группе нагрузочного тестирования ЮMoney и занимаюсь исследованием производительности. В статье расскажу про xk6-browser — что у нас было до него, какие у этого решения преимущества и метрики.

Чем мы пользовались до xk6-browser

Первое, о чём хочется сказать, — К6. Этот набор инструментов для нагрузочного тестирования мы использовали для моделирования нагрузки на основе HTTP (тестирование на уровне протокола). Про К6 подробно рассказывали на одном из наших мероприятий в прошлом году, советую перейти и посмотреть.

Пройдёмся по главным возможностям K6:

Основная функция K6 — генерация HTTP‑запросов для имитации взаимодействия пользователей системы.
Разделение логики на модули.
Сценарии на JavaScript.
Содержит большую экосистему расширений.
Гибкое хранение и визуализация показателей.

Второй инструмент, который мы используем в нашей команде для фронтенда, — утилита Lighthouse Launcher. Она предназначена для измерения метрик производительности веб‑интерфейсов. Главная функция утилиты — тестировать производительность на уровне веб‑интерфейсов (оценка скорости, стабильности веб‑приложений и получения метрик Web Vitals).

У утилиты есть ряд ограничений:

Мы проверяем только загрузку страницы, но не можем проверить элементы управления: корректную работу кнопок, полей ввода, навигацию, вкладки, ссылки, меню и так далее.
Тестирование производительности происходит только на уровне интерфейса и не взаимодействует с бэкендом. При таких проверках можно выявить проблемы исключительно на стороне интерфейса.
Lighthouse Launcher — это отдельный инструмент. То есть для проверки на уровне протокола К6, у которого свой набор сценариев на JavaScript, разработчику необходимо запускать и отдельную утилиту в совершенно другом формате, а также два разных набора тестов. Для комплексной проверки это неудобно и сложно, более рационально использовать один инструмент.

Новое решение — xk6-browser

Какие у него преимущества:

Гибридный подход. Это альтернативный подход к нагрузочному тестированию на основе браузера. Проверяет производительность на уровне и протокола, и веб‑интерфейсов в одном тесте.
Метрики под нагрузкой. За счёт гибридного подхода в сочетании с небольшим количеством виртуальных пользователей для тестирования браузера и с большим количеством пользователей для тестирования на уровне протокола мы получаем метрики под нагрузкой.
JavaScript и возможность переиспользовать сценарии K6. Также xk6-browser даёт возможность писать тесты в одном скрипте.

Что такое xk6-browser

Это расширение k6, которое позволяет поддерживать автоматизацию браузера.
Оно добавляет API для взаимодействия с браузером.
Cобирает показатели производительности веб-интерфейсов в рамках тестов К6.

Основное назначение модуля xk6-browser — тестировать производительность на уровне браузера. Это позволяет выявить проблемы, которые сложно обнаружить на уровне протокола, и, конечно же, определить максимальную нагрузку, при которой сайт продолжает работать стабильно. Также с помощью xk6-browser мы можем ответить на следующие вопросы:

Что происходит с интерфейсом, когда мы получаем тысячи запросов на уровне протокола?
Все ли элементы интерфейса интерактивны?
Как получить метрики, специфичные для браузера?

Метрики Web Vitals — основные показатели xk6-browser

Вот какие метрики мы используем в ЮMoney:

Largest Contentful Paint (LCP). Измеряет время загрузки самого большого элемента в области просмотра.
First Contentful Paint (FCP). Измеряет время, которое понадобится браузеру для отображения первой части содержимого.
Cumulative Layout Shift (CLS). Проверяет визуальную стабильность — не смещён ли макет из-за асинхронной загрузки ресурсов.
Time to First Byte (TTFB). Измеряет время между запросами ресурса и началом поступления первого байта ответа.

Также в документе по Web Vitals описаны все пороговые значения для каждой метрики. Мы используем эти значения в своих сценариях, что позволяет нам проверять производительность интерфейсов по единому стандарту.

Перейдём к практике: использование xk6-browser

Разберём, как просто написать сценарий, что такое гибридный подход и какие результаты после запуска теста мы получим.

Отмечу, что у xk6-browser полная совместимость с API Playwright (поэтому не нужно изучать новый API), а также есть поддержка асинхронных методов.

Для примера я выбрал наш сайт yoomoney.ru: вместе посмотрим, как написать сценарий перехода на страницу и взаимодействие с ней, а также на сбор основных метрик производительности по ней.

Что нам для этого потребуется:

Переход на страницу yoomoney.ru. Состоит из нескольких этапов: создание контекста и новой страницы → переход на yoomoney.ru с использованием метода goto() → закрытие страницы и браузера с использованием метода close(). Сценарий очень простой и понятный. Его достаточно, чтобы проверить работоспособность интерфейса.
Взаимодействие с веб-интерфейсом. Если нужно взаимодействовать с интерфейсом, можем добавить локаторы. В нашем случае в роли локатора выбрана кнопка входа на страницу yoomoney.ru или кнопка залогина. С помощью метода click() нажимаем на эту кнопку.

Попадаем на страницу ввода логина → выбираем локатор поля для ввода → вводим логин, используя метод type().

После этого выбираем локатор кнопки Submit и методом Click() нажимаем на неё.

Для ввода пароля проводим те же действия, что и для ввода логина.

После этого с помощью метода close() закрываем страницу и браузер.

Механизм проверки check(). Для проверок в К6 есть функционал чеков. Этот механизм позволяет убедиться, что все элементы на странице отображаются верно и что они загрузились. Метод очень простой: берём локатор, который хотим проверить, например кнопку входа, и с помощью метода isVisible() проверяем, загрузилась ли эта кнопка.
Пороговые значения thresholds. Чтобы запустить наш тест, выставляем пороговые значения для браузера. Ранее я уже говорил, что все они описаны в документации по Web Vitals.
Создаём гибридный тест: добавляем тест браузера к тесту K6. Основную нагрузку делаем на уровне протокола.

Метрики xk6-browser

Статистику по всем метрикам мы получаем в одном отчёте. Это очень удобно и практично. Видим отдельно блоки с метриками браузера, К6, а также блоки с чеками по используемым сценариям.

Таким образом, у нас есть простой и очень удобный инструмент для умного исследования производительности. Единственное, чего не хватает, — это отображение результатов тестов.

Где мы храним наши метрики

Мы используем Victoria Metrics как хранилище данных со стрельб.
Для представления метрик используем формат Prometheus.
Взяли за основу агрегирование данных, как у K6, и сделали Grafana-дашборд для xk6-browser. Выглядит он так:

Дашборд комплексный, на нём показаны все метрики продолжительности нашего теста.

Зелёным цветом выделены метрики LCP (измеряет скорость загрузки самого большого элемента в области отображения).
Фиолетовая линия — это количество наших виртуальных пользователей, которых мы используем в тесте.
Жёлтой линией отмечены наши пороговые значения.

Дашборд простой, информативный и понятный. На нём видно, что происходит с интерфейсом.

Для реализации наших решений в этом направлении нам нужна доступная и простая инструкция по использованию xk6-browser. Мы добавили в пользовательскую документацию раздел по xk6-browser с подробными примерами и ответами на все вопросы, которые могут возникнуть на этапе реализации.

Что мы получили в итоге

Гибридный подход в тестировании производительности. Мы можем контролировать производительность на уровне протокола и веб-интерфейсов. Этот подход даёт наиболее полное представление о том, как на самом деле работает наше приложение.

И ещё несколько плюсов гибридного подхода:

За счёт того, что весь функционал находится в одном инструменте, порог вхождения для любого пользователя/разработчика минимальный.
Проще написание сценариев. Они написаны на JavaScript, что даёт нам возможность переиспользовать сценарий К6.
Всё это способствует значительному уменьшению Time to Market.

Подписывайтесь на нас в Telegram, чтобы не пропускать новости и статьи о технологиях в финтехе.

xk6-browser как секретное оружие для умного исследования производительности