The Secret Life of JavaScript: The Frame

Stop fighting the browser: how to fix layout thrashing

#JavaScript #WebPerformance #Frontend #requestAnimationFrame

---

The Stuttering UI

Timothy dragged his mouse across the dark IDE, intensely focused on the preview window. He was building a custom drag-and-drop kanban board. He clicked a task card and dragged it across the screen.

Instead of gliding, the card stuttered. It lagged a few pixels behind his cursor, jumping frantically to catch up like a flipbook missing half of its pages.

"I don't get it," Timothy sighed, dropping the mouse. "I am using the setTimeout chunking trick you showed me yesterday. The Event Loop is completely clear. The JavaScript execution is lightning fast. Why does the UI look like it is running on a dial-up connection?"

Margaret leaned against his desk, watching the jerky animation replay on the screen.

"Because JavaScript speed is only half the battle," Margaret said. "You fixed your Microtask starvation, which means your code is executing fast. But you are completely ignoring the monitor's refresh rate. You are fighting the painter."

The Suspect Code Block

She pointed to the block of code responsible for the drag animation.

function updateCardPositions(cards, mouseX) {
  cards.forEach(card => {
    // Read the current position
    let currentLeft = card.offsetLeft; 
    
    // Write the new position
    card.style.left = (currentLeft + mouseX) + 'px'; 
  });
}

"To get that buttery-smooth 60 frames per second," Margaret explained, "the browser has exactly 16.6 milliseconds to execute your JavaScript, calculate the CSS, figure out the geometry of the page, and finally paint the pixels on the screen."

Layout Thrashing

"Inside your loop, you are doing something called 'Layout Thrashing,'" Margaret continued. "You ask the browser to read the offsetLeft of a card. And it is not just offsetLeft. Anytime you ask for properties like offsetTop, clientWidth, or run getComputedStyle(), the browser has to stop everything and calculate the geometry of the entire page to give you an accurate number. Immediately after that, you write a new style.left to the DOM. That invalidates the geometry the browser just calculated."

Timothy looked at the forEach loop. "And then the loop runs again for the next card."

"Exactly," Margaret nodded. "You read, it calculates. You write, it throws the calculation in the trash. You read the next card, it has to stop everything and calculate the entire page layout all over again from scratch. It is forced synchronous layout. Imagine an exhausted painter trying to paint a billboard, and every two seconds you force them to drop their brush, climb down the ladder, and measure the canvas for you."

"No wonder it's stuttering," Timothy said. "I am forcing the browser to recalculate the math dozens of times per frame, instead of actually painting the frame."

Separate Reads from Writes

"So, you have to separate your reads from your writes," Margaret instructed. "You measure everything at once, while the painter is still resting. Then, you hand all the updates to the painter at the exact moment they pick up their brush."

Timothy thought about the VIP lines from yesterday. "How do I know exactly when the painter is picking up the brush?"

Use requestAnimationFrame

"You use the ultimate VIP pass," Margaret smiled. "requestAnimationFrame. It tells the browser, 'Hey, right before you paint the very next frame, execute this specific block of code.' It perfectly synchronizes your JavaScript with the hardware's 60Hz refresh rate."

Timothy deleted his thrashing loop and rewrote the function. He created one array to store all the measurements, and then wrapped the actual DOM updates inside requestAnimationFrame.

function updateCardPositions(cards, mouseX) {
  // 1. Batch all the DOM Reads first (No thrashing)
  const currentPositions = cards.map(card => card.offsetLeft);
  
  // 2. Schedule all the DOM Writes for the exact start of the next frame
  requestAnimationFrame(() => {
    cards.forEach((card, index) => {
      card.style.left = (currentPositions[index] + mouseX) + 'px';
    });
  });
}

"Look at that," Margaret said as he finished typing. "You batched all your reads. The browser calculates the layout exactly once. Then, requestAnimationFrame queues up your writes so they execute right before the next paint cycle. The painter measures once, and paints once."

Modern Frameworks Handle This Kind of Batching

She tapped the monitor. "This is exactly why modern frameworks like React are so popular. They handle this kind of read/write batching for you under the hood using a Virtual DOM. But when you are manipulating the real DOM directly like we are, performance optimization is entirely your responsibility."

A Word of Caution

"And one word of caution," she added, her tone turning serious. "If you ever use requestAnimationFrame recursively to build a continuous animation, make sure you have a strict break condition. Otherwise, you trap the painter in an infinite loop and freeze the tab completely."

Timothy saved the file, refreshed the browser, and clicked the task card.

He dragged it across the screen. The stuttering was entirely gone. The card clung perfectly to his cursor, gliding across the kanban board like glass. The JavaScript and the hardware were finally moving in perfect harmony.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.