This PR addresses a performance issue caused by repeated calls toDrawing.bBox which appends and remove test node to the tester element in the DOM, which were leading to unnecessary layout reflows—especially in scenarios involving complex DOM structures or a large number of CSS variables. These frequent reflows resulted in noticeable performance degradation during initial chart rendering and interactions like resizing, panning, zooming, or updating plots.

Background

Profiling revealed that frequent ``getBoundingClientRectcalls were forcing synchronous reflows inDrawing.bBox`.
While this was negligible in simpler DOM trees, in real-world usage with thousands of CSS variables and deep nesting, these layout recalculations became expensive.
This resulted in degraded runtime performance, particularly visible during initial rendering and chart interaction which require layout updates.

Changes Introduced

Width/height optimization:
- Directly usegetBBox() when only size metrics are needed (avoiding full Drawing.bBox).
Drawing.bBox logic
- For non-text nodes: switched from getBoundingClientRect to getBBox.
- For text nodes: retained getBoundingClientRect to ensure correct positioning. ( asgetBBox fails to compute position fortext node correctly.Raised here )

Impact

Significant reduction in forced reflows during plot rendering/updates.
Maintains accurate text positioning while optimizing other node calculations.
No changes to public API or rendering output.

Aniket Bansaland others added3 commits

July 28, 2025 19:20

Eliminate unnecessary DOM reflows

5045adf

Add draftlogs/7497_fix.md

204dd5a

Merge branch 'plotly:master' into fix/performance-issue-unnecessary-r…

d3cc2d0

…eflows

Copy link

Collaborator

alexcjohnson commentedJul 31, 2025

Thanks@imbansalaniket! There are two cases I'd be concerned about here, which are the original reasons we createdDrawing.bBox in the first place:

the<div> we're plotting into isn't part of the DOM yet.
the<div> or its parents have CSS transforms applied.

I suspect that when we originally wrote thisgetBBox didn't have sufficient support or gave browser-dependent output, but it looks like at least the support has been good for years now. And perhaps its distinct characteristics vsgetBoundingClientRect mean we don't need to worry about CSS transforms anymore?

Anyway if we can ensure these cases still work, and fix the various test failures (there are a bunch of image tests that fail, you can see them in the artifacts here:https://app.circleci.com/pipelines/github/plotly/plotly.js/12418/workflows/12a27ec0-ea1e-45f9-9d25-196d14e5e1b7/jobs/275741/artifacts - also looks like one jasmine test failed here:https://app.circleci.com/pipelines/github/plotly/plotly.js/12418/workflows/12a27ec0-ea1e-45f9-9d25-196d14e5e1b7/jobs/275729) then I'm all in favor of this change.

I guess the other thing to say is we really shouldn't need to do this at all for non-text nodes. I know there are a few cases where we currently do callDrawing.bBox on non-text nodes but in principle we can directly calculate what we need for these cases, which will always be better than asking the browser.

gvwilson requested a review fromemilykl

August 1, 2025 15:31

gvwilson assignedemilykl

Aug 1, 2025

gvwilson added community

community contribution

needed for current cycle

fixfixes something broken labels

Aug 1, 2025

Copy link

Author

imbansalaniket commentedAug 4, 2025

Hi@alexcjohnson, thanks for your feedback,

1. the <div> we're plotting into isn't part of the DOM yet. - yes this make sense asgetBBox return empty object for the node which are not in the DOM, for such node we still need to rely ongetBoundingClientRect.
2. the <div> or its parents have CSS transforms applied. - as you mentioned, yes, getBBox is independent from any transform applied on the node.

For the failing test and recommendation point1. the <div> we're plotting into isn't part of the DOM yet., I will add a fix in upcoming commit.

Thanks