Fourteen days separate Chrome 153 Stable from Chrome 154 Stable [1]. Put that against the field window. CrUX advances one day at a time, oldest day out and newest day in, and there is no switch that flips the whole population onto the new major on release day [7]. The window has no opinion about your release calendar. Two release boundaries therefore fit inside 28 days, which means sessions from three consecutive majors can land in the same p75 [2]. The dev.to post that works this through describes the blend as two adjacent majors [9]; two is the floor, because people who auto-update mid-window contribute post-update sessions beside pre-update ones in one aggregate [8].
What a Stable release changes is the measurement path: paint timing, image decoding, lazy-loading heuristics, interaction scheduling, on a page nobody touched [8]. Change the version mix inside the window and the published p75 moves while your bundles are byte-identical to last month [10]. The same post reads an amber band after a quiet week as population mix first: who updated, which channel they run, how fast auto-update spread [20].
The instinct is to slice the data by exact Chrome major and settle the argument. The post says check sample thresholds before you do [15]. The arithmetic says why: at a fortnightly cadence each major owns 14 days of the window rather than 28, so the sessions attributable to a version halve before you have also split by device, country and template [5].
Eight weeks against two is four majors of drift [3], which is how a retail origin and a locked-down corporate fleet come to read different field bands on the same URL template [11].
Annotation alone will not close this. Origin-level field LCP also moves when the homepage's share of traffic falls and a slower category listing gains, with no code change on either template [12]. So the division of labour has to be explicit: a lab run on a fixed URL answers whether your deploy changed the critical path, and CrUX answers what Chrome users experienced across versions and journeys [13]. Scheduled runs in the same week are the evidence that the origin held still [16].
Chrome's branch cut for 153 lands 14 days before its public Stable [4], so the vendor's own validation window now equals its shipping interval. Smaller, more frequent releases remain the right call for security and platform velocity [18]. The compression just propagates outward to everyone whose reporting cycle is still monthly.
