Оптимизация производительности в веб-разработке

DOM — самый затратный ресурс, с которым работает большинство JavaScript-приложений. Чтение такого свойства, как offsetHeight, может вынудить браузер остановиться и пересчитать геометрию страницы, а запись в DOM способна спровоцировать reflow (повторное вычисление позиций и размеров элементов) и repaint (перерисовку пикселей). Делайте это небрежно внутри цикла — и страница, которая должна работать мгновенно, начнёт тормозить.

В этом руководстве объясняется, почему операции с DOM медленны, а затем демонстрируются конкретные методы их ускорения: минимизация обращений к DOM, предотвращение layout thrashing, пакетная обработка изменений с помощью requestAnimationFrame и document.createDocumentFragment(), а также профилирование там, где нельзя полагаться на догадки.

Почему операции с DOM медленны

JavaScript выполняется в быстром движке, однако DOM — это граница между движком и конвейером рендеринга браузера. Именно многократное пересечение этой границы и создаёт проблему:

• Reflow (layout) — браузер заново вычисляет положение и размеры элементов. Reflow одного элемента может распространиться на его предков, потомков и соседей.
• Repaint — браузер перерисовывает пиксели (цвета, тени, видимость), не меняя геометрию. Дешевле reflow, но тоже не бесплатно.

Ключевая идея: браузер пытается группировать эти операции за вас. Он накапливает все записи и сбрасывает их разом прямо перед отрисовкой следующего кадра. Эта оптимизация нарушается в тот момент, когда вы читаете свойство, связанное с разметкой: браузер обязан немедленно сбросить все отложенные записи, чтобы выдать точный результат. Такой принудительный сброс называется синхронным (принудительным) layout, и именно его выполнение в цикле является корнем большинства проблем с производительностью DOM.

Минимизация обращений к DOM

Каждое чтение и запись свойства пересекает границу JS→DOM, поэтому самая дешёвая оптимизация — делать это как можно реже.

• Кэшируйте ссылки на элементы. Найдите элемент один раз и сохраните в переменной, вместо того чтобы вызывать document.querySelector на каждой итерации.
• Читайте значения в локальные переменные. Счётчики циклов, длины и вычисленные значения должны храниться в переменных JavaScript, а не перечитываться из DOM при каждом проходе.
• Когда уместно, стройте строки, а не узлы. Однократное присваивание innerHTML зачастую быстрее, чем последовательная вставка множества узлов — хотя при этом теряются обработчики событий и небезопасно использовать ненадёжный ввод.

// Slow: re-queries and re-reads the DOM on every iteration
for (let i = 0; i < items.length; i++) {
  document.getElementById('list').appendChild(makeRow(items[i]));
}

// Fast: resolve the reference once, outside the loop
const list = document.getElementById('list');
for (let i = 0; i < items.length; i++) {
  list.appendChild(makeRow(items[i]));
}

О выборе быстрых и точных селекторов читайте в разделе Выбор элементов DOM — предпочитайте getElementById и точечный querySelector глубоким цепочкам вроде div > ul li span.

Эффективная обработка событий

Навешивать обработчик на каждый элемент длинного списка расточительно по памяти и замедляет обновление DOM. Делегирование событий предполагает подключение одного обработчика к общему родителю с использованием event.target для определения дочернего элемента-источника — благодаря всплытию событий.

// One listener handles the whole list, including rows added later
document.getElementById('list').addEventListener('click', (event) => {
  const row = event.target.closest('li');
  if (row) console.log('clicked row:', row.dataset.id);
});

Этот подход масштабируется на тысячи элементов и автоматически охватывает элементы, добавленные после установки обработчика. Подробнее читайте в разделах Обработка событий в DOM и Введение в события браузера.

Понимание и предотвращение layout thrashing

Что такое layout thrashing?

Layout thrashing возникает, когда вы попеременно читаете и записываете свойства, связанные с разметкой, в быстрой последовательности. Каждое чтение вызывает синхронный layout для сброса предыдущей записи, поэтому цикл вида «чтение-запись-чтение-запись» запускает один reflow на каждой итерации вместо одного общего.

// Bad: read (offsetWidth) forces layout, then write invalidates it — every loop
const boxes = document.querySelectorAll('.box');
boxes.forEach((box) => {
  box.style.width = box.offsetWidth + 10 + 'px'; // read + write interleaved
});

Решение: сначала все чтения, потом все записи

Сгруппируйте все операции чтения, затем выполните все записи. Браузер сделает один проход layout для чтений и один для записей.

const boxes = document.querySelectorAll('.box');

// 1. Read phase — collect every measurement first
const widths = [...boxes].map((box) => box.offsetWidth);

// 2. Write phase — now apply all changes; no read interrupts them
boxes.forEach((box, i) => {
  box.style.width = widths[i] + 10 + 'px';
});

Планирование работы с помощью requestAnimationFrame

requestAnimationFrame запускает ваш колбэк непосредственно перед следующей перерисовкой — это идеальный момент для записи изменений в DOM: они объединяются в один кадр вместо того, чтобы вызывать промежуточные отрисовки.

const element = document.getElementById('box');

requestAnimationFrame(() => {
  const width = element.offsetWidth; // read
  element.style.width = width + 10 + 'px'; // write, applied in the same frame
});

Для анимаций помещайте все записи в DOM внутрь колбэка requestAnimationFrame и никогда не читайте свойства разметки в середине этих записей.

Пакетная обработка изменений DOM

Использование document.createDocumentFragment()

document.createDocumentFragment() — это лёгкий внеэкранный контейнер. Узлы, добавляемые во фрагмент, не являются частью живого документа, поэтому его построение не вызывает reflow. Когда готовый фрагмент добавляется на страницу, браузер вставляет всех его потомков за одну операцию — один reflow вместо одного на каждый узел.

Пример

<!DOCTYPE html>
<html>
<head>
    <title>Batching DOM Changes</title>
</head>
<body>
    <div id="container"></div>

    <script>
        const container = document.getElementById('container');
        const fragment = document.createDocumentFragment();

        for (let i = 0; i < 40; i++) {
            const div = document.createElement('div');
            div.textContent = `Item ${i}`;
            fragment.appendChild(div);
        }

        container.appendChild(fragment); // Batch update
    </script>
</body>
</html>

Цикл формирует 40 элементов внутри фрагмента без какого-либо влияния на видимую страницу. Лишь финальный вызов container.appendChild(fragment) затрагивает живой DOM, поэтому браузер выполняет один проход layout вместо 40. (Современные движки также позволяют добавить массив узлов за один вызов через container.append(...nodes), что аналогично группируется.)

Предотвращение принудительного синхронного layout

Незаметная разновидность thrashing — чтение свойства разметки сразу после изменения стиля, что вынуждает браузер немедленно пересчитать layout:

const box = document.getElementById('box');

box.classList.add('expanded'); // write — queues a layout change
const height = box.offsetHeight; // read — forces layout NOW to answer

Если значение не нужно немедленно, отложите чтение до следующего кадра с помощью requestAnimationFrame или перестройте код так, чтобы все операции чтения выполнялись до любых записей. К свойствам, вызывающим принудительный layout при чтении, относятся offsetTop/offsetWidth/offsetHeight, clientWidth/clientHeight, scrollTop и getComputedStyle().

Лучшие практики

1. Откладывайте некритичный JavaScript. Добавляйте атрибут defer к тегам <script>, чтобы браузер продолжал разбирать HTML и выполнял скрипт после готовности DOM. Используйте async для независимых сторонних скриптов.
2. Предпочитайте переключение классов инлайн-стилям. Изменение одного CSS-класса позволяет браузеру применить множество правил за один reflow, вместо одного reflow на каждое присваивание инлайн-стиля.
3. Анимируйте transform и opacity. Эти свойства компонуются на GPU и полностью минуют layout и paint — в отличие от анимации width, top или margin.
4. Открепите, измените, прикрепите обратно. При масштабных правках удалите поддерево из документа (или скройте его через display: none), измените его вне экрана, затем верните на место.
5. Профилируйте перед оптимизацией. Используйте панель Performance в DevTools браузера, чтобы найти реальное узкое место, а не угадывать его — см. Отладка DOM и инструменты.

Типичные ошибки

• Вызов document.querySelector внутри цикла вместо кэширования результата.
• Чтение offsetWidth/offsetHeight и запись стилей в одной итерации цикла.
• Навешивание отдельного обработчика событий на каждый элемент большого динамического списка вместо делегирования.
• Анимация свойств, вызывающих layout (width, left, margin), вместо transform/opacity.

Заключение

Производительность DOM сводится к одной идее: браузер отлично справляется с пакетной обработкой рендеринга, а ваша задача — не нарушать эту группировку. Кэшируйте ссылки, делегируйте события, выполняйте все чтения перед записями, формируйте крупные обновления внутри DocumentFragment и планируйте визуальные изменения через requestAnimationFrame. В сомнительных случаях профилируйте — панель Performance в DevTools покажет точно, где происходят reflow. Далее углубите свой инструментарий в разделах Манипуляции с DOM и Продвинутые техники DOM.

Практика