[RUM-12600] Continuous Benchmarking

[amortemousque]

Motivation

We want to monitor the impact of performance-intensive features like Replay and Profiling.
This PR introduces benchmark tests to measure their effect.

We track:

• Memory, CPU, and network using the Chrome DevTools Protocol. Same implementation as /performances, except it only collects the total consumption.
• Web Vitals using Google’s web-vitals package

For now, we run a single scenario, heavy.scenario.ts, which executes a sample app from this PR.

Current results:

Changes

Benchmark tests in /benchmark

Test instructions

1- Run the sample app (from browser-sdk-test-playground)

git checkout aymeric/profiling-benchmark-sites
cd performance-benchmarks/heavy-spa/
yarn && yarn dev

2- Run the benchmark (from browser-sdk)

git checkout aymeric/profiling-benchmark
yarn test:performance

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[datadog-official]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 100.00%
• Total Coverage: 92.63% (-0.00%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0558c91 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[cit-pr-commenter]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	162.85 KiB	162.85 KiB	0 B	0.00%	✅
Rum Recorder	19.78 KiB	19.78 KiB	0 B	0.00%	✅
Rum Profiler	4.89 KiB	4.89 KiB	0 B	0.00%	✅
Logs	56.54 KiB	56.54 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	119.81 KiB	119.81 KiB	0 B	0.00%	✅
Worker	23.60 KiB	23.60 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base CPU Time (ms)	Local CPU Time (ms)	𝚫%
RUM - add global context	0.0049	0.0041	-16.33%
RUM - add action	0.0129	0.0117	-9.30%
RUM - add error	0.0163	0.0112	-31.29%
RUM - add timing	0.003	0.0025	-16.67%
RUM - start view	0.0036	0.0031	-13.89%
RUM - start/stop session replay recording	0.0008	0.0007	-12.50%
Logs - log message	0.0142	0.0131	-7.75%

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	26.53 KiB	25.38 KiB	-1.16 KiB
RUM - add action	45.87 KiB	46.75 KiB	+903 B
RUM - add timing	24.22 KiB	24.34 KiB	+117 B
RUM - add error	50.81 KiB	50.56 KiB	-264 B
RUM - start/stop session replay recording	24.13 KiB	23.63 KiB	-520 B
RUM - start view	427.22 KiB	430.02 KiB	+2.79 KiB
Logs - log message	43.74 KiB	43.11 KiB	-649 B

🔗 RealWorld

[BenoitZugmeyer]

❓ question: ‏What's the logic behind this? The accept-encoding headers tells the server that it can respond with encoded data. FMU this has nothing to do with postData?

Also yeah one limitation of the CDP is that it doesn't expose the request as binary... but I'm not sure encoding the postData to UTF-8 is a good strategy either? 🤔

This is why I went with the proxy route BTW.

[BenoitZugmeyer]

❓ question: ‏I'm curious why we need this? We fixed an issue where the SDK is injected a bit too early #3153 . Did you observe another issue?

[amortemousque]

Good question! In the /performances approach, we use import(bundle_url).then(...), but the issue is that the lazy-loaded module URL resolved by Webpack is incorrect.

I wanted to switch to the regular async setup, but Playwright’s addInitScript runs before any DOM element are accessible. (e.g. document.documentElement is undefined). That’s why I wait until document.readyState === "interactive".

[BenoitZugmeyer]

💭 thought: ‏I think there are more idiomatic ways to declare common test logic in playwright using fixtures. But personally I don't mind your approach, as I find it more explicit than using playwright magic.

[BenoitZugmeyer]

💬 suggestion: ‏extend from the base tsconfig and remove redundant options.