The 16ms Frame Budget

The Number That Rules Every Frame

Your screen refreshes 60 times per second. That gives the browser exactly 16.67 milliseconds to produce each frame. Miss that deadline, and the user sees jank — a visible stutter that screams "this app is slow" louder than any loading spinner.

Here's the thing most engineers miss: you don't actually get the full 16.67ms. The browser has its own housekeeping — garbage collection, input processing, compositing overhead. After all that, you realistically get about 10ms of JavaScript execution time per frame. That's your budget. Blow it, and the frame drops.

The Rendering Pipeline Per Frame

Every single frame the browser produces follows the same pipeline. Understanding where your time goes is the difference between guessing and knowing.

Not every frame runs every stage. That insight is the key to high-performance animation.

What Actually Fits in 16ms

Let's break down a realistic frame budget:

Total frame budget:           16.67ms
─────────────────────────────────────
Browser overhead:             ~2ms    (input handling, compositing, GC)
Style recalculation:          ~0.5ms  (small DOM, simple selectors)
Layout:                       ~1ms    (if triggered)
Paint:                        ~1ms    (if triggered)
Composite:                    ~0.5ms
─────────────────────────────────────
Remaining for YOUR JavaScript: ~11ms

That's the happy path. Now consider what happens when layout thrashing enters the picture — a single forced reflow in a loop can consume 50ms+ on a mid-range mobile device. Your 16ms budget doesn't just get blown. It gets obliterated.

The CSS Property Cost Table

Not all CSS changes are equal. Some properties trigger the full pipeline. Others skip expensive stages entirely. This table determines your animation strategy:

┌──────────────────────┬───────┬────────┬───────┬───────────┐
│ Property             │ Style │ Layout │ Paint │ Composite │
├──────────────────────┼───────┼────────┼───────┼───────────┤
│ width, height        │  ✓    │   ✓    │   ✓   │     ✓     │
│ margin, padding      │  ✓    │   ✓    │   ✓   │     ✓     │
│ top, left, right     │  ✓    │   ✓    │   ✓   │     ✓     │
│ font-size            │  ✓    │   ✓    │   ✓   │     ✓     │
│ border-width         │  ✓    │   ✓    │   ✓   │     ✓     │
├──────────────────────┼───────┼────────┼───────┼───────────┤
│ color                │  ✓    │        │   ✓   │     ✓     │
│ background-color     │  ✓    │        │   ✓   │     ✓     │
│ box-shadow           │  ✓    │        │   ✓   │     ✓     │
│ border-color         │  ✓    │        │   ✓   │     ✓     │
├──────────────────────┼───────┼────────┼───────┼───────────┤
│ transform            │  ✓    │        │       │     ✓     │
│ opacity              │  ✓    │        │       │     ✓     │
│ filter (on layer)    │  ✓    │        │       │     ✓     │
└──────────────────────┴───────┴────────┴───────┴───────────┘

The bottom rows are gold. transform and opacity skip layout AND paint — they run entirely on the compositor thread, off the main thread. Your JavaScript can be busy doing other work and the animation still runs smoothly at 60fps.

Compositor-Only Animations

This is the single highest-impact optimization for animation performance. When you animate transform or opacity on an element that has its own compositing layer, the animation runs on the compositor thread — completely independent of the main thread.

/* SLOW: Animating top triggers Layout + Paint + Composite every frame */
.card-bad {
  position: absolute;
  transition: top 300ms ease;
}
.card-bad:hover {
  top: -10px;
}

/* FAST: Animating transform runs only on compositor thread */
.card-good {
  transition: transform 300ms ease;
}
.card-good:hover {
  transform: translateY(-10px);
}

Both produce the same visual result — the card moves up 10px on hover. But the performance characteristics are night and day:

• Animating top: triggers layout (recalculate every element's position), paint (redraw affected area), composite. All on the main thread. If JavaScript is busy, the animation stutters.
• Animating transform: the element already has a GPU texture from its compositing layer. The compositor just moves the texture. Zero main thread involvement. Silky smooth even during heavy JS execution.

Layout Thrashing and Forced Reflow

Layout thrashing is the most common cause of frame budget violations. It happens when you interleave reads and writes to the DOM, forcing the browser to synchronously recalculate layout multiple times in a single frame.

// THRASHING: Forces synchronous layout on every iteration
function resizeCards(cards) {
  for (const card of cards) {
    const parentWidth = card.parentElement.offsetWidth; // READ → forces layout
    card.style.width = (parentWidth * 0.9) + 'px';     // WRITE → invalidates layout
  }
}

Each offsetWidth read forces the browser to flush pending style changes and compute layout synchronously. With 100 cards, that's 100 forced layouts in a single frame. On a mid-range phone, that's easily 200ms — twelve dropped frames.

The Fix: Separate Reads from Writes

// BATCHED: One layout calculation total
function resizeCards(cards) {
  const widths = cards.map(card => card.parentElement.offsetWidth);

  for (let i = 0; i < cards.length; i++) {
    cards[i].style.width = (widths[i] * 0.9) + 'px';
  }
}

Read all values first (one layout), then write all values (one layout at end of frame). Two layouts instead of 100.

requestAnimationFrame Timing

requestAnimationFrame (rAF) fires right before the browser runs style/layout/paint for the next frame. This makes it the correct place for any visual DOM mutation.

// RIGHT: Visual updates go in rAF
function animateProgress(element, targetWidth) {
  let currentWidth = 0;

  function step() {
    currentWidth += 2;
    element.style.width = currentWidth + 'px';

    if (currentWidth < targetWidth) {
      requestAnimationFrame(step);
    }
  }

  requestAnimationFrame(step);
}

// WRONG: setTimeout has no relationship to the display refresh
function animateProgress(element, targetWidth) {
  let currentWidth = 0;

  function step() {
    currentWidth += 2;
    element.style.width = currentWidth + 'px';

    if (currentWidth < targetWidth) {
      setTimeout(step, 16); // NOT synced to display — causes tearing
    }
  }

  setTimeout(step, 16);
}

The difference: setTimeout(fn, 16) fires approximately every 16ms, but it drifts relative to the display refresh. Some frames get two updates (wasted work), others get zero (visual stutter). requestAnimationFrame is synchronized to the display's actual vsync signal.

The Double-rAF Trick

Sometimes you need to read layout values that depend on changes from the current frame. A single rAF won't work because the browser hasn't processed your changes yet. The double-rAF technique defers the read to the next frame:

element.classList.add('expanded');

requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    const newHeight = element.offsetHeight;
    console.log('Height after expansion:', newHeight);
  });
});

The first rAF fires before rendering — the browser processes the class change during this frame's style/layout. The second rAF fires before the next frame, by which point layout is complete and offsetHeight returns the correct value without forcing a synchronous reflow.

will-change: The Double-Edged Hint

will-change tells the browser to prepare for a specific property animation by promoting the element to its own compositing layer ahead of time.

/* Promotes to its own layer BEFORE animation starts */
.menu {
  will-change: transform;
}

/* Layer created on hover — may cause visual glitch on first trigger */
.menu-lazy {
  /* no will-change */
}
.menu-lazy:hover {
  will-change: transform;
  transform: translateX(250px);
}

Why It Costs Memory

Every compositing layer consumes GPU memory. A 500x400px element on a 2x device pixel ratio display uses:

1000px × 800px × 4 bytes (RGBA) = 3.2MB per layer

Slap will-change: transform on 50 elements and you're burning 160MB of GPU memory. On a mobile device with 256MB total GPU memory, that's a guaranteed performance regression — the GPU starts evicting and re-uploading textures, which is slower than not having layers at all.

const menu = document.querySelector('.sidebar-menu');

menu.addEventListener('mouseenter', () => {
  menu.style.willChange = 'transform';
});

menu.addEventListener('transitionend', () => {
  menu.style.willChange = 'auto';
});

CSS contain for Rendering Isolation

contain tells the browser that an element's internals are independent from the rest of the page. This lets the browser skip recalculating layout or paint for elements outside the contained subtree.

/* Each card is isolated — changes inside don't trigger layout/paint outside */
.card {
  contain: layout paint;
}

/* Full containment — maximum optimization but requires explicit dimensions */
.widget {
  contain: strict;
  width: 300px;
  height: 200px;
}

/* content-visibility skips rendering off-screen elements entirely */
.feed-item {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

Containment Types

• contain: layout — layout changes inside don't propagate outward. The element becomes a layout boundary.
• contain: paint — nothing inside paints outside the element's bounds. Off-screen contained elements skip paint entirely.
• contain: size — the element's size doesn't depend on its children. You must set explicit dimensions.
• contain: style — counters and quotes scoped to this subtree (rarely needed alone).
• contain: strict — shorthand for layout paint size style. Maximum isolation, maximum savings.
• contain: content — shorthand for layout paint style. Like strict but without size containment.

Measuring with the Performance API

Guessing doesn't work. You need to measure actual frame timing to know where your budget goes.

Frame Timing with rAF

let lastFrameTime = performance.now();
let frameCount = 0;
let droppedFrames = 0;

function measureFrames() {
  const now = performance.now();
  const frameDuration = now - lastFrameTime;
  lastFrameTime = now;
  frameCount++;

  if (frameDuration > 18) {
    droppedFrames++;
    console.warn(`Dropped frame: ${frameDuration.toFixed(1)}ms`);
  }

  requestAnimationFrame(measureFrames);
}

requestAnimationFrame(measureFrames);

Long Animation Frames API

The newer Long Animation Frames (LoAF) API provides detailed breakdowns of frames that exceed 50ms:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long frame:', {
      duration: entry.duration,
      blockingDuration: entry.blockingDuration,
      renderStart: entry.renderStart,
      styleAndLayoutStart: entry.styleAndLayoutStart,
      scripts: entry.scripts.map(s => ({
        name: s.name,
        duration: s.duration,
        sourceURL: s.sourceURL
      }))
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Chrome DevTools Performance Panel

The most powerful tool for frame analysis:

1. Open DevTools → Performance tab
2. Click Record, interact with the page, then Stop
3. Look at the Frames row — green bars are good frames, yellow/red are slow
4. Click a slow frame to see exactly which stage took too long
5. The Main flame chart shows your JavaScript execution
6. Recalculate Style and Layout blocks in purple show rendering work

Putting It All Together

Here's a real-world example: building a smooth card hover animation that respects the frame budget.

.card {
  contain: layout paint;
  transition: transform 200ms cubic-bezier(0.4, 0, 0.2, 1),
              box-shadow 200ms cubic-bezier(0.4, 0, 0.2, 1);
  will-change: transform;
}

.card:hover {
  transform: translateY(-4px);
  box-shadow: 0 12px 24px var(--color-shadow);
}

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: none;
    will-change: auto;
  }
}

This hits every optimization:

• contain: layout paint — card changes don't affect siblings or parent
• transform instead of top — compositor-only animation
• will-change: transform — layer promoted ahead of time (justified because cards are the primary interactive elements)
• cubic-bezier — smooth easing that feels physical
• prefers-reduced-motion — respects accessibility preferences and removes the layer promotion to save GPU memory