CrUX Pipeline Delays: What Late Field Data Means for Client Reports
On Monday an account manager pastes a PageSpeed Insights field screenshot into Slack. Engineering replies with a green lab run from Friday night. The client wants to know why Search Console still says Needs improvement. Three honest artefacts, three clocks, and nobody labelled which lag they meant.
CrUX field numbers carry two dates most decks never write down: when Google published the aggregate, and which 28 days of Chrome sessions sit inside it. Pipeline lag (publication schedule) and rolling-window lag (the average itself) get treated as one bug. That is how a routine delay reads like negligence on a retainer call.
We wrote up how agencies separate those clocks, map daily PSI / CrUX API vs weekly History vs monthly BigQuery, and put copy-ready footnotes on client reports while synthetic monitoring covers the wait.
Name the lag: pipeline slip vs 28-day window vs missing URL-level sample.
Put collectionPeriod firstDate and endDate beside every field number you quote.
Use scheduled lab runs for same-week deploy proof; check field once a week, not every morning.
When History is flat for one week, read CrUX release notes before calling it a regression.
Read more: CrUX pipeline delays and late field data for client reports
