Correction: my rounding explanation was wrong, and the finding is worse than either of us said. You were right to push on it.
You're correct that nothing in the metric path rounds — summarise-web-vitals.mjs takes numericValue straight through for both metrics, and baselineFromRows copies all four from the same row. So I checked where the committed numbers actually came from. Comparing 669640b against the base at da66b28:
| route |
fcpMs before |
fcpMs after |
changed |
| desktop-documents-search |
404.55240000000003 |
404.55240000000003 |
no |
| desktop-dsm |
399.6637 |
399.6637 |
no |
| desktop-forms |
393.5287 |
393.5287 |
no |
| desktop-root |
358.3345 |
358.3345 |
no |
| desktop-therapy-compass |
397.3599 |
397.3599 |
no |
| mobile-documents-search |
2329.335 |
2329.335 |
no |
| mobile-dsm |
2325.841 |
2325.841 |
no |
| mobile-forms |
2291.215 |
2291.215 |
no |
| mobile-root |
3325.742 |
3274 |
yes |
| mobile-therapy-compass |
2327.357 |
2327.357 |
no |
Nine of ten fcpMs values are byte-identical to the pre-refresh file. baselineFromRows writes lcpMs, cls, tbtMs and fcpMs from one row, so a real --update could not have left nine FCPs untouched while replacing every LCP. The refresh did not come from that path.
Where it did come from is legible in the numbers. The new lcpMs / tbtMs / cls values match, exactly, the run column of the markdown table renderBudgetTable printed in the advisory job on run 31183183255 — desktop-documents-search 887 / 1 / 0.119, mobile-documents-search 2311 / 399 / 0.000, mobile-root 3274 / 763 / 0.000. That table is rendered through toFixed(0) and toFixed(3), which is where the integers come from. It has no FCP column — so FCP was left at its old value, and for mobile-root it was filled with 3274, that route's LCP from the same table row.
So the baseline was transcribed from a rendered CI log rather than generated. Consequences:
- The two inversions are not measurement noise inside a rounding window. They are new HeadlessChrome/151 LCPs compared against stale HeadlessChrome/150 FCPs from a different run — exactly the "not from the same complete report set" you diagnosed. My 18ms/7ms rounding argument was wrong.
- Every
lcpMs/tbtMs/cls in the file is now display-precision, not measured precision.
mobile-root's fcpMs is not an FCP measurement at all.
This raises what I'd do about it rather than settling it. 669640b is not on main (git merge-base --is-ancestor 669640b origin/main → false); it exists only on this branch, so reverting it here would drop the corrupt data without touching anything else — and would return the advisory job to failing the way it failed before, which it does anyway. I have not done that, because it is someone else's commit and removing it is a maintainer's call, not mine.
@BigSimmo — three options, your pick: (a) I revert 669640b from this branch, leaving the baseline as main has it; (b) leave it and open the follow-up for a real --update run plus the runner-drift fix; (c) leave it entirely alone. I'd suggest (a) plus (b): committed measurement data that was copied out of a log should not survive on a branch, and the gate needs the version-tolerance fix regardless.
On opening an issue — please don't open one automatically; this repo tracks outstanding work in docs/outstanding-issues.md via its own /issues flow, and a maintainer should decide which lands there.
Leaving this thread unresolved, as you suggested.
Generated by Claude Code
Originally posted by @BigSimmo in #1689 (comment)
Correction: my rounding explanation was wrong, and the finding is worse than either of us said. You were right to push on it.
You're correct that nothing in the metric path rounds —
summarise-web-vitals.mjstakesnumericValuestraight through for both metrics, andbaselineFromRowscopies all four from the same row. So I checked where the committed numbers actually came from. Comparing669640bagainst the base atda66b28:Nine of ten
fcpMsvalues are byte-identical to the pre-refresh file.baselineFromRowswriteslcpMs,cls,tbtMsandfcpMsfrom one row, so a real--updatecould not have left nine FCPs untouched while replacing every LCP. The refresh did not come from that path.Where it did come from is legible in the numbers. The new
lcpMs/tbtMs/clsvalues match, exactly, the run column of the markdown tablerenderBudgetTableprinted in the advisory job on run 31183183255 —desktop-documents-search 887 / 1 / 0.119,mobile-documents-search 2311 / 399 / 0.000,mobile-root 3274 / 763 / 0.000. That table is rendered throughtoFixed(0)andtoFixed(3), which is where the integers come from. It has no FCP column — so FCP was left at its old value, and formobile-rootit was filled with3274, that route's LCP from the same table row.So the baseline was transcribed from a rendered CI log rather than generated. Consequences:
lcpMs/tbtMs/clsin the file is now display-precision, not measured precision.mobile-root'sfcpMsis not an FCP measurement at all.This raises what I'd do about it rather than settling it.
669640bis not onmain(git merge-base --is-ancestor 669640b origin/main→ false); it exists only on this branch, so reverting it here would drop the corrupt data without touching anything else — and would return the advisory job to failing the way it failed before, which it does anyway. I have not done that, because it is someone else's commit and removing it is a maintainer's call, not mine.@BigSimmo — three options, your pick: (a) I revert
669640bfrom this branch, leaving the baseline asmainhas it; (b) leave it and open the follow-up for a real--updaterun plus the runner-drift fix; (c) leave it entirely alone. I'd suggest (a) plus (b): committed measurement data that was copied out of a log should not survive on a branch, and the gate needs the version-tolerance fix regardless.On opening an issue — please don't open one automatically; this repo tracks outstanding work in
docs/outstanding-issues.mdvia its own/issuesflow, and a maintainer should decide which lands there.Leaving this thread unresolved, as you suggested.
Generated by Claude Code
Originally posted by @BigSimmo in #1689 (comment)