A team marks every <script> on a page as deferred. Lab First Contentful Paint improves, but real users report the page is unresponsive for about a second after it appears, and Total Blocking Time barely moved. Why did deferring not fix that, and what would?

## The confusion at the heart of it There are two separate costs in a script, and people who have only ever tuned attributes tend to collapse them into one: - **Discovery and download cost.** The bytes have to be found and fetched, and while they are fetching they compete with everything else the page needs. This is what loading attributes and hints affect. - **Execution cost.** Once the bytes arrive, the engine parses, compiles and runs them on the main thread. Nothing about how you asked for the file changes this number. Marking scripts as deferred addresses the first cost and leaves the second untouched. First Contentful Paint measures when something appears, so it improves. Total Blocking Time measures main-thread work that keeps the page from responding, so it does not. ## Why the burst is the worst possible timing When every script on the page is deferred, they all become eligible to run at roughly the same moment — after the document has been parsed. The result is a dense block of initialisation: frameworks booting, tag managers evaluating rules, analytics building payloads, widgets constructing DOM. That block lands immediately after the page has visibly rendered. From the user's perspective this is the worst arrangement available. The page looks finished, so they click, scroll or type — and the main thread is busy, so nothing happens for several hundred milliseconds. This is exactly what the field responsiveness metric, Interaction to Next Paint, captures, and it is why a page can hold a fast paint score and a poor real-user experience simultaneously. (INP became the responsiveness Core Web Vital in 2024, replacing First Input Delay, which only measured the delay before the *first* interaction's handler started and largely missed this pattern.) ## Diagnosing it honestly The symptom description already contains the diagnosis: a good paint number next to an unchanged blocking number is the signature of moved-not-removed work. To confirm and to assign blame, record a load profile and look at the main-thread work grouped by which script it came from. Two numbers per script matter: how long it occupies the thread, and whether anything on the first screen depended on it. The scripts that are expensive and unnecessary are your list. ## What actually reduces the cost **Delete.** The largest reliable wins on mature pages come from tags with no consumer. Nothing else improves bytes, execution, connections and failure modes simultaneously. **Ship less that runs at load.** Not all bytes cost the same: what matters is how much code actually executes during startup. A dependency that registers dozens of handlers and builds objects at import time is more expensive than a larger one that only defines functions. Attack initialisation work, not just the file size in a bundle report. **Move code behind the need.** Code for a feature that a minority of visitors use should be fetched when they use it. This converts a guaranteed cost for everybody into an occasional cost for the people who benefit. **Hold third-party tags.** Vendor code is the classic contributor to this burst because several tags each do their own initialisation and none of them are needed for the first screen. Loading them once the page is idle, or on first meaningful engagement, takes their work out of the sensitive window entirely. **Break up what remains.** Some initialisation genuinely has to happen at load. If it runs as one long stretch, split it so the browser gets control back between pieces and can respond to input in the gaps. This does not reduce total work, but it does reduce the longest uninterrupted block, which is what the user feels. ```javascript // Deferred but unconditional: everyone pays for the editor. import { mountEditor } from '/editor.js'; // Conditional: only users who open it pay. document.getElementById('open-editor') .addEventListener('click', async () => { const { mountEditor } = await import('/editor.js'); mountEditor(document.getElementById('editor-root')); }, { once: true }); ``` ## How to say this in an interview State the principle first — deferring relocates work, it does not remove it — then show that you know which metric each action moves. Candidates who answer this question by proposing a different loading attribute have not understood the symptom; the fact that the blocking number did not move is the evidence that the attribute layer has already been exhausted. The remaining levers are all about quantity: less code, later code, or no code. ## The lab-versus-field lesson underneath This scenario is also a good illustration of why a green local score is not a report card. A lab run on a fast machine compresses the burst enough that it may not read as a problem, and lab runs do not include a user clicking during it. The complaint came from real users because the pattern is only fully visible when real people interact with a page while it is still booting.