Профилировщики, безусловно, являются хорошим способом получения чисел, но по моему опыту воспринимаемая производительность - это все, что имеет значение для пользователя / клиента. Например, у нас был проект с Ext аккордеоном, который расширился, чтобы показать некоторые данные, а затем несколько вложенных сеток Ext. На самом деле все рендерилось довольно быстро, ни одна операция не занимала много времени, было просто много информации, отображаемой одновременно, поэтому пользователю это казалось медленным.
Мы «исправили» это, не переключаясь на более быстрый компонент или оптимизируя какой-либо метод, но сначала отображая данные, а затем отображая сетки с помощью setTimeout. Итак, сначала появилась информация, затем через секунду появятся сетки. В целом, для этого потребовалось немного больше времени на обработку, но для пользователя воспринимаемая производительность была улучшена.
В наши дни профилировщик Chrome и другие инструменты универсально доступны и просты в использовании, как и console.time()
, console.profile()
и performance.now()
. Chrome также дает вам представление временной шкалы, которое может показать вам, что убивает вашу частоту кадров, где пользователь может ждать и т. Д.
Найти документацию по всем этим инструментам очень просто, для этого вам не нужен SO-ответ. Спустя 7 лет я все еще повторю совет моего первоначального ответа и укажу, что вы можете иметь медленный код, выполняемый вечно, где пользователь этого не заметит, и довольно быстрый код, работающий там, где он это делает, и они будут жаловаться на довольно быстрый код недостаточно быстр. Или чтобы ваш запрос к API вашего сервера занял 220мс. Или что-то еще в этом роде. Суть в том, что если вы возьмете профилировщик и начнете искать работу, вы ее найдете, но это может быть не та работа, которая нужна вашим пользователям.