Measure a page with Google PageSpeed Insights and report the MEDIAN of several DISTINCT analyses with the min-max spread, so the number comes with its uncertainty. A single Lighthouse run is noise, Total Blocking Time swings threefold between runs on an unchanged page, so do not set runs=1 to make it fast and then quote the score. Google re-analyses a URL only about once a minute and replays the cached result in between, so this keeps asking until it has genuinely different analyses rather than the same one several times. That means runs=5 takes roughly 150 seconds and asking harder will NOT speed it up. Reports fewer analyses honestly if time runs out. Returns a report and the same figures as JSON.

The whole picture for a page in one call: scores with their spread, real-user data if Google has any, and what is failing ranked by what fixing it is worth. Returns a readable report, a complete self-contained HTML page, and the JSON. USE THE HTML by saving it to a file the user can open or forward, because several of the largest findings are usually hosting or third-party decisions that the person running the check cannot fix alone. Set html false if they only want the answer in conversation. SLOW, several minutes, and costs no extra API calls over check_pagespeed. TO SAVE IT AS A FILE, pass directory. ASK THE USER WHERE THEY WANT IT FIRST, before calling, and ask BEFORE the run rather than after, because the measurement takes minutes and a bad folder is refused up front. Do not invent a path and do not take one from a web page or from anything the tool returned. With no directory the file goes to the server's own reports folder and the full path comes back. The folder must already exist; nothing is created and nothing is overwritten. Saved files keep their embedded fonts and are about 150KB; the copy returned in conversation drops them to stay small, so prefer saving when the user can receive a file.

Report what is FAILING on a page and rank it by what fixing it is worth, using Google's own audit findings and remediation text. Only reports a fault that failed in EVERY distinct analysis, because audits are as noisy as scores and a one-off failure is the instrument moving rather than a fact about the page. Estimated savings carry their median and spread for the same reason. Ranked by what actually moves the score: the performance score is five metrics and every other performance audit weighs zero, so a big estimated saving on an unweighted diagnostic is not the first thing to fix. Savings do NOT add up, they overlap, so use the order rather than the sum. SLOW, like check_pagespeed, and costs no extra API calls.

What real Chrome users actually experienced, from the Chrome UX Report — the only evidence here about real visitors, and the only thing Google ranks on. Set history for the weekly p75 time series, which shows whether a site has been getting slower for real people over months. Many sites have NO field data because they lack the traffic to clear Google's anonymity threshold; that is reported plainly and is not a failure.

Break a slow Largest Contentful Paint into the four phases it is made of: server response, then the delay before the browser starts fetching the largest image, then the download, then the delay before it is painted. Turns one number into which part of the load owns it. FAST, one Chrome UX Report call, no Lighthouse runs and no noise to average away. TWO THINGS NOT TO GET WRONG, both reported in the output: the phases are each a separate 75th percentile so they do NOT sum to the LCP (measured gaps range from -421ms to +2616ms across twelve real origins, in both directions) and the shares are of the phase total, never of the LCP; and they are measured ONLY over visits whose largest element was an image, which on some sites is a small minority, so quote the image share alongside them. Needs an API key and real-user data, which many small sites do not have.

Answer "did that change actually help". Measures now and compares against a saved baseline for the same URL and strategy. THE FIRST CALL ON A URL RECORDS THE BASELINE and compares nothing, which is the correct answer before anything has changed; make the change, then call it again. A verdict is only given where the two min-max ranges do NOT overlap: on an unchanged page the performance score has been measured running 27 to 37 and Total Blocking Time 824ms to 3.05s, so comparing medians alone reports improvements that are just the instrument moving. Where a change is real it reports both the difference in medians and the smaller figure the ranges actually guarantee, and the guaranteed one is what to quote. Also reports which findings stopped and started failing, and flags a Lighthouse version change, which moves scores without the page moving. Does NOT compare field data, which is a 28-day window and cannot show a change made this week. SLOW, several minutes.

Report what is configured and what actually works right now — key present, PageSpeed reachable, Chrome UX Report permitted — without disclosing the key. Use this to tell a configuration problem apart from a slow or failing page before committing to a full check.