This is a slightly weird example because it's adding an empty <div>, so you can imagine it could be optimized if it provably has no effect on layout. But let's

This is a slightly weird example because it's adding an empty <div>, so you can imagine it could be optimized if it provably has no effect on layout. But let's imagine instead that the node added to parent was a div with a text child. Or, slightly less obviously, the div is getting added in a document with a style rule of `div { width: 1000px;} In that case, the width could change. So the browser engine's options are: 1. Return a stale value from parent.innerWidth for now, and just lazily update style at the next event loop iteration. 2. Synchronously update style and layout (note, this update is not as expensive as a from-scratch layout), and return the up-to-date value of parent.innerWidth It turns out that, historically, the earliest browsers with scripting did option (2), and websites came to depend on it. So browsers had to keep on doing it, and so forth. Many folks in the web standards world would like to find away out of this dilemma, where DOM mutation doesn't risk this kind of performance hazard. You could also imagine an extra bad option: 3. Every time the DOM (or the CSSOM) is mutated, synchronously update layout. This is super expensive in the face of repeated DOM mutations. Repeated DOM mutations (e.g. adding multiple elements, setting multiple attributes) are way more common than repeatedly getting style/layout-dependent attributes. (3) has the same observable functional behavior as (2), but it's a lot slower, because it will do a lot of unnecessary layouts. I'm not totally sure if this explains everything you were wondering about, but I hope it helps some.