fix(web-vitals): use PerformanceEntry.startTime for web vitals log timestamps where possible

[joseph-embrace]

What problem is this solving?

We have an inconsistency with how the log timestamps are set:

• CLS uses metric.attribution.largestShiftTime
• INP uses metric.attribution.interactionTime
• Everything else uses the time that web-vitals emitted the metric (this.perf.getNowMillis())

Metrics can be emitted very long after they occur, so we are not capturing the correct timestamp for other metrics.

Short description of changes

I believe the log timestamp should be the time when the metric actually started. For INP this is still interactionTime. For CLS it's the start of the first layout shift (which is also the start of the session window). For everything else it's the PerformanceEntry.startTime for the most recent entry*.

*^{in practice, most metrics only have one entry}

⚠️ I have also bumped the bundle size limit from 56 -> 60 KB.

How has this been tested?

Unit tests

Checklist

• Documentation added
• Tests added

[github-actions]

Chrome DevTools Protocol Tracing (Script: 125.23ms, Heap: 12.62MB)

	Number of Requests	Size of Requests	Script Duration	Task Duration	Heap Used Size
Requests	+13 requests	+43.04 KB
Page Loaded			+22.34 ms	+16.38 ms	+1.19 MB
Generate 100 fetch requests			+21.70 ms	+73.14 ms	+1.70 MB
Generate 100 XHR requests			+42.28 ms	+111.85 ms	+2.75 MB
Click 100 buttons and generate 100 logs			+28.55 ms	+53.95 ms	+2.36 MB
Throw a 100 exceptions			+0.29 ms	+35.89 ms	+2.47 MB
End Session			+10.08 ms	+39.99 ms	+2.15 MB
Total	+13 requests	+43.04 KB	+125.23 ms	+331.19 ms	+12.62 MB

Lighthouse (Script Eval: 137.94ms)

	Difference	Description
Total Blocking Time	+5 ms	Difference in Total Blocking Time: Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. Learn more about the Total Blocking Time metric.
Main Thread Time	+111.40 ms	Difference in Main Thread Time: Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to minimize main-thread work
Script Evaluation Time	+137.94 ms	Difference in Script Evaluation Time: Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to reduce Javascript execution time.

Platform Tests (vite-7 es2015 gzip: 70.83KB)

vite-6 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-6 - es2015	+209.48 KB	+70.90 KB

vite-7 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-7 - es2015	+209.48 KB	+70.83 KB

webpack-5 Platform Tests

	Total Uncompressed Size	Total Gzip Size
webpack-5 - es2015	0 KB	0 KB

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.87%. Comparing base (1cc54a8) to head (70b477d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1420      +/-   ##
==========================================
- Coverage   96.87%   96.87%   -0.01%     
==========================================
  Files         233      233              
  Lines       10183    10208      +25     
  Branches     1440     1447       +7     
==========================================
+ Hits         9865     9889      +24     
- Misses        316      317       +1     
  Partials        2        2              

Files with missing lines	Coverage Δ
...bVitalsInstrumentation/WebVitalsInstrumentation.ts	97.80% <100.00%> (+0.14%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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