How would you use DocumentFragment to optimize adding 1,000 list items?
Tests DOM reflow/repaint costs and off-DOM batching. A strong answer: create a DocumentFragment, build the 1,000 nodes off-DOM, then append once to trigger a single reflow. Red flag: claiming it saves memory or confusing it with innerHTML batching.
What's really being asked
This question tests your understanding of the browser rendering pipeline, specifically layout reflow and paint costs. Appending 1,000 elements individually inside a loop forces the browser to recalculate layout, styles, and potentially repaint up to 1,000 times, causing layout thrashing. The interviewer wants to see if you know how to batch DOM mutations off the active document tree to minimize reflows.
The full answer
First, instantiate a DocumentFragment with document.createDocumentFragment. Second, loop through the API response and create each li element, appending it to the fragment rather than the live DOM. Because the fragment is not part of the active document tree, these appends trigger zero reflows or repaints. Third, perform a single append of the fragment to the target parent node in the live DOM, for example ul.appendChild(fragment). Fourth, note that per the MDN specification, this operation moves the fragment's child nodes into the DOM and leaves behind an empty DocumentFragment object. The net result is exactly one reflow and one repaint regardless of child count.
The mistakes people make
Claiming that DocumentFragment reduces memory usage; it does not, it reduces layout calculations. Suggesting innerHTML as the obvious better solution without acknowledging HTML parsing overhead, string escaping, or XSS risks. Failing to mention that the fragment empties itself upon insertion into the DOM. Describing the fragment as a virtual DOM or shadow DOM equivalent. Saying you would hide the parent with display none first, which is a workaround rather than the idiomatic fragment pattern.
What usually comes next
How does this compare to using a template element or cloning a template? Would requestAnimationFrame change your approach? How would you measure the improvement using the Performance API? What happens if you need event listeners on each li; would delegation change your design? Does DocumentFragment help with memory fragmentation?
A concrete example
Suppose you have an unordered list with id items. You write const fragment = document.createDocumentFragment(); data.forEach(item => { const li = document.createElement('li'); li.textContent = item.name; fragment.appendChild(li); }); document.getElementById('items').appendChild(fragment); After the last line, fragment.childNodes.length is zero and all one thousand list items appear in the page after a single layout pass.
Interview question
When appending 1,000 newly created elements in a loop, why does using a DocumentFragment improve performance over direct parent append?
- a.It queues all mutations and applies them asynchronously on the next animation frame
- b.It temporarily sets display:none on the parent to suppress layout calculations until insertion
- c.It exists outside the active document tree, so appends do not trigger reflows or repaintsCorrect
- d.It compresses child nodes into a lighter memory structure, reducing RAM usage during creation
Why? this is the answer
C is correct because a DocumentFragment lives outside the active document tree, so batch appends inside a loop cause zero reflows until the single final insertion. A is a tempting distractor because beginners often wrongly assume fragments reduce memory usage, but they actually minimize layout calculations.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #dom
- #performance
- #documentfragment
- #browser-rendering
- #typescript
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 dom — each one lists the topics its interview covers.
See open roles