Как стать автором
Обновить

Комментарии 13

Вредный совет:
«Если у вас есть возможность использовать для выполнения неких действий побитовые операторы — сделайте это.»
Т.к. ресурсов много не сэкономит, а читабельность ухудшит, что чревато проблемами в других местах алгоритма, которые повлияют на производительность более значительно.
Используйте поисковые массивы вместо конструкций switch/case.

Что такое, поисковые массивы?
Ставлю на хеш-мапы
8. Если вы обращаетесь к элементу DOM несколько раз — сохраните ссылку на него в переменной


Хороший совет в плане читаемости кода и так делать однозначно надо, но вот только при обращении к DOM ссылка кешируется браузером и второе обращение происходит значительно быстрее. Так что не сказал бы что это сильно поможет оптимизации.

Многие из советов выглядят как экономия на спичках и дают реальный прирост разве что в IE 5.5.
Реальные тормоза это фреймворки типа Реакта и зависимости, если их не правильно готовить. А правильно готовить их никто не умеет.

Оптимизации гребли
image
Для достижения высокой производительности — не используйте javascript и потом пункт 3.
НЛО прилетело и опубликовало эту надпись здесь
>Согласно данным Kissmetrics, 47% посетителей ожидают, что веб-сайт загрузится менее чем за 2 секунды.
Помню обсуждали этот вопрос еще в 2000 годах. Цифра в 2 секунды взялась из психологических тестов о взаимодействии человека и ЭВМ. Человек вообще не готов ждать ответа машины дольше 2-х секунд, например в электронных тестах. Так что Kissmetrics открывают Америку снова
Правильно ли я понимаю, что наилучшей стратегией для избегания утечек памяти будет присвоение каждого нового фрагмента DOM одной и той же переменной x=$("#another_block"); поскольку она всегда обнуляется, а наихудшей — создание бесконечного массива для таких блоков x[n]=$("#another_block");?

Я как понимаю статья написана К. О. для людей которые познали js путем кодинга в реакте со старта. Полезность сомнительная…

Трагедия веб-воркеров в том, что обычно самые тяжелые операции — это DOM. А их в воркеры не вынести никак :(
На практике вам не удастся выполнять исследования производительности кода, например, во всех существующих версиях JS-движков, равно как и оптимизировать код в расчёте на все среды, в которых он может выполняться.

насколько я знаю, оптимизировать JS для разных браузерных (про консольные приложения не знаю) движков — плохая практика, т.к. в любой момент медленная конструкция может быть оптимизирована на уровне движка, а в все "оптимизации" будут значительно медленее.

Можно ещё добавить, что полезно просматривать импорты библиотек, особенно в старых проектах. Иногда целый пакет импортируется ради пары ф-й. Например, если заменить ту же lodash на lodash-es и правильные импорты, то можно убрать несколько десятков кб JS'а.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий