Резонный вопрос, который можно услышать от многих фронтенд-разработчиков. Большинство из нас делают (или хотя бы задумываются) глобальные оптимизации приложения: уменьшают размеры поставляемого кода, разбивают его на множество частей и тому подобное. Таких оптимизаций оказывается достаточно в большинстве случаев. Но вот появляется кастомный дропдаун, который отрисовывается секунду, а вот при скролле начинает подтормаживать список... И пользоваться таким приложением уже не очень приятно.

Чтобы наш код «оставался незамеченным», есть в лучшем случае 16 миллисекунд. Именно столько времени мы можем позволить себе выполнять код между отрисовками 60 кадров в секунду. Но на самом деле времени у нас гораздо меньше: эти же 16 миллисекунд делит с нами браузер на всю свою работу для отрисовки страницы.

В действительности если мы потеряем 1-2 кадра, то ничего страшного не произойдёт — скорее всего, пользователь этого даже не заметит. Проблемы начинаются, когда алгоритмически «тяжелый» код выполняется каждый кадр и производительность приложения падает настолько, что конечные пользователи получают 15-20 кадров в секунду. Большинство таких приложений — это либо браузерные игры, либо тяжелые «промышленные интерфейсы», UX которых особо не уделяют внимания. Оптимизации в таких приложениях происходят только в моменты, когда пользоваться ими становится невозможно. Так вот, именно для того, чтобы не доводить свои приложения до такого состояния, и нужно иметь хотя бы базовые знания о сложностях алгоритмов и том, как можно снижать сложность вашего кода.