A Save button's click handler on a web page first serializes the whole draft into localStorage, then builds an analytics payload, and only after that updates the DOM to show the "Saved" state. Users say the button feels laggy. What would you change, and why does the order matter?

## The browser cannot paint mid-handler While an event handler is running, the main thread is yours and the browser is not rendering. Style, layout and paint happen after the handler returns control. That single fact explains the whole problem: everything the handler does before it returns is time the user spends staring at an unchanged button. So the question to ask of each statement in a handler is not "is this fast?" but **"does the next frame depend on it?"** In the Save handler: - `status.textContent = 'Saved'` — yes. This is the whole point of the interaction. - `localStorage.setItem('draft', JSON.stringify(draft))` — no. Nothing on screen reflects it. - Building and sending an analytics payload — no. Nobody sees it, ever. Two of the three are ahead of the one that matters. ## Why localStorage is the classic offender `localStorage` has a synchronous API. `setItem` does not return until the value is written, and the value first has to be produced by `JSON.stringify`, which walks the whole object graph. For a small preference that is microseconds. For a document draft it can be tens of milliseconds, entirely on the main thread, entirely in front of the user's feedback. The same shape shows up with any synchronous bookkeeping: recomputing a derived structure, re-sorting a cached list, formatting a log line from a large object. None of it is *wrong*; it is just in the wrong place. ## The reordered handler ```javascript async function onSave(draft) { status.textContent = 'Saved'; // paint-critical await yieldToMain(); // let the frame happen localStorage.setItem('draft', JSON.stringify(draft)); sendAnalytics('save'); } ``` Note that this is two changes, not one. Reordering alone is not enough: if you simply move the DOM write to the top and leave everything in the same synchronous block, the handler still does not return until the write and the payload are done, and the paint still waits. You need the DOM write **and** a genuine handback to the browser before the rest. ## Is deferring always safe? No, and an interviewer may push here. Deferred work can be lost if the page goes away between the paint and the continuation — a navigation, a tab close, a crash. For persistence that matters: - If losing the write would be a data-loss bug, deferring by a frame is still fine in practice (a frame is milliseconds), but re-persisting on page-hide as a safety net is cheap insurance. - For analytics, a beacon-style send is designed to survive unload, which is one reason it is preferred over a plain request in a handler. The general rule: defer freely, but know what happens if the continuation never runs, and choose a mechanism whose failure mode you can live with. ## What this does and does not fix It fixes **perceived** responsiveness and the interaction's measured duration, because the frame the user waits for no longer sits behind unrelated work. It does not make the page do less: the serialise still costs what it costs, the thread is still busy for the same total time, and if the user clicks again immediately, that deferred work is now in front of the *next* interaction. If the bookkeeping is large enough for that to matter, the answer escalates — batch it, debounce it, or get it off the main thread — rather than just moving it a few lines down. ## Recognising the pattern This is one of the highest-yield habits in front-end performance because it costs nothing to apply. Handlers accumulate incidental work over time: someone adds telemetry, someone adds a cache update, someone adds a persistence call, and each is individually trivial. Sorting them into "the frame needs this" and "the frame does not" — and putting a yield between the two groups — routinely recovers tens of milliseconds of felt latency without changing a single algorithm.