How to batch DOM manipulations in JavaScript

Every time you update the DOM, the browser has to do a bit of work behind the scenes. It’s not just about slapping new content onto the page; the browser recalculates styles, reflows layouts, and repaints pixels. These steps—style calculation, layout, and paint—are what make DOM updates costly if you’re not careful.

Consider a simple example: changing the text content of a single element. It might seem trivial, but if done repeatedly or on many elements, it triggers the browser’s layout engine to re-compute the positions and sizes of elements. This process is known as a reflow (or layout thrash when it happens excessively).

Here’s a quick demonstration:

const list = document.getElementById('myList');
for(let i = 0; i < 100; i++) {
  const item = document.createElement('li');
  item.textContent = Item ${i};
  list.appendChild(item);
}

At first glance, this looks simpler. But appending each li element individually forces the browser to update the layout every time appendChild is called—potentially 100 times in this loop. That’s expensive.

When you trigger a layout, the browser has to do more than just one thing:

• Style recalculation: It figures out which CSS rules apply to the changed elements.
• Layout (reflow): It calculates positions and sizes of elements, which can cascade through the DOM if any dimensions changed.
• Paint: It redraws pixels on the screen.

The more elements you touch one-by-one, the more often the browser cycles through this expensive process. Even reading layout properties like offsetHeight or getBoundingClientRect() can force an immediate reflow, because the browser needs the latest layout to return accurate values.

Here’s an example of a subtle cause of layout thrashing:

const element = document.getElementById('box');
element.style.width = '100px';
const height = element.offsetHeight; // Forces layout to ensure height is accurate
element.style.height = height + 'px';

At first, you set the width, which marks the layout dirty. Then reading offsetHeight forces the browser to flush all pending changes to get the computed height, after which you write a new height style. This read-write-read-write pattern is a classic layout thrash.

Understanding that every DOM mutation can cascade into a costly reflow is key. The browser’s layout engine isn’t lazy—it has to keep the page visually consistent, and that means recalculating layout as soon as you query layout-dependent properties after a mutation.

So the goal is to batch DOM mutations together, minimize forced synchronous layouts, and avoid mixing reads and writes in a way that triggers multiple reflows within a single frame. That’s a fundamental performance principle when manipulating the DOM directly.

Techniques for minimizing layout thrashing

The most simpler technique to minimize layout thrashing is to separate DOM reads from DOM writes. Instead of interleaving them, group all your reads first, then perform all your writes. This reduces the number of times the browser has to recalculate layout during a batch of operations.

Consider a scenario where you want to update the positions of multiple elements based on their current locations. A naive approach might look like this:

const items = document.querySelectorAll('.item');
items.forEach(item => {
  const rect = item.getBoundingClientRect(); // Read
  item.style.top = rect.top + 10 + 'px';     // Write
});

Because each iteration reads and writes alternately, the browser is forced to recalculate layout after each write to ensure the next read is accurate. Instead, batch all reads first, then all writes:

const items = document.querySelectorAll('.item');
const positions = [];
items.forEach(item => {
  positions.push(item.getBoundingClientRect().top);
});
items.forEach((item, i) => {
  item.style.top = positions[i] + 10 + 'px';
});

This way, the browser only recalculates layout once—after all reads—before performing all writes.

Another common technique is to use classList toggling instead of repeatedly manipulating inline styles. Changing a class can trigger style recalculations, but if you do it once per element rather than multiple inline style assignments, you reduce the overhead.

When you must perform many DOM updates, consider detaching the parent node from the document, performing all the mutations, then reattaching it. This prevents the browser from recalculating layout on each change:

const container = document.getElementById('container');
const parent = container.parentNode;
parent.removeChild(container);

// Perform multiple DOM mutations
for (let i = 0; i < 100; i++) {
  const newDiv = document.createElement('div');
  newDiv.textContent = 'Item ' + i;
  container.appendChild(newDiv);
}

parent.appendChild(container);

Because the container is detached, none of the intermediate changes cause layout recalculations. The browser only updates layout when the container is reinserted.

Beware of reading layout properties in the middle of write-heavy code. Properties like offsetWidth, offsetHeight, scrollTop, and getComputedStyle() can trigger forced synchronous layouts. Avoid querying these inside loops that also modify styles.

In performance-critical scenarios, consider caching layout values where feasible to avoid repeated reads:

function updatePositions(items) {
  const cachedTops = [];
  items.forEach(item => cachedTops.push(item.getBoundingClientRect().top));
  
  items.forEach((item, i) => {
    // Use cachedTops[i] instead of querying again
    item.style.transform = translateY(${cachedTops[i] + 20}px);
  });
}

By caching values, you prevent repeated forced layouts. The key is to think about the browser’s rendering pipeline and respect its cost model.

Finally, consider debouncing or throttling DOM updates when responding to rapid events like window resizing or scrolling. This prevents overwhelming the layout engine with too many updates in a tight timeframe:

let scheduled = false;
window.addEventListener('resize', () => {
  if (!scheduled) {
    scheduled = true;
    requestAnimationFrame(() => {
      // Perform DOM updates here
      scheduled = false;
    });
  }
});

This approach leverages requestAnimationFrame to batch updates into the next animation frame, reducing unnecessary recalculations and improving perceived performance. The browser can optimize layout and paint more efficiently when you align updates with its rendering schedule.

Using document fragments and requestAnimationFrame

Using document.createDocumentFragment() can also significantly enhance performance when dealing with multiple DOM updates. A document fragment acts like a lightweight container that holds DOM nodes but isn’t part of the main document tree. By appending elements to a fragment first and then appending the fragment to the DOM, you minimize the number of reflows and repaints triggered by each individual insertion.

Here’s how you can implement this technique:

const fragment = document.createDocumentFragment();
for (let i = 0; i < 100; i++) {
  const item = document.createElement('li');
  item.textContent = Item ${i};
  fragment.appendChild(item);
}
document.getElementById('myList').appendChild(fragment);

In this example, the fragment is built in memory without causing any reflows. Once all items are appended to the fragment, the entire fragment is added to the DOM in a single operation, resulting in a significant performance gain.

Another aspect to consider is the use of requestAnimationFrame. This method allows you to schedule updates to the DOM in a way that aligns with the browser’s rendering cycle. When you wrap your DOM manipulations inside a requestAnimationFrame callback, you ensure that these updates happen before the next repaint, effectively reducing the chance of layout thrashing.

Here’s a practical example:

const updateDOM = () => {
  const items = document.querySelectorAll('.item');
  items.forEach(item => {
    item.style.transform = 'translateY(10px)';
  });
};

window.addEventListener('scroll', () => {
  requestAnimationFrame(updateDOM);
});

In this case, whenever the user scrolls, the updateDOM function is called, but only once per frame, even if the scroll event fires multiple times. This batching of updates allows the browser to optimize rendering and enhances the overall performance.

Combining these strategies—using document fragments for batch DOM updates and using requestAnimationFrame for timing—can lead to smoother user experiences and reduced layout thrashing. Remember, the goal is to minimize the number of times the browser has to recalculate styles and layouts, which can significantly impact the performance of your web applications.