React rendering and layout shifts: A guide to stable UIs

We’ve all been there: you push a new feature, load the page, and the entire header jumps three inches downward a split second after the content appears. It’s frustrating, it looks unprofessional, and it’s usually a symptom of a misunderstood mental model regarding how React rendering interacts with the browser's layout engine.

When we talk about performance, we often focus on JavaScript execution time. But in reality, the browser's ability to calculate positions is where the "jank" happens. If you don't account for how DOM reflow works alongside React's reconciliation process, you’re essentially flying blind.

The Problem: Virtual vs. Physical Reality

React doesn't touch the DOM directly. It uses a virtual representation to calculate the "diff" between states. When you change a piece of state in a Next.js component, React runs its reconciliation phase, decides what changed, and then commits those changes to the actual browser DOM.

The catch? React finishing its work is only half the battle. Once the DOM is updated, the browser must trigger a layout (or reflow) to calculate the geometry of every element. If your CSS is dynamic or dependent on content that isn't pre-sized, the browser has to recalculate the entire page flow. This is what we call a layout shift.

We once tried to solve a loading state issue by simply conditionally rendering a spinner. It worked, but because the spinner had a different height than the incoming data, the entire page content shifted 200ms after the initial paint. It was a classic "wrong turn." We had to swap the spinner for a skeleton screen with a fixed aspect ratio to keep the layout stable.

Why Next.js Performance Depends on Layout Stability

In a framework like Next.js, you have the advantage of server-side rendering (SSR). However, if your initial HTML doesn't account for the space your components will eventually occupy, you're losing the performance benefits of SSR.

When you look at React rendering: Tracing Prop Changes from Update to DOM Patch, you see how precise React is. But that precision stops at the browser boundary. If you're building a dashboard, you need to ensure that your CSS grid or flex containers have defined constraints.

If you're noticing sluggishness, you should React performance debugging: How to trace component re-renders to ensure you aren't triggering excessive updates. Often, the "performance" issue isn't the number of re-renders, but the cost of those re-renders forcing the browser to repaint the entire page.

Managing DOM Reflow and Layout Shifts

To stop the jumping, you need to move from a "content-first" mindset to a "container-first" mindset. Here is the mental model I use:

1. Reserve Space: Use min-height or CSS aspect-ratio properties on containers that fetch data.
2. Avoid Layout-Triggering Properties: Changing top, left, margin, or padding forces a reflow. Prefer transform (like scale or translate) for animations, as these are handled by the compositor thread and don't trigger layout.
3. Batch Updates: Understand that React rendering: Mastering State Batching and the Two-Pass Model is your friend. If you update three pieces of state in one event handler, React usually batches them to prevent multiple re-renders.

Consider this simple example of a component that causes a shift versus one that prevents it:

JSX
// Bad: Causes layout shift
const UserCard = ({ user }) => (
  <div>
    {user ? <p>{user.bio}</p> : <Spinner />}
  </div>
);

// Good: Reserves space
const UserCard = ({ user }) => (
  <div style={{ minHeight: CE9178">'150px' }}>
    {user ? <p>{user.bio}</p> : <SkeletonLoader />}
  </div>
);

By providing a min-height, the browser reserves space during the initial paint. When the user data arrives, the SkeletonLoader is swapped out, but the surrounding elements don't move.

The Developer's Caveat

I’m still experimenting with how CSS-in-JS libraries handle these shifts automatically. Some libraries handle the injection of styles so efficiently that they minimize layout thrashing, but others add overhead that can be counterproductive on mobile devices.

My advice? Don't over-engineer your layout strategy until you see a shift. Use the "Performance" tab in Chrome DevTools to record a page load. If you see "Layout Shift" warnings in your Lighthouse report, that’s your signal to start pinning down your dimensions. It’s rarely about the total number of components; it’s almost always about the browser having to recalculate space because we didn't give it enough information upfront.

Next time you're building a complex UI, try setting your container dimensions before you even worry about the data fetching. It saves you the headache of debugging layout jumps later in the cycle.