♻️trackCumulativeLayoutShift: Get the biggest element attribution (instead of the first one)

[anediaz]

trafficstars

Motivation

https://datadoghq.atlassian.net/browse/RUM-9262

We’ve recently identified an issue on how the Browser SDK reports the shifted element data for CLS.

The way it is reported today, from the list of elements having contributed to the biggest shift, always the first one is returned by the Browser SDK, while the list is not sorted by element size, instead of the biggest one. Take a look at this example, that proves it:

https://github.com/user-attachments/assets/c74f76d7-a277-4718-aff5-ff5dd1bab6d3

[!NOTE] The CLS official documentation recommends using this method, in order to get the biggest element contributing to the shift. In addition, we can find the same proposal in this snippet in web-vitals-report repository

In the Optimize Inspect page, this can lead us to confusing situations, where for a significant CLS, the element we’re showing as the most relevant one is considerably small (comparing to the CLS score), while, in the element list contributing to this poor score, there could be other elements that are bigger, and so more relevant to highlight as candidates for the poor CLS.

As an example, here’s a recent case where we showed a poor CLS with a small shifted element:

Changes

Adapt cls tracking logic to pick the source having the biggest area among those attributed to the CLS entry

Testing

• [ ] Local
• [ ] Staging
• [ ] Unit
• [ ] End to end

---

I have gone over the contributing documentation.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.00%. Comparing base (4266bcd) to head (9d84857). Report is 102 commits behind head on main.

:exclamation: Current head 9d84857 differs from pull request most recent head 3d2b120

Please upload reports for the commit 3d2b120 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3447      +/-   ##
==========================================
+ Coverage   91.98%   92.00%   +0.01%     
==========================================
  Files         310      311       +1     
  Lines        8026     8046      +20     
  Branches     1820     1822       +2     
==========================================
+ Hits         7383     7403      +20     
  Misses        643      643              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cit-pr-commenter[bot]]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	0 B	145.52 KiB	145.52 KiB	N/A%	✅
Rum-recorder	0 B	18.02 KiB	18.02 KiB	N/A%	✅
Rum-profiler	0 B	4.64 KiB	4.64 KiB	N/A%	✅
Logs	0 B	50.16 KiB	50.16 KiB	N/A%	✅
Rum Slim	0 B	105.05 KiB	105.05 KiB	N/A%	✅
Worker	0 B	23.59 KiB	23.59 KiB	N/A%	✅

🚀 CPU Performance

Action Name	Base Average Cpu Time (ms)	Local Average Cpu Time (ms)	𝚫
addglobalcontext	0.002	0.002	-0.000
addaction	0.052	0.039	-0.013
addtiming	0.001	0.001	-0.000
adderror	0.047	0.041	-0.006
startstopsessionreplayrecording	0.008	0.012	0.004
startview	0.415	0.409	-0.006
logmessage	0.020	0.021	0.001

🧠 Memory Performance

Action Name	Base Consumption Memory (bytes)	Local Consumption Memory (bytes)	𝚫 (bytes)
addglobalcontext	NaN KiB	25.02 KiB	NaN KiB
addaction	NaN KiB	54.65 KiB	NaN KiB
addtiming	NaN KiB	24.55 KiB	NaN KiB
adderror	NaN KiB	57.71 KiB	NaN KiB
startstopsessionreplayrecording	NaN KiB	23.61 KiB	NaN KiB
startview	NaN KiB	425.46 KiB	NaN KiB
logmessage	NaN KiB	54.84 KiB	NaN KiB

🔗 RealWorld