
What forces layout/reflow in Chrome - tilt
https://gist.github.com/paulirish/5d52fb081b3570c81e3a
======
greggman
And are none of them cached? If I go

    
    
        var w = element.clientWidth;
        var h = element.clientHeight;
    

Is that 2 reflows or 1?

    
    
        var w1 = element1.clientWidth;
        var h1 = element1.clientHeight;
        var w2 = element2.clientWidth;
        var h2 = element2.clientHeight;
    

Is this 4 reflows, 2, or 1?

\---

reading this article
([https://developers.google.com/web/fundamentals/performance/r...](https://developers.google.com/web/fundamentals/performance/rendering/avoid-
large-complex-layouts-and-layout-thrashing?hl=en)) it sounds like it's 0
reflows if nothing has changed. In other words it's all cached

~~~
paulirish
They cause immediate reflow only if the DOM is dirty. In both cases it'd be a
maximum of 1.

This'd be 2:

    
    
        element.textContent = 'omg';
        var w = element.clientWidth;
        elem.classList.add('ok');
        var h = element.clientHeight;

~~~
jffry
And it's especially bad if you interleave them all:

    
    
      var heights = lotsOfElements.map(function(el){
        el.classList.add('ok');
        return el.clientHeight;
      });
    

Better is to batch the DOM updates and reads, where you can:

    
    
      lotsOfElements.forEach(function(el){
        el.classList.add('ok');
      });
      var heights = lotsOfElements.map(function(el){
       return el.clientHeight;
      });

------
amelius
Speaking about reflow, I'm wondering: if I have a piece of text that contains
multiple paragraphs, and I change a single character in the text, will Chrome
recompute the layout for all paragraphs? Is changing a character a O(1)
operation w.r.t. the number of paragraphs?

~~~
paulirish
Just tried this out and the answer is yes. All subsequent elements will have
layout recomputed. There is some room for optimization here (evaluate if the
flow content requires new text-wrapping across lineboxes), but luckily these
layouts are quite fast.

Establishing containers as layout roots (generally fixed height/width and
overflow:hidden) will constrain these sorts of costs.

------
jimrandomh
One related thing that's caused me some grief is that in Chrome, the cost of a
layout is O(n) in the number of hidden elements; so if there's a large number
of DOM nodes hidden inside a node with display:none, they still slow down
reflows.

~~~
paulirish
Somewhat. "Reflow" is typically what we call forced 1) Style Recalc and 2)
Layout. Any hidden DOM elements have zero cost during Layout, as they are
absent in the LayoutTree. However they can contribute to recalc, just while
the browser confirms that they are still display:none.

------
josteink
Sounds like a ripe opportunity to write browser and implementation-specific
JavaScript instead of trying to solve real world problems in a readable and
reusable manner.

This would be more interesting if it wasn't specific to Chrome only, but
looked at the web at large. Maybe specs/things like this could be extended to
be part of the standard instead?

~~~
AgentME
Aren't all of those properties/methods standardized to query something about
the document that require it to be laid out? What do you think the standards
are lacking here?

~~~
josteink
It may have been some of a gut-reaction on my part (and I'm willing to admit
that), but my main gripe with documents like this is that at the moment tons
of web-developers are targeting Chrome only.

When something breaks in Firefox, Safari, Vivaldi, Edge or other browsers
(because obviously it was never tested outside Chrome) their answer is usually
"Just use Chrome".

This is now not only happening at amateur-hour shows and quick Github POCs,
but also at official products from big names like Google.

Basically "This website best viewed in Chrome". Haven't we already been there?
We saw how that worked out, didn't we?

That sort of attitude is not healthy for the web at large, and documents like
this will (IMO) further entrench that attitude, rather than the opposite.

~~~
gopowerranger
>at the moment tons of web-developers are targeting Chrome only.

I'm a web developer and, in my 11 years of doing this, the only people I've
ever seen do that are those experimenting with a new feature that only works
in Chrome or rank amateurs.

Knowledgeable web developers write code to standards, not browsers.

~~~
gsnedders
> Knowledgeable web developers write code to standards, not browsers.

Really? I certainly don't try and work out how the spec says the document
should render — I trust if browsers interoperably render the document the
same, that's what the spec says. And I'm not someone scared of specs, having
contributed to them for years and worked on browsers for years.

~~~
gopowerranger
Yes, really.

You're saying the same thing I am, Geoffrey. Sort of. I expect browsers to
render the same way as the spec says it should. I then verify in each browser.
When they don't, I adjust, but I never write code, only test in ... Opera ...,
and expect it to be identical everywhere. I don't only read the ... Opera ...
blogs and specs and expect it all to work the same all the time.

------
_ZeD_
I needed to know these "implementation details" between css layout and
javascript also regarding css transitions:
[http://stackoverflow.com/questions/12088819/css-
transitions-...](http://stackoverflow.com/questions/12088819/css-transitions-
on-new-elements)

tldr: you can "fade in" a new element only if you trigger a reflow at the
right moment

------
pcwalton
Note that in Servo a lot of reflows can be done off the main thread, not
synchronously. Don't take this list as something that will be true for all
time.

Even if the APIs in question require synchronous reflows now because they
return some data, it may be possible to introduce new APIs that receive the
data in a callback. (The usefulness of these APIs depends on the engine having
support for off main thread layout, of course.)

~~~
paulirish
Yes! This has me quite excited about Servo. Chrome is interested in async APIs
for these as well.

Random aside: Dart's DOM originally offered these properties only as async but
developers were unhappy with the ergonomics so Dart ended up delivering the
sync APIs. :/

~~~
spankalee
If Dart had async/await from the start I bet the async-only APIs would have
been better received.

~~~
paulirish
True dat.

------
dmethvin
For specifics on which CSS properties affect layout, see csstriggers.com .

------
idibidiart
Funny, Chrome uses Blink for rendering and the article talks about WebKit.

~~~
andrewguenther
Blink is a fork of WebKit and still behaves largely the same. Chrome really
hasn't done a whole lot to the underlying layout/reflow logic...yet.

------
idibidiart
Funny, Chrome uses link for rendering and the article talks about WebKit.

