Guide on reflow and performance optimizations

[twig-atl]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect

What specific section or headline is this issue about?

getBoundingClientRect() triggers a reflow and performance issues

What information was incorrect, unhelpful, or incomplete?

It was missing something that might be vital for people when debugging issues.

What did you expect to see?

At least a remark or footnote about reflow.

Update from #27189 (comment):

Not sure that it's such a good idea to add this note. Reflow is quite complex and while it's true that it can be a perf bottleneck, such a note may make devs "fear" the APIs where they see that note and prefer less suitable APIs just because they didn't see the note there. For instance, all these getters and methods will only trigger a reflow when the box-model has been dirtied. Calling twice getBoundingClientRect() in a row, or even inside a ResizeObserver callback will not trigger a reflow. Also, some getters will only trigger a partial recalc, like getComputedStyle(element).fontStyle which only needs to walk up the tree from element to get the computed value, where getComputedStyle(element).width would need to recalculate the whole tree because it could be affected by siblings. So maybe if it did link to a complete tutorial on what is layout/reflow and what triggers it, that could be valuable, but even then, some are so unrelated that adding such a note to stuff like CanvasRenderingContext2d#fillText() sounds very weird.

Do you have any supporting links, references, or citations?

https://toruskit.com/blog/how-to-get-element-bounds-without-reflow/

Do you have anything more you want to share?

No response

MDN metadata

Page report details

• Folder: en-us/web/api/element/getboundingclientrect
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/api/element/getboundingclientrect/index.md
• Last commit: bbf7f25
• Document last modified: 2023-04-07T05:55:26.000Z

[advitiya7]

hey i want to contribute to this @twig-atl can you assign this issue to me?
thanks

[twig-atl]

@advitiya7 I don't have access to do that

[wbamberg]

@advitiya7 , I've assigned you :). Thanks!

[Josh-Cena]

From #27189 (comment)

Not sure that it's such a good idea to add this note. Reflow is quite complex and while it's true that it can be a perf bottleneck, such a note may make devs "fear" the APIs where they see that note and prefer less suitable APIs just because they didn't see the note there. For instance, all these getters and methods will only trigger a reflow when the box-model has been dirtied. Calling twice getBoundingClientRect() in a row, or even inside a ResizeObserver callback will not trigger a reflow. Also, some getters will only trigger a partial recalc, like getComputedStyle(element).fontStyle which only needs to walk up the tree from element to get the computed value, where getComputedStyle(element).width would need to recalculate the whole tree because it could be affected by siblings. So maybe if it did link to a complete tutorial on what is layout/reflow and what triggers it, that could be valuable, but even then, some are so unrelated that adding such a note to stuff like CanvasRenderingContext2d#fillText() sounds very weird.

[wbamberg]

Maybe we should just close this issue then?

[Josh-Cena]

Isn't a guide for handling reflow in order, though?

I understand that the performance cliff is only triggered in certain cases, but we probably still need to remind readers that it's not zero/low-cost like it may seem as a getter.

[wbamberg]

Oh, I only read the content, didn't notice the title change. Yes, we should I suppose, but perhaps make the description match?