Расчетная производительность не интересует. Задача - новая фича не должна ухудшить текущие показатели. То есть показатели относительные

Оно и надо, но в автоматическом режиме и по многим метрикам

селениум свежий вроде как умеет туда смотреть

Chrome dev tools protocol and puppeteer - но это не тот чат )

Вопрос звучит: делаете ли вы это, делали ли, если да -чем и как?)

Но это же после деплоя хоть куда-то

не очень понял мысль

куда-то задеплоил код - измерил - принял решение, раскатывать ли на весь продакшен

👍

Ну это у нас есть - поднимается дев стенды для Ui тестов, слабенькие, но мне нужна относительные показатели (не хуже исторических данных), так что это норм.
Дальше, это должно быть в CI - разраб сделал MR, автоматом поднялся стенд, прогнались тесты в том числе и по производительности, собрали метрики, посмотрели - что по крайней мере за заранее определенные лимиты не вышли (условно, не сделали селект, который отрабатывает минуту) - если ок, то отправили автоматом дальше.
И это - на все задачи

Если что-то специфичное, связанное с оптимизацией бэка или фронта - можно отдельно поднимать и скрупулезнее проверять.

Возможно никто это тут не делал ,я спросил на всякий случай, вдруг стояла такая задача и как нашли решение.

Chrome dev tools protocol and puppeteer - но это не тот чат - повторюсь немного

считаю, что этот
я задаю вопросы касательно (по сути) мониторинга перформанса веб приложения

или вы только нагрузку тут обсуждаете?

Есть отличный инструмент для этого https://www.sitespeed.io/

Хорошая должность инженер по производительности

Разве qa инженер не желает багов в коде, чтобы их можно было найти и пофиксить?

QA инженер проверяет качество баги его не интересуют 😉

В целом метрика пропущенных багов важней найденных, но с каждым найденным зато растёт мотивация