Хранитель производительности 🚀

Совсем недавно был написан @perf-tools/timekeeper, для замены console.time и удобной профилировки приложения, но спустя время, я начал добавлять расширения, которые бы позволили из «коробки» собирать разного рода метрики, которые отвечают за производительность вашего приложения. В итоге стало понятно, что это уже не просто «Хранитель времени», а производительности в целом.

npm i --save @perf-tools/keeper

Главное изменение, это размерность, на данный момент, есть три варианта:ms (по умолчанию), KiB , fps и raw .

Яркий пример использования всех 4 единиц измерения

На самом деле единицы нужны только для вывода, больше они не на что не влияют (ну ещё цвет немного по разному определяется).

Кроме этого появилась возможность вывести группу в схлопнутом состоянии:

const gapp = keeper.group('app');
gapp._ = true; // да-да, во имя экономии байтиков
gapp.unit = 'ms'; // единицы измерения
// ...
gapp.stop();

Но хватит от скучном, переходим к самому сочку

Расширения

Это самая важная часть, ради которой все и начиналось. В расширениях я попытался собрать, раз и на всегда, все те метрики, которые мы собираем.

  • fps — мерялка FPS скролла (ниже, напишу о ней отдельно)
Первый и второй сколл, latency, это задержка при старте
  • navigation — все сетевые тайминги + загрузка страницы с разделением на фазы
  • paint —время первой и полной отрисовки страницы
  • performance — комплексные метрики, которые считаю время до первого клика, прокрутки, отправки формы и т.п., так же есть TTI, TabUnload и задержка при обработки некоторых событий (типа пытаемся следить за тормозами)
  • resource—умеет считать трафик по времени и статистику по ресурсам
и так далее

Это самая интересная метрика, обычно её меряют через requestAnimationFrame и результаты получаются очень оптимистичными, но тут я наткнулся на очень интересный способ.

Гениально на самом деле, просто создаём прозрачный div (1x1px), добавляем ему transition: left 300ms linear и запускаем его из одного угла в другой, а пока он анимируется, через requestAnimationFrame проверяем его реальный left и если новая длинна отличается от предыдущей, то увеличиваем количество отрисованных кадров (иначе имеем просадку FPS).

И это ещё не всё, если вы пользуетесь FF, то там просто есть mozPaintCount, которое отвечает за количество отрисованных кадров, т.е. запоминаем «ДО», а на transitionend вычисляем разницу.

Итого 🔥. Без какого-либо прогрева, мы точно знаем, перерисовал-ли браузер кадр или нет.

Ещё, в скором времени, появится нормальное API: http://wicg.github.io/frame-timing/

npm i --save @perf-tools/keeper

Так же из коробки идут три врапера для аналитики: Google Analytics, Yandex.Metirka и конечно Mailru.XRay.

Ну и все ваши предложения, улучшения, баги, то это сюда:

The End 🚀

Frontend originator | https://rubaxa.github.io | https://t.me/artifact_project