Layout Shift and Janky Interactions

Both problems are about trust. A button that jumps as you tap it sends you to the wrong page. An input that shows each letter late makes the app feel broken. They match two Core Web Vitals (Google's measures of page quality): CLS and INP. See Browser Contract, Lesson 09.

The two measures in plain words

• CLS (Cumulative Layout Shift) is a score that adds up how much visible content moves without the user asking for it. Lower is better. Example: a text line jumps down because an image above it finally loaded.
• INP (Interaction to Next Paint) is a time that measures how long the page takes to show a visible response after a click, tap or key press. It reports one of the slowest interactions of the visit. A good INP is 200 ms or less at the 75th percentile.
• Difference in one line: CLS measures things moving by surprise; INP measures the page answering too slowly.

Words used in this lesson

• Layout (also called reflow) is the step where the browser works out the size and position of every element. Paint is the step where it draws the pixels. Changing height forces layout again. Changing transform does not.
• Compositor is the part of the browser that moves already-drawn layers around, often on the graphics chip. transform and opacity can run there, so they are cheap.
• Long task is any piece of main-thread work that runs for more than 50 ms. The page cannot react to the user during it.
• startTransition is a React function that marks a state update as not urgent, so React keeps the page responsive and does that update later. useDeferredValue is a React hook that gives you a delayed copy of a value, so the heavy part of the screen can lag behind the typing.
• scheduler.yield() is a browser function that pauses your code, lets the browser handle clicks and painting, and then continues. setTimeout(fn, 0) does a similar thing the old way: it runs fn in a later task.
• requestIdleCallback is a browser function that runs your code when the browser has nothing urgent to do. requestAnimationFrame is a browser function that runs your code just before the next frame is drawn.
• Web Worker is a separate thread that runs JavaScript in the background. It cannot touch the page, but it does not block it either.
• Debounce means waiting until the user pauses (for example 300 ms) before doing the work. Throttle means doing the work at most once per time period. Difference in one line: debounce waits for quiet; throttle limits the rate.
• content-visibility: auto is a CSS property that tells the browser to skip drawing and layout for content that is off screen.
• Skeleton is a grey placeholder box shaped like the content that will appear. Above the fold is the part of the page you see without scrolling.
• Percentile (p75) is the value below which a given share of results fall. The 75th percentile is the value that 75 out of 100 visits are at or below.

Part 1: layout shift (CLS)

What counts

A layout shift happens when a visible element changes its start position between two frames, and the user did not cause it. Each shift gets a score:

shift score = impact fraction × distance fraction

The impact fraction is how much of the viewport (the visible part of the page) the moving content touched, before and after the move. The distance fraction is how far it moved, compared with the viewport. CLS reports the worst group of shifts during the life of the page. A group (a "session window") is a run of shifts with gaps of less than 1 second between them, and at most 5 seconds long. A good score is 0.1 or less at the 75th percentile (three out of four visits are at or below this score). A score above 0.25 is poor. Shifts that start within about half a second (500 ms) after a click, tap or key press are not counted, for example opening a menu or clicking "show more". The user expects those. Scrolling and hovering do not count as input for this rule.

Common causes and fixes

/* Reserve space before anything loads */.hero img    { width: 100%; height: auto; aspect-ratio: 16 / 9; }.ad-slot     { min-height: 250px; }.avatar      { width: 40px; height: 40px; }.skeleton-row{ height: 56px; }               /* equals the real row height *//* Scroll anchoring keeps the visible content steady when content above it changes (`none` turns it off) */.chat-log { overflow-anchor: auto; }

// dynamic() loads a component only when needed (lazy loading). The loading box keeps the space reserved.const MapView = dynamic(() => import("./MapView"), { ssr: false, loading: () => <div style={{ height: 400 }} /> });

Debugging CLS

1. Chrome DevTools, Performance panel (DevTools is the set of debugging tools built into Chrome): record a page load. The Layout shifts track (in older Chrome versions it is part of the Experience track) marks each shift. Click one to see which nodes moved and the score. The Insights sidebar also has a "Layout shift culprits" entry.
2. Rendering tab, "Layout Shift Regions": it flashes blue where shifts happen, live.
3. Lighthouse points to the elements to blame ("Avoid large layout shifts"; newer versions call it "Layout shift culprits"). It also warns about "Image elements do not have explicit width and height".
4. In code, with a PerformanceObserver (a browser API that calls your function when a performance event happens, such as a layout shift):

new PerformanceObserver((list) => {  for (const entry of list.getEntries() as any[]) {    if (entry.hadRecentInput) continue;               // user-initiated shifts don't count    console.log("shift", entry.value.toFixed(4), entry.sources?.map((s: any) => s.node));  }}).observe({ type: "layout-shift", buffered: true });

5. Real-user data: web-vitals is Google's small JavaScript library that measures Core Web Vitals in real visits. Its attribution build reports the largest shift source for each page view. So you can see which element shifts for real users.

Scenario: the page jumps when a banner loads. Fix it.

• Diagnose with Layout Shift Regions or the Performance track. A script adds the banner <div> at the top after the first paint, and it pushes the page down.
• Fix options (the first is best):
  1. Render the banner on the server, so it is in the first HTML.
  2. Reserve its height with a fixed-size box (CSS min-height) before the script runs.
  3. Make it an overlay (position: fixed pins it to the screen, for example at the bottom), so nothing moves.
  4. Animate it with transform, not layout properties.
• Prevent: add a Lighthouse CI check on CLS (Lighthouse is Chrome's automatic page audit tool; Lighthouse CI runs it on every code change). Set RUM alerts (RUM means real user monitoring: data from real visits) for CLS getting worse. Add a code-review rule: "anything that appears after load must have reserved space."

Part 2: janky interactions (INP and frame drops)

What it feels like

• You type in an input: the letters appear late or in bursts.
• You click a button: nothing happens for a moment, then everything happens at once.
• Scrolling stutters. Animations skip frames.

INP splits one interaction into three parts:

• Input delay: the time before your code can start, because the main thread was busy when the user acted.
• Processing time: the time your event handlers (functions that run when an event such as a click happens) take to run.
• Presentation delay: the time the browser needs to calculate and draw the result on screen.

All three usually have the same root cause: the main thread is busy. See Browser Contract, Lesson 08.

Causes and fixes

Yield so the browser can paint first. This is the "acknowledge, then work" pattern:

button.addEventListener("click", async () => {  button.classList.add("loading");                       // 1. immediate visual feedback  await (globalThis.scheduler?.yield?.() ?? new Promise((r) => setTimeout(r, 0))); // 2. let the browser paint  const result = expensiveWork();                         // 3. then the heavy part  render(result);});

In React, startTransition gives you the same shape. (scheduler.yield() is not in every browser, so the code falls back to setTimeout.) You update the urgent state now. The expensive state updates in the background.

Debugging janky interactions

1. Performance panel: record the interaction with CPU throttling (slowing the CPU down on purpose, so your fast laptop behaves like a phone). The Interactions track shows how long each interaction took and splits it into input delay, processing and presentation. Click a long one and look at the flame chart (each bar is a function call; a wider bar means more time) for the function that takes the most time.
2. Look for long tasks (tasks over 50 ms; DevTools marks them with a red corner) near the interaction, and for forced reflow warnings (JavaScript asked for a size while layout was out of date, so the browser had to redo layout at once).
3. Chrome's Long Animation Frames (LoAF) API (it reports frames that took over 50 ms to draw) and the DevTools Insights link long frames to scripts and callbacks. This helps you blame a specific handler or third-party script.
4. Use the React Profiler (a React DevTools tool that records which components rendered and how long each took) to see the re-render cost during the interaction.
5. Real-user INP: the web-vitals attribution build shows the slowest interaction target and which phase caused the delay.

import { onINP } from "web-vitals/attribution";onINP(({ value, attribution }) => {  navigator.sendBeacon("/vitals", JSON.stringify({    inp: value,    target: attribution.interactionTarget,     // which element    type: attribution.interactionType,         // click, keyboard…    inputDelay: attribution.inputDelay,    processing: attribution.processingDuration,    presentation: attribution.presentationDelay,  }));});

A short checklist

Before launch

• Every image, video, iframe and ad has reserved dimensions.
• Fonts use font-display with a matched fallback (or next/font).
• Skeletons match the final heights. Anything dynamic has reserved space.
• Animations use transform and opacity.
• Event handlers are light. Heavy work is deferred or runs off the main thread.
• Scroll and touch listeners are passive. There are no layout reads in loops.
• Large lists are virtualised or paginated (split into pages).
• Third-party scripts are lazy-loaded and measured.

In production

• RUM tracks CLS and INP with attribution (which element, which phase), split by route and device.
• Alerts fire when numbers get worse. Lighthouse CI guards the main pages.
• Review every new UI pattern with two questions: "What moves when this loads?" and "What runs when this is clicked?"

Common mistakes

1. Images without dimensions (still the number one cause of CLS).
2. Adding content above existing content after load.
3. Skeletons with different dimensions from the final content.
4. Font swaps with no size-matched fallback.
5. Animating layout properties.
6. Doing all the work inside the click handler before the UI updates.
7. Controlled inputs that re-render a huge form on each key press.
8. Not testing on slowed-down CPUs and real devices.

Interview questions

Key takeaways

• CLS means reserve space. Give media dimensions. Use fixed slots for late content. Match skeletons and fonts. Add banners below the content or as an overlay. Animate transform.
• Jank and INP mean free the main thread. Keep handlers light. Defer the rest. Make re-renders narrow. Use passive listeners. Batch layout reads. Virtualise lists. Lazy-load third parties.
• Use Layout Shift Regions and the Interactions track. Collect attribution data in production.
• Guard with Lighthouse CI and RUM alerts. Review every new late-loading or interactive UI with these two questions.

What's next

Lesson 09: Quick Scenario Round. Fifteen common "what would you do?" questions. Each answer has three steps: diagnose, fix, prevent.