> I wonder if browser makers can do anything to ease the pain a bit. For example, a page will reflow a few times while it loads, making it hard to start reading immediately. I'll often be mousing to the thing I want to click on next only to see everything move. Could browsers coalesce these reflows so that only completed pages are presented to the user?
Speaking as someone who's worked on browser engines for years now, this is a hard problem. The semantics of the Web demands immediate, synchronous reflows: after performing DOM mutations, any script running on the page can ask for the location of any element on the page, and it requires an up-to-date answer. These APIs are used a lot: almost any news site, for example, is going to use them during initial page load (e.g. for ad placement). So we have to reflow during initial page load.
You might then ask: Why not perform the reflow "in the background" so that the DOM APIs doesn't break, but present a static version of the page as it was initially to the user? The problem with that is that clicking on links (or even mousing over them) is a DOM event that script can be involved in. Besides the fact that you'd basically have to have two simultaneous versions of the DOM around, you'd (for example) break scripts that expect the X/Y coordinates of a mouse-down event on a button to occur inside the boundaries of the button.
Browsers have been coalescing reflows as much as possible within the constraints of the Web, and have for at least a decade. But the semantics of the Web limit what can be done.