PageSpeed Insights MCP

Use to measure a page in the lab and find what to fix (scores with their spread, failing audits ranked by what fixing them is worth, real-user data beside them, and a page to send on); for real-user data alone use get_field_data, which is fast, and for "did that change help" use compare_to_baseline. include picks the parts, "scores", "issues", "field_data" and "html", default all four. ONE MEASUREMENT SERVES EVERY PART, so asking for more costs no extra API calls, while asking in separate calls measures again. SLOW, several minutes. It reports 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 runs=1 is fast but its score is not a reliable figure. 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. Anything that will not fit inside one tool call returns a JOB ID instead and keeps working: collect it with get_job_result, polling about every 15 seconds. Only runs=1 on a single URL with include ["scores"] answers immediately, and that is the noisy single run described above. ISSUES are what is FAILING on the page, from Google's own audit findings and remediation text. Only a fault that failed in EVERY distinct analysis is reported, 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…

Use first when anything looks wrong, to tell a configuration problem apart from a slow or failing page before committing to a full check. Reports what is configured and what actually works right now (key present, PageSpeed reachable, Chrome UX Report permitted) without disclosing the key.

Use to answer "did that change actually help"; for a one-off measurement with nothing to compare against use analyse_page. 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, and a call after the change compares against it. 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 the figure the measurement supports. 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: it returns a JOB ID and you collect the verdict with get_job_result.

Use when Largest Contentful Paint is the problem, to find which part of the load owns it; for the LCP figure alone use get_field_data, and for lab scores and what to fix use analyse_page. Breaks a slow LCP 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. 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 the output gives the image share alongside them. Needs an API key and real-user data, which many small sites do not have.

Use for what real Chrome users actually experienced, with no lab measurement, so it answers in seconds rather than minutes; for lab scores and what to fix use analyse_page, and for which phase owns a slow LCP use explain_lcp. 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.

Use to collect a measurement that analyse_page or compare_to_baseline handed back as a job id, calling it about every 15 seconds until it reports done. Anything longer than about a minute cannot be answered inside one tool call (clients enforce a hard wall-clock limit and progress notifications do not extend it), so those tools return a job id and keep working. When done it returns exactly what the tool would have returned. ALWAYS answers immediately. Omit job_id for the most recent job. Starting the same measurement again while one is running does not make it arrive any sooner, because the wait is Google re-analysing the URL about once a minute.