5 ms·

Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements out

Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large <table> rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of <table>.

deleted 1y ago
[deleted]
liuliu 1y ago
Thank you! This is what I am looking for in HN comments. Layout engine cannot be that stupid per the article. I guess it is not once you give it enough hint.
codeptualize 1y ago
This is the answer. I thought this was fairly common knowledge, height is animated quite often (think dropdowns), no need for the over complications.
alexchantavy 1y ago
Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?
- brokencode 1y ago
  Usually you try to build something, realize it’s slow, then do a combination of searching for possible solutions, trying them, and profiling again and again to gain this knowledge. Experience is the best teacher.
- notatoad 1y ago
  not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes. the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.
  - socalgal2 1y ago
    I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.
    - notatoad 1y ago
      yes. i don't mean to unfairly criticize the web as a platform, i just know it's warts because it's the platform i work on. my criticism is reserved for the concept of "first principles", as if there should be a cohesive and simple set of rules that you can build up all the knowledge you need from. that's just not really how any complicated system works: building a comprehensive understanding of a complicated system takes a lot of work and a lot of time.
    - troupo 1y ago
      It's not "completely responsive". And literally every other GUI is just as responsive when coded for those screens. Have you never resized a window on a desktop OS?
- RumourRider 1y ago
  You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually. If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is out of date now due to improvements in Browser engines, the fundamental ideas are still the same. https://www.youtube.com/watch?v=mHtdZgou0qU https://www.youtube.com/watch?v=mHtdZgou0qU If you skip to the 35 minute mark he speaks about reflow specifically. Generally I still use many of these techniques when writing vanilla JS (which is unfortunately rare these days). There are other talks where he talks about many other performance specific topics. Obviously none of this is as good as real world experience of dealing with a thorny issue.
  - troupo 1y ago
    > If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"
    - RumourRider 1y ago
      Yes it will. Most of the CSS styling is literally wrappers around draw calls.
      - troupo 1y ago
        Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"? Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc." Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but will only consume 6% if you go out of your way to make it 'performant'"?
- eviks 1y ago
  Not sure, but if CSS first principle is parent sets width going down to children, but sets height going up from children, then you could see how children changing its height leads to layout recalc all the way up. So the you need to fix that height /remove resize, then google on which technique to use?
- deleted 1y ago
  [deleted]
- dsego 1y ago
  Understanding the document's flow layout, block and inline elements and build on top of that.
legitster 1y ago
As an old-school webguy, fixes like this article make me sad. The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.
- sema4hacker 1y ago
  I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
  - adastra22 1y ago
    All modular, I hope.
  - nonethewiser 1y ago
    Looks like its using YUI (a yahoo UI library) that was deprecated in 2011 in favor of YUI 3 (which is now deprecated as well). https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.
- dotancohen 1y ago
  A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.
- bartread 1y ago
  Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case. The acceptable range would be something like 0 - 1% when no interactions are taking place. I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there. Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).
bfgeek 1y ago
This likely more effective quite a few years ago, but not particularly important today. Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes. "overflow: clip" is also much more lightweight than "overflow: hidden"
spankalee 1y ago
`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.
- bobbylarrybobby 1y ago
  https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!
dotancohen 1y ago
> Just wrap it in a container with fixed height and "overflow: hidden". That's a fix for a webdev who cares, not a fix for a browser vendor as GP was alluding to.
- fiddlerwoaroof 1y ago
  I don't understand how you'd fix this, in general, for the browser: the browser can't just assume certain animations will never affect layout.
  - kadoban 1y ago
    It could _probably_ figure out a lot of cases via some kind of static or runtime analysis. Like the example from the linked article, there's one animation involved essentially and if the browser does the hard work for the entire length of one animation cycle and no layout ever changes, just assume it never will? It would have to have a bunch of edge cases to handle correctly I'm sure though.
    - deepsun 1y ago
      Browsers layout engines are pretty smart, and also optimized for speed at the same time, which makes them very complex. I can do one or the other in my code, but both is too hard. Now add there security. But Google having more people working on Chrome than on Android I would say all the low-hanging optimizations have already been optimized, and all that's left is pretty complex even for teams of thousands.
troupo 1y ago
Translation: just make a completely different functionality and effect than what was originally intended because the DOM can only handle static content, barely.
- kadoban 1y ago
  The suggested change wouldn't affect functionality or the effect. It just tells the browser that there's a thing around the changing part with a fixed size that can't possibly change layout of anything around it, to the user it's invisible.
  - troupo 1y ago
    It will literally change the intended functionality by, placing it in a container of fixed height and overflow hidden

deleted 1y ago

[deleted]

liuliu 1y ago

Thank you! This is what I am looking for in HN comments. Layout engine cannot be that stupid per the article. I guess it is not once you give it enough hint.

codeptualize 1y ago

This is the answer. I thought this was fairly common knowledge, height is animated quite often (think dropdowns), no need for the over complications.

alexchantavy 1y ago

Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?

brokencode 1y ago
Usually you try to build something, realize it’s slow, then do a combination of searching for possible solutions, trying them, and profiling again and again to gain this knowledge. Experience is the best teacher.
notatoad 1y ago
not really. the web is 30+ years of fixes, shortcuts, compatibility hacks, tech industry politics, and other assorted mistakes. the "first principles" to understand it all is the complete set of mailing list archives of the WhatWG, plus the archives of the bug trackers of all the major browsers.
- socalgal2 1y ago
  I don't think it would be different for any other system. Trying to make a piece of computer software that is completely responsive to big displays, small displays, touch screens, mice, etc is just a ton of work and a ton of small details you can't easily learn until you need to learn them.
  - notatoad 1y ago
    yes. i don't mean to unfairly criticize the web as a platform, i just know it's warts because it's the platform i work on. my criticism is reserved for the concept of "first principles", as if there should be a cohesive and simple set of rules that you can build up all the knowledge you need from. that's just not really how any complicated system works: building a comprehensive understanding of a complicated system takes a lot of work and a lot of time.
  - troupo 1y ago
    It's not "completely responsive". And literally every other GUI is just as responsive when coded for those screens. Have you never resized a window on a desktop OS?
RumourRider 1y ago
You need to think about what the browser is actually doing when it displays a web page. You need to think about what happens when you type the URL in and what the browser is doing conceptually. If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. There is an old school talk by Nikolas Zakas on JavaScript Performance from 2009 which while some of it is out of date now due to improvements in Browser engines, the fundamental ideas are still the same. https://www.youtube.com/watch?v=mHtdZgou0qU https://www.youtube.com/watch?v=mHtdZgou0qU If you skip to the 35 minute mark he speaks about reflow specifically. Generally I still use many of these techniques when writing vanilla JS (which is unfortunately rare these days). There are other talks where he talks about many other performance specific topics. Obviously none of this is as good as real world experience of dealing with a thorny issue.
- troupo 1y ago
  > If you have any experience programming 2D graphics with SDL this will help you to understand what is happening as well. No. No it will not. Nothing in 2D graphics will help you understand things like "simple animation required full layout re-calculation and re-painting of the entire page"
  - RumourRider 1y ago
    Yes it will. Most of the CSS styling is literally wrappers around draw calls.
    - troupo 1y ago
      Which draw calls result in "changing border width will cause a full page re-flow in some browsers, and bot others"? Which draw calls are "literally any animation will cause the full re-flow of the document unless you make sure an element is not a part of the document, but then you'll have issues with positioning, weird gaps etc." Which draw calls teach you that "well, this primitive animation consumes 15% of CPU, but will only consume 6% if you go out of your way to make it 'performant'"?
eviks 1y ago
Not sure, but if CSS first principle is parent sets width going down to children, but sets height going up from children, then you could see how children changing its height leads to layout recalc all the way up. So the you need to fix that height /remove resize, then google on which technique to use?
deleted 1y ago
[deleted]
dsego 1y ago
Understanding the document's flow layout, block and inline elements and build on top of that.

legitster 1y ago

As an old-school webguy, fixes like this article make me sad. The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.

sema4hacker 1y ago
I just went to the McMaster-Carr home page and right-clicked for "View Page Source". There's a LOT of code there.
- adastra22 1y ago
  All modular, I hope.
- nonethewiser 1y ago
  Looks like its using YUI (a yahoo UI library) that was deprecated in 2011 in favor of YUI 3 (which is now deprecated as well). https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html https://yui.github.io/yui2/docs/yui_2.5.0/docs/index.html Im seeing a lighthouse mobile performance of 64 with Javascript execution time, unused js, legacy js on modern browsers, etc. as some of the top reasons.
dotancohen 1y ago
A few years ago a client that I hadn't spoken to in half a decade called me to thank me. He wanted to update his website to work with tablets, checked before calling me, and realized that his website just simply worked. Being the caveman that I am, I wrote the damn thing using the simplest CSS possible. Simple equals compatibility in this field.
bartread 1y ago
Well, and especially because the “fixed” version is still - if I’ve read correctly - consuming 12% CPU before any user interaction on a page that’s otherwise substantially a plain or possibly RTFish text editor. How is that considered acceptable? It’s still going to drain the battery faster than is justified, even if at a somewhat reduced rate from the pre-fixed case. The acceptable range would be something like 0 - 1% when no interactions are taking place. I’d still deploy the fix in the article as an interim solution - better is after all better - but I wouldn’t stop there. Front-end web devs need to have more respect for power consumption and battery life (proxies by CPU and GPU usage).

bfgeek 1y ago

This likely more effective quite a few years ago, but not particularly important today. Changing height typically only shifts elements, and browser engines typically wont relayout them due to position changes. "overflow: clip" is also much more lightweight than "overflow: hidden"

spankalee 1y ago

`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.

bobbylarrybobby 1y ago
https://developer.mozilla.org/en-US/docs/Web/CSS/contain https://developer.mozilla.org/en-US/docs/Web/CSS/contain Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!

dotancohen 1y ago

> Just wrap it in a container with fixed height and "overflow: hidden". That's a fix for a webdev who cares, not a fix for a browser vendor as GP was alluding to.

fiddlerwoaroof 1y ago
I don't understand how you'd fix this, in general, for the browser: the browser can't just assume certain animations will never affect layout.
- kadoban 1y ago
  It could _probably_ figure out a lot of cases via some kind of static or runtime analysis. Like the example from the linked article, there's one animation involved essentially and if the browser does the hard work for the entire length of one animation cycle and no layout ever changes, just assume it never will? It would have to have a bunch of edge cases to handle correctly I'm sure though.
  - deepsun 1y ago
    Browsers layout engines are pretty smart, and also optimized for speed at the same time, which makes them very complex. I can do one or the other in my code, but both is too hard. Now add there security. But Google having more people working on Chrome than on Android I would say all the low-hanging optimizations have already been optimized, and all that's left is pretty complex even for teams of thousands.

troupo 1y ago

Translation: just make a completely different functionality and effect than what was originally intended because the DOM can only handle static content, barely.

kadoban 1y ago
The suggested change wouldn't affect functionality or the effect. It just tells the browser that there's a thing around the changing part with a fixed size that can't possibly change layout of anything around it, to the user it's invisible.
- troupo 1y ago
  It will literally change the intended functionality by, placing it in a container of fixed height and overflow hidden