Free tools Windows power users keep installed
One-click scans. No signup required.
A 20/100 mobile score in PageSpeed Insights means Lighthouse rated one page poorly under that report’s simulated mobile test conditions. It is a reason to investigate, not proof that WordPress, a particular plugin, or every visitor’s experience is the problem. To understand what is slow, inspect the individual metrics and audits, repeat a comparable test, then check real-user data where it is available.
What a 20/100 PageSpeed score does—and does not—tell you
PageSpeed Insights (PSI) presents separate mobile and desktop reports. Its Performance score summarizes a Lighthouse lab analysis: a synthetic test run under controlled conditions. That makes it useful for reproducing and diagnosing potential problems, but it cannot represent every visitor’s device, connection, location, or interactions. Google’s PSI explanation distinguishes this lab analysis from real-user data.
As an Amazon Associate I earn from qualifying purchases.
The score alone does not identify a cause. A low result is not evidence that WordPress itself, your host, theme, or any one plugin is responsible. Open the report’s metric details and diagnostic audits to see what that particular run found. Treat possible contributors—such as images, scripts, server response, caching, theme code, or plugins—as things to investigate, not conclusions.
Lab results and field data answer different questions
PSI may also show Chrome User Experience Report (CrUX) field data when enough eligible real-user data exists. Unlike a single simulated run, field data represents a distribution of experiences from actual Chrome users over time. PSI may provide page-level data and, where available, origin-level context. A page can lack enough data to show its own field results. Google’s PSI documentation describes these distinctions.
A lab score helps investigate a repeatable test; field data helps assess what real users experience. Neither should be substituted for the other, and one does not automatically explain the other.
Why your mobile score may change between tests
A Lighthouse run is a sample, not a permanent rating of your entire site. Results can differ when test conditions or the page response differ. Google’s guidance on lab and field data and measurement variability discusses why measurements may not match.
- Test conditions: network, device, or location can affect a synthetic run.
- Page state: cache state, redirects, or the content rendered during the test may vary.
- Different targets: a homepage and a landing page are not interchangeable, even if they belong to the same WordPress site.
- Different evidence: a lab run and a field-data distribution measure different things, over different samples and time periods.
For a meaningful comparison, hold the page and test context as constant as possible. Look at metric-level results and audit details, not only the rounded score.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How to measure your WordPress site’s mobile speed consistently
- Run the exact public page in PSI. Enter the page URL, select the mobile report, and save the URL, date and time, report link or screenshot, and metric-level results. Use the same page for future comparisons.
- Repeat under comparable conditions. Treat each run as a sample. Record the results and compare the metric details and audits across runs rather than treating one score as definitive.
- Use lab metrics to investigate loading and responsiveness. Lighthouse can report Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Total Blocking Time (TBT). TBT can help you investigate a blocked main thread, but it is not Interaction to Next Paint (INP). Lighthouse cannot measure INP without real user input. Google explains the limits and differences of lab and field metrics.
- Check field experience separately. Review field data in PSI, Search Console, or a real-user monitoring (RUM) setup if you have one. Search Console offers historical Core Web Vitals reporting; field data and lab data have different roles. See Google Search Console’s Core Web Vitals report guidance.
- After a change, repeat the same lab process and watch field trends. Report what changed in the controlled test separately from what happened to real-user metrics. One before-and-after score does not establish that a particular change caused the difference.
How to read the metrics behind the score
Core Web Vitals cover loading, responsiveness, and visual stability. Google’s current Web Vitals guidance recommends assessing the 75th percentile separately for mobile and desktop. These are recommended thresholds, not a substitute for inspecting your page’s report.
| Metric | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to user interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
Thresholds and the 75th-percentile assessment are from Google web.dev’s Web Vitals guidance, accessed October 7, 2026. They are evaluated on field data; a synthetic Lighthouse score is not itself a Core Web Vitals pass-or-fail result. Google notes that “many” Core Web Vitals can also be measured in the lab, while describing them first and foremost as field metrics. Read the lab-and-field explanation.
Keep comparisons aligned: mobile with mobile, the same page with the same page, and lab with lab or field with field. For field metrics, distinguish a page’s data from origin-level context and remember that a distribution collected over time is not the same as one test run.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to check if the report stays poor
Use the report’s specific findings to choose the next investigation. Depending on what the metrics and audits show, you might examine large images, scripts that delay rendering or block the main thread, server response, caching, or delivery setup. In WordPress, the theme and plugins are also possible areas to inspect—but a 20/100 score by itself does not establish that any of them caused the result.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Change one relevant factor at a time when practical, then repeat the same page test and compare the metric tied to that change. If the lab result improves but field trends do not, or vice versa, keep both outcomes visible: they describe different conditions and samples. A site-specific root-cause claim needs the actual URL and report, with controlled changes or site-specific measurements to support it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
