User Timing API

[RubaXa]

хорошая эмуляция

Не знаю почему в оригинальной статье это назвали хорошим полифилом, но половина методов просто отсутствует, реализованы только mark и getEntriesByType. По этому в рамках борьбы за справедливость написал честный polyfill.

[Malyw]

Там же первые комментарии содержат указания на опечатки в коде:
— Про reqCount->reqCnt
— и .length()
Поправьте хоть тут.

[EasyX]

Поправил, спасибо!

[plutov]

Я думал, что в песочницу переводы статей не публикуют.

[kingil]

Не могу понять, как можно использовать User timing api для сбора статистики по загрузке, например, тысячи сайтов? SiteSpeed.io вроде можно приспособить для этого, но он откровенно лагучий, увидеть его в работе так и не получилось.

[Murz]

А можно как-то измерять производительность JS в каких-либо «статических попугаях», чтобы попугаев было одинаковое количество на разных компьютерах, независимо от скорости процессора и активности других процессов? Например, количество выполненных эвентов, количество тактов процессора, и т.п.

А то текущие замеры по времени — сильно зависят от производительности процессора и текущей нагрузке на систему, например если на момент проверки в соседней вкладке майнятся бетховены, то статистика по User Timing API получится неправильной.

[RubaXa]

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

[Murz]

Когда ты пишешь код и в голове есть 2-3 варианта реализации — на этот момент нет ни статистики ни процентилей, поэтому и нужен быстрый инструмент оценки и сравнения "скорости" выполнения кода не "на глаз". Ну а так-то да, а-б тестирование на реальных юзерах — тоже хороший инструмент.

[Alternator]

Тут есть что-то про измерение количества процессорных инструкций
habr.com/ru/company/ruvds/blog/479266

[Murz]

Благодарю, это прям то что нужно!

[Murz]

Благодарю, это прям то что нужно!