Page Speed Automation measures Core Web Vitals on mobile first and reads them off the document rather than off a picture of it. That distinction is not pedantry. It is a mistake we made on this very site, diagnosed a bug that did not exist, and shipped CSS to fix it before measuring properly and reverting the lot.
Page Speed AutomationPart of the Website Optimisation module. Switched on and off per account, so you never pay for a module sitting idle.
Not a desktop score with a mobile tab. The layout viewport is set properly and the numbers are read from the document itself.
A one-off score is a screenshot of a moving thing. What matters is whether it is getting worse as content is added.
Not a technical score. A control that moves under a thumb costs you the tap, and taps are leads.
New sections have to fit inside a budget rather than being added until someone notices the site got slow.
Search volume: Google Keyword Planner, United States, pulled 31 Aug 2026. Every other number is measured on our own site.
The measurement approach is running and it is what we use on this site: every page checked at 390px with the layout viewport set through CDP, reading scrollWidth off the document. Automatic remediation, as opposed to detection, is the early-access half.
Because that is where the leak is. On our own site the conversion gap between mobile and desktop was the single largest finding in the funnel.
Reading scrollWidth and element geometry from the live DOM at a set viewport, rather than looking at a rendered image. Headless browsers enforce a minimum window width, so a 390px screenshot is often a crop of a wider layout. We diagnosed a bug from exactly that mistake and had to revert the fix.
It finds and prioritises. Applying the fix is supervised, because a performance change that breaks a layout costs more than the milliseconds it saved.
Also in Website Optimisation: Page Drip Automation · Page Doctor