What forces layout/reflow in Chrome | Hacker News Reader

What forces layout/reflow in Chrome

gist.github.com

88 pointstilt43 comments

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...) it sounds like it's 0 reflows if nothing has changed. In other words it's all cached

If the layout isn't "dirty" from a change, then it doesn't need to reflow.

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;

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;
  });

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?

It depends if it creates a new line (and therefore a new line box).

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.

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.

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.

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?

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?

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.

Developers (and me as one of them) seek their sanity. They try to achieve what they've been asked to, by following the specs. There are some browsers that are always up-to-date with the specs, and there are other browsers that still have 5 year old bugs to fix.

If those browsers are still in popular use, and you call yourself a professional web developer, you test and ensure things work in those old and terrible browsers too though.

But like I said, there are plenty of amateur-hour gigs following your play-book.

You decide which group you want to identify with. For me part, I know which I represent.

And thus for a small rant:

On a side note, I love how web-developers these days have the nerve to tell people how hard their job is because they have to support several browsers. Cry me a river. Nobody's job has ever been easier than yours.

Do you have to deal with messages not getting through in a message pump when threads are involved? Do you have to deal with how GPU accelerated graphics frameworks magically sometimes not showing windows when run in a Citrix TS, but with faulty Intel GPU drivers on the server? Have you ever tried to figure out why your code isn't getting the correct registry-entries, which you can see is there in a mixed 32-64 registry mess? Why that setting a configured was never shell-expanded, causing your script to break 3 layers in? Have you ever tried to debug why the file you just released a handle for is still locked, by yourself? Etc etc. These things a million times every day.

Web-developers have it so easy peasy as no other programmer in the history of programmers. I'll admit that's an opinion, but I'm pretty sure it closer to a fact.

Signed someone who has delivered cross-platform products, on-premise software across several versions and decades, with demands that nothing should ever be broken no matter what.

And yes my job is 'easy'. And I personally try to always serve legacy browsers too. And yes I will always complain until those browsers will finally fix their bugs and implement what the specs say.

> If those browsers are still in popular use, and you call yourself a professional web developer, you test and ensure things work in those old and terrible browsers too though.

That's not my decision to make as it impacts production costs. The person paying the bills should be the one that makes the decision and my job is to inform him of the probable costs and provide statistics so he can measure the cost vs benefit for his intended audience.

I'm so tired of hearing this. Just because web developers need to solve different problems doesn't mean it's easy.

This kind of crab mentality of "you aren't a real developer until you are miserable like me" is really getting old and it only serves to make the whole industry look standoffish and bad.

Yes, some of the work I do on the web is easy, but so is the view components of any other system. The time spent bit twiddling to try and get a little more performance out of a browser to be able to render a game at 60 FPS or spending time understanding what each browser compiles my JS to under the hood (after it was "transpiled" [i hate that word] from another JS dialect) so that I can figure out why what should be a simple copy is taking so fucking long is just as difficult as some of the shit you have to deal with.

Stop trying to make it into a contest.

That applies when you build websites. But when you build web apps, you care more about providing the best optimal experience for the up-to-date browsers and if you have enough time you can provide a graceful degradation for the old browsers. But most of the time it depends on what you've been ordered to build and which users you want to focus.

Keyword: enough time. Spent two day working around a firefox outline bug only to have it break on mobile safary because their absolute positioning of pseudo elements is relative to the parent and not the element.

Browsers are making my day to day work miserable. I wish O could target a reference css3 platform and browser specific bugs be damned.

>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.

WhatsApp Web? Google Inbox? Very good examples that were unnecessarily "only works in Chrome".

Changing your User agent also allowed you to use both in Firefox.

Both of these did not allow other browser when they were released, today both work fine on FF.

Details on why Inbox wasn't available at first are available in this thread: https://news.ycombinator.com/item?id=8606879

And still, for a few months two recent web products were limited to one browser, which is used by a minority, and is in many countries not even the largest minority.

And still rely on UA hackery in Opera, which given in principle it relies on the same version of the Chromium Content API as the current Chrome release, it's fairly obvious it's a business decision and not a technical one.

> 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.

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.

> Knowledgeable web developers write code to standards, not browsers

Users are running browsers, not standards. Writing to standards only works once the standard is widely distributed and implemented.

Of course, you must wait for implementation. As I said in another post, you must still test in the browsers to make sure they work but to only use a property available in one browser, or to write code and test in only one browser (the subject of this thread), is a fault of the developer and an error of omission.

You can take a look at the diffs between this and what the list was in 2011 for Webkit:

http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-...

They look basically the same to me - this part of a browser layout engine hasn't changed much, and probably isn't likely to unless Chrome goes all GPU-rendering. And it includes Webkit browsers as well, so it's also Safari, mobile Safari, Opera, and Android Browser.

Just FYI: GPU can only used for accelerated compositing (animations) and rasterization (faster paint). We'll need new or async APIs for this stuff to significantly change things at the platform level. In the meantime, we have Virtual DOM and maybe a transactional API for read/write to help alleviate the common cases.

Thx for linking up Tony's post btw!

This stuff is 90% consistent cross-browser, but it's possible IE has a larger list, or smaller list. In retrospect, I coulda left off the "Chrome" specifier on it.

I needed to know these "implementation details" between css layout and javascript also regarding css transitions: http://stackoverflow.com/questions/12088819/css-transitions-...

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

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.)

Interesting. How is something like e.g. reading offsetTop done asynchronously? The js would still need immediate access to the value.

We'd need a new API for it.

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. :/

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

True dat.

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

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

Under the heading "Other browsers"?

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.

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

Reply on news.ycombinator.com