What it does: After a plugin or theme update, current Core Web Vitals are compared with the previous baseline and a regression is flagged and e-mailed. Since 2026-09-05 the row also says which assets changed: the scripts and stylesheets the front end gained, lost or resized. How to access: VelocityForge > Monitoring, the regression table’s “What changed” column — one line of prose, expanding to the per-asset detail where there is any. Notes:

• The “before” snapshot is taken on upgrader_pre_install, immediately before the files are replaced, by loopback-fetching the real front page and reading its and queue out of the served HTML — the rendered page, not the handle registry.
• A non-2xx response is refused before the body is parsed. During a bulk update WordPress serves a 503 maintenance page that parses perfectly into an empty asset list, which would have made the entire real queue look like an addition.
• The fan-out is bounded: at most 24 assets are sized per snapshot and the sizing stops after a 3-second budget, so a bulk update of twenty plugins cannot eat max_execution_time from inside install_package(). An asset past the limit is still listed, just without its byte count.
• Both the page fetch and the size probes go through Forge_Net's SSRF guard, because the URLs come out of someone else's HTML.
• Measurements are only ever compared against measurements from the same instrument. A real visitor's browser, a loopback scan and a Lighthouse run from Google's edge are three yardsticks, and comparing two of them reports a regression whose only cause is the change of yardstick.