Describe the difference between DOMContentLoaded and window.load
This tests critical rendering path knowledge. DOMContentLoaded fires after HTML parsing and deferred scripts, while load waits for all subresources; use the former to bind UI early.
Defaulting to load, which stalls interactivity until images finish.
What's really being asked
This question probes whether you understand the browser's parsing and resource-loading pipeline beyond surface-level definitions. Senior engineers are expected to know exactly when the DOM is safe to query and manipulate versus when every external dependency has arrived, because choosing the wrong milestone directly impacts perceived performance, user interactivity, and Core Web Vitals scores.
The full answer
First, define DOMContentLoaded as the moment the HTML parser finishes and all deferred scripts have downloaded and executed, noting that it does not wait for stylesheets unless a parser-blocking script is present. Second, define the load event as the point where every image, iframe, stylesheet, and async script has finished loading. Third, explain the performance rationale: attaching click handlers, hydrating components, or reading layout metrics inside DOMContentLoaded lets users interact with the page while heavy assets are still in flight, whereas waiting for load defers all interactivity until the last byte arrives. Fourth, mention the readyState guard for dynamically injected scripts that might run after DOMContentLoaded has already fired.
The mistakes people make
A red flag is saying the two events are interchangeable or that load is safer for all initialization. Another is claiming DOMContentLoaded waits for images or that stylesheets always block it; the nuance is that stylesheets block parser-blocking scripts, which in turn can delay DOMContentLoaded. A third red flag is recommending async scripts inside the head to speed up DOMContentLoaded without acknowledging that async scripts can still interrupt parsing if they arrive early and execute immediately.
What usually comes next
An interviewer might ask how defer versus async influences these events, or how to measure the gap between DOMContentLoaded and load in the field. They may also ask what happens if a script checks document.readyState after a top-level await in a module, or how server-side hydration and modern frameworks change which event you listen to.
A concrete example
Imagine a product listing page with 40 high-resolution images. If you wait for window load to attach the Add to Cart button handlers, users cannot click anything until all 40 images finish downloading, which could take 2 to 5 seconds on 3G. Instead, listen for DOMContentLoaded to bind those handlers and initialize the cart state; the images can continue loading in the background while users already interact with the page.
Interview question
When initializing UI handlers on a page with external images, which distinction between DOMContentLoaded and window.load matters most?
- a.DOMContentLoaded always blocks until all stylesheets finish downloading, so load is safer for initialization
- b.window.load fires once the HTML parser finishes, while DOMContentLoaded waits for every stylesheet and image
- c.The two events are interchangeable today, though load provides better backward compatibility
- d.DOMContentLoaded fires after deferred scripts run but does not wait for images, letting handlers bind earlierCorrect
Why? this is the answer
DOMContentLoaded fires after HTML parsing and deferred scripts complete, so you can bind UI handlers before heavy assets like images finish, whereas window.load waits for all subresources. The most tempting distractor reverses the two events: window.load is the one that waits for every asset, not DOMContentLoaded.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on web apis — each one lists the topics its interview covers.
See open roles