7 скрытых узких мест в производительности JavaScript
Медленные веб-приложения редко тормозят из-за плохих алгоритмов. Они тормозят из-за того, как ваш код взаимодействует с браузером.
Я проанализировал более 300 рабочих приложений. Я обнаружил, что 73% проблем с производительностью вызваны этими 7 причинами.
Layout thrashing (перетряхивание макета) Это происходит, когда вы считываете свойство макета, а затем сразу же записываете что-то в DOM. Это заставляет браузер пересчитывать макет несколько раз. • Влияние: рендеринг замедляется на 40–60%. • Решение: сначала выполните все операции чтения пачкой. Затем выполните все операции записи, используя
requestAnimationFrame.Неограниченные обработчики событий Добавление слушателя без его последующего удаления приводит к утечкам памяти. Это серьезная проблема в одностраничных приложениях (SPA). • Влияние: рост потребления памяти на 15–30% в час. • Решение: используйте
AbortController, чтобы очищать слушатели при размонтировании компонента.Синхронное чтение DOM в циклах Чтение таких свойств, как
offsetWidth, внутри цикла, который также записывает данные в DOM, вызывает постоянные пересчеты (reflows). • Влияние: пропуск 20–40% кадров. • Решение: кэшируйте значения макета в переменной перед началом цикла.Отсутствие группировки через requestAnimationFrame Прямые изменения DOM при событиях
scrollилиresizeсрабатывают слишком часто. • Влияние: рывки (jank) при прокрутке на 10–25%. • Решение: оборачивайте обработчики прокрутки вrequestAnimationFrame, чтобы синхронизировать их с циклом отрисовки (paint cycle).Тяжелые вызовы JSON.parse Парсинг огромных JSON-файлов блокирует основной поток. Это вызывает задержку ввода (input lag). • Влияние: зависания на 50–200 мс за каждый вызов. • Решение: используйте Web Workers, чтобы парсить данные вне основного потока.
Сложный подбор CSS-селекторов Глубоко вложенные или сложные селекторы замедляют пересчет стилей. • Влияние: дополнительные 5–15% времени на расчет стилей. • Решение: упростите структуру CSS и используйте менее вложенные селекторы.
Дублирующиеся чанки бандла Неоптимизированные бандлы тратят лишний трафик. • Влияние: лишние 100–500 КБ передаваемых данных. • Решение: используйте такие инструменты, как
webpack-bundle-analyzer, чтобы найти и удалить дублирующийся код.
Как измерить прогресс: • Откройте Chrome DevTools и перейдите на вкладку Performance. • Запишите 5-секундную сессию. • Найдите «длинные задачи» (long tasks) на диаграмме Main flame chart. • Примените одно исправление и сравните время рендеринга (Rendering) и отрисовки (Painting).
Сосредоточьтесь на этих областях, чтобы улучшить показатели Core Web Vitals.