pagespeed-insights-read

Reading PageSpeed results

The MCP server refuses to state a number without its uncertainty. It cannot stop an assistant discarding that uncertainty on the way to an answer, which is the failure this skill exists to prevent.

Every rule below came from measuring, and the measurements are quoted so they can be checked rather than believed.

The one that matters most: a change smaller than the spread is not a change

Every score and metric comes back as a median with the range across distinct analyses. That range is the instrument moving on a page that did not change.

Measured on one unchanged page: performance ran 27 to 37 across three analyses, Total Blocking Time 824ms to 3.05s, and estimated savings for one fix ranged 1450 to 2750ms.

So:

• Do not report "performance improved from 33 to 36". That is inside the noise.
• Do not compare today's median against yesterday's median without both spreads. Two medians that differ by less than the ranges overlap tell you nothing.
• If asked whether something got better, say what the spreads were and whether they overlap. If they overlap, the honest answer is "no measurable change", not a hedged yes.

Use compare_to_baseline rather than doing this arithmetic yourself. It holds the baseline, applies the overlap rule, and will refuse a verdict where you might not.

Never add savings together

Findings carry Google's estimate of what each fix returns, per metric. These do not compose. Two fixes claiming 6750ms and 1200ms off LCP do not return 7950ms. They overlap, and Lighthouse models no interaction between them.

• Never sum them into a total.
• Never promise a resulting score. There is no way to get from a saving to a score, because the curve is not linear.
• The ordering is the useful part. Say "fix this first", not "this will save you nine seconds".

The LCP phases do not add up to the LCP

explain_lcp returns four phases. They are each a separate 75th percentile, so they do not sum to the LCP and are not meant to. Measured across twelve real origins, the sum missed every time and in both directions, from 40ms under to 2616ms over.