Key facts at a glance
Reading a WordPress PSI report in 2026
Last updated
- The score is not the ranking signal
- The 0 to 100 performance score is lab data from one simulated test. Google ranks on the field data, the Core Web Vitals assessment of your real visitors, shown separately on the report.
- Why mobile looks worse
- The mobile score is run on an emulated mid-range phone on slow 4G, about 1.6 Mbps, with a four-times CPU slowdown. A large gap below the desktop score is normal, not a separate bug.
- What the score weighs most
- Total Blocking Time is 30 percent, LCP and CLS are 25 percent each. On WordPress, heavy main-thread JavaScript driving Total Blocking Time is the most common reason a score is low.
- The score bands
- 90 to 100 is green and good, 50 to 89 is orange and needs improvement, 0 to 49 is red and poor. Aim for green on mobile, not a vanity 100.
- The score varies between runs
- A few points of movement is expected, from ads, routing, the test device, and browser extensions. Run it a few times in a clean window and read the range, not one number.
- Insights, not Opportunities
- Google reorganized the findings list. What older guides call Opportunities and Diagnostics now shows as Insights and Diagnostics, the current default in PageSpeed Insights.
Source: the Lighthouse performance scoring documentation, the About PageSpeed Insights documentation, the Chrome blog on the move to Insights, the web.dev Core Web Vitals thresholds, and Google Search Central on Core Web Vitals. Get a quote in 60 seconds →
Why the report confuses WordPress owners
PageSpeed Insights is the test most WordPress owners reach for, and it is the one that causes the most unnecessary alarm. Someone runs it, sees a red mobile number in the forties, and concludes their site is broken and their ranking is tanking. Usually neither is true. The report is genuinely useful, but it presents several different things side by side, a lab score, real-user field data, a list of findings, and it is easy to read the scariest number as the verdict when it is not the one that matters. Most of the panic comes from not knowing which part of the report does what.
There are three misunderstandings behind almost every PageSpeed worry we hear. The first is treating the 0 to 100 score as the thing Google ranks on, when it is a lab diagnostic and the field data is the ranking signal. The second is panicking that the mobile score is far below desktop, when that gap is built into how the test runs. The third is chasing every item in the report equally, when the score is weighted and a few causes dominate. Clear those three up and the report turns from a source of stress into a precise to-do list.
This page is the map. It explains how to read a WordPress PageSpeed Insights report correctly, what each number means and how much it matters, and then it routes each finding to the specific fix it needs, the mobile speed work, the image work, the JavaScript and caching work, so you spend your effort where it actually moves the result. It is the orientation layer above our specific speed fixes, starting with the single most important distinction on the whole report.
Lab score vs field data
This is the distinction that resolves most PageSpeed anxiety, so it is worth getting right. The report shows two fundamentally different kinds of data, and they answer different questions.
The performance score, lab data
The 0 to 100 number, from a single simulated Lighthouse test on a virtual phone under fixed conditions. Repeatable and great for diagnosis. It is not used by Google for ranking, and a perfect 100 does not guarantee passing in the field.
The Core Web Vitals assessment, field data
The pass or fail near the top, from your real Chrome visitors over the previous 28 days, at the 75th percentile. This is what Google uses for ranking. It only shows when your page or site has enough traffic data.
The practical consequence is a simple rule. When you open a bad report, look below the score at the field assessment first. If the field data passes, you do not have a speed-related ranking problem, and the low lab score is a diagnostic you can improve at your own pace. If the field data fails, that is the real issue, and it is worth fixing promptly because it affects both visitors and ranking. Use the lab data to find and fix the causes, but judge success by the field data moving, since the field is the part that counts and it updates gradually as real visits accumulate.
The score is a lab diagnostic. The Core Web Vitals assessment is the field data Google ranks on. Fix using the score, but measure success by the field.
What the score actually weighs
The performance score is not one measurement, it is a weighted blend of five lab metrics, and the weights tell you exactly where to look on a WordPress site. Chasing every item in the report equally is wasted effort. The score rewards fixing the heavily weighted metrics.
| Lab metric | Weight | What it is on WordPress |
|---|---|---|
| Total Blocking Time | 30% | How long the main thread is blocked, the lab stand-in for responsiveness. Usually JavaScript from plugins and the page builder. The heaviest single input. |
| Largest Contentful Paint | 25% | How long the biggest visible element, usually the hero image, takes to render. |
| Cumulative Layout Shift | 25% | How much the layout jumps while loading. Unsized images, ads, and late fonts. |
| First Contentful Paint | 10% | When the first content appears. Affected by server response and render-blocking resources. |
| Speed Index | 10% | How quickly the page visibly fills in during load. |
The takeaway for WordPress is that Total Blocking Time, at 30 percent, is the largest single input, and it is driven by main-thread JavaScript, which on a plugin-heavy, page-builder site is usually plentiful. So the fastest way to lift a low WordPress score is almost always to reduce and defer JavaScript, then to address the hero image behind Largest Contentful Paint and the layout shift behind Cumulative Layout Shift. Total Blocking Time is also the lab stand-in for responsiveness, since a lab test cannot measure real interactions, so improving it tends to help the real-user INP that Google measures in the field.
Why mobile looks so much worse
The most common single complaint we hear is that the mobile score is dramatically lower than desktop, and people assume something is specifically broken on mobile. Usually nothing is. The gap is built into the test. When PageSpeed Insights produces the mobile score, it does not use a fast device. It emulates a mid-range phone, a Moto G Power class device, on a throttled slow-4G connection of around 1.6 megabits per second, and it applies a four-times CPU slowdown on top to approximate a phone that is warm and busy rather than fresh. The desktop score, by contrast, runs on fast hardware and a fast connection.
So the two numbers are not comparable. The mobile score is your site under deliberately hard conditions, which is the point, because it reflects the median real visitor rather than an engineer on fast office wifi. A large gap between a green desktop score and an orange or red mobile score is completely normal and does not mean there is a separate mobile fault. It matters more than the desktop score, though, because Google indexes and ranks using the mobile version of your site, so the mobile result is the one that feeds both the field assessment and your ranking.
That is also why the fixes for a low mobile score are mobile-specific, the hero image being discovered late, render-blocking JavaScript, and heavy scripts on the throttled CPU, rather than generic. We cover those in depth on the WordPress slow on mobile page, which is the right next read if your problem is specifically the mobile number.
Reading the report top to bottom
Once you know the order, the report reads cleanly. Here is what each section is, from the top.
1. Core Web Vitals assessment, the field data
At the top when available. A pass or fail with your real-user LCP, INP, and CLS over 28 days. This is the ranking-relevant part. If it is missing, your page or site does not yet have enough Chrome traffic data.
2. The performance score, the lab data
The 0 to 100 number with its color band. A diagnostic, not the ranking signal. Toggle between the Mobile and Desktop tabs, and remember the mobile number is run on a throttled phone.
3. The lab metrics
First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index, each with its own value. These feed the score by the weights above, so Total Blocking Time and LCP carry the most.
4. Insights and Diagnostics, the findings
The list of specific, fixable problems. Google reorganized this: what older guides call Opportunities and Diagnostics now shows as Insights, merged high-level areas, and Diagnostics, the granular audits. Each names a cause the next section routes to a fix.
Route each finding to its fix
Match the finding on your report to the fix it needs. Each row links to the specific diagnostic and repair for that cause.
| What the report shows | What it means and the fix |
|---|---|
| A low mobile score, or a failed Core Web Vitals assessment on mobile | The mobile-specific causes: the hero image discovered late, render-blocking JavaScript, and heavy scripts on a throttled phone. |
| Serve images in next-gen formats, Properly size images, Efficiently encode images | Images are in old formats, served too large, or lightly compressed. WordPress supports WebP and AVIF but will not convert them for you. |
| Reduce unused JavaScript, Reduce JavaScript execution time, high Total Blocking Time | Too much main-thread JavaScript from plugins and the page builder. High Total Blocking Time is the lab proxy for poor INP, the responsiveness metric. |
| A failed Core Web Vitals assessment across LCP, INP, or CLS in the field | A real-user problem that affects ranking. Identify which of the three metrics is over threshold and fix that one. |
| Initial server response time is high, or the whole site feels slow | A slow Time to First Byte from hosting or missing caching, the floor under every other metric. |
| The wp-admin dashboard is slow, but the public score is fine | A backend problem PageSpeed does not measure, since it only tests public pages. Autoload bloat, no object cache, the Heartbeat API. |
Set the right target
With the report understood, the goal becomes realistic. The score bands are 90 to 100 green and good, 50 to 89 orange and needs improvement, and 0 to 49 red and poor. A sensible target is to get comfortably into the green on mobile and, more importantly, to pass the Core Web Vitals assessment in the field. The last stretch toward a perfect 100 usually costs far more effort than it returns and can mean stripping out functionality your visitors use, all for a number Google does not rank on.
So the target we aim for, and recommend, is a solid green mobile score and a passing field assessment, not a vanity 100. A site that passes Core Web Vitals for real users and sits at a healthy lab score is in excellent shape whether that score reads 92 or 99. That framing keeps the work focused on what actually helps your visitors and your ranking, rather than on chasing points for their own sake.
How we fix a PSI report
Read it correctly
We separate the lab score from the field assessment, so you know whether you have a ranking-relevant Core Web Vitals problem or just a diagnostic to improve, and we focus the work accordingly.
Fix in order of impact
We use the weighted metrics and the Insights to target the biggest causes first, usually the main-thread JavaScript behind Total Blocking Time, then the LCP hero image, layout shift, images, and caching.
Verify on the field
We confirm the lab score improved immediately and that the field assessment moves into the good range over the following weeks, since the field is what counts. No rebuild, just the existing site optimized.
Flat $49 to $149 per fix. For an ongoing program across many pages or sites, see the monthly plans, or start with the speed optimization service.
WordPress PageSpeed Insights FAQ
My WordPress PageSpeed Insights score is low. Is my Google ranking being hurt?
Not necessarily, and this is the most important thing to understand about the report. The big number at the top, the 0 to 100 performance score, is lab data. It comes from a single simulated test that Lighthouse runs on a virtual mid-range phone on a throttled connection. Google does not use that score for ranking. What Google uses is the field data, the Core Web Vitals assessment shown separately on the report, which is the experience of your real Chrome visitors over the trailing 28 days. So a site can have a scary-looking score of 45 and still pass Core Web Vitals in the field, in which case there is no ranking problem from speed, only a diagnostic worth acting on. The reverse is also true: a green score does not guarantee you pass in the field. So the first move with a bad score is to look below it at the field assessment, because that is the part that affects ranking.
Why is my mobile PageSpeed score so much lower than desktop?
Because the mobile test is deliberately run on a slow device and connection, while the desktop test is not, so the two scores are not measuring the same thing. For the mobile score, PageSpeed Insights emulates a mid-range phone, a Moto G Power class device, on a throttled slow-4G connection of around 1.6 megabits per second, and it applies a four-times CPU slowdown on top to mimic a warm, busy phone. The desktop score runs on fast hardware with a fast connection. So the same WordPress site is being asked to perform under far harder conditions for the mobile number, and a large gap between the two is completely normal, not a sign of a separate mobile bug. It also matters because Google indexes and ranks using the mobile version of your site, so the mobile result is the one that counts. The fixes for a low mobile score are the mobile-specific ones we cover on the mobile speed page.
What does the performance score actually measure?
It is a weighted blend of five lab metrics, and knowing the weights tells you what is really dragging it down. In the current Lighthouse scoring, Total Blocking Time is weighted at 30 percent, Largest Contentful Paint at 25 percent, Cumulative Layout Shift at 25 percent, First Contentful Paint at 10 percent, and Speed Index at 10 percent. The single heaviest input is Total Blocking Time, which measures how long the main thread is blocked by JavaScript, so on a typical WordPress site loaded with plugins and a page builder, heavy JavaScript is very often the biggest reason the score is low. Largest Contentful Paint, usually the hero image, and Cumulative Layout Shift, the layout jumping, together account for another half. So when you see a low score, the weighting tells you to look first at JavaScript and the main thread, then the hero image and layout stability, rather than chasing every item in the report equally.
What is the difference between the lab data and the field data on the report?
They answer two different questions, and confusing them is the most common mistake. Lab data is a controlled, repeatable test: Lighthouse loads your page once on a simulated device under fixed conditions and produces the performance score and the list of issues. It is excellent for diagnosis, because it is reproducible and it points at specific problems. Field data is the Core Web Vitals assessment near the top of the report, and it is the real experience of your actual Chrome visitors collected over the previous 28 days, shown only when Google has enough traffic data for your page or site. Field data is what Google uses to judge Core Web Vitals for ranking. The practical rule is to use the lab data to find and fix problems, and to judge success by the field data improving, since the field is what counts and it updates gradually as real visits accumulate at the new speed.
My score changes every time I run the test. Why is it not stable?
Because a lab score is a single measurement of a complex system, and several things outside your site move it between runs. The Lighthouse documentation lists the usual causes: A/B tests or different ads being served on each load, internet traffic routing changes, testing on different devices such as a fast desktop versus a slower laptop, browser extensions that inject their own JavaScript and network requests, and even antivirus software. So a few points of variation from run to run is expected and not meaningful. The way to use the score sensibly is to run the test a few times and look at the range rather than fixating on one number, to test in a clean environment such as an incognito window without extensions, and again to treat the score as a diagnostic direction rather than a precise grade. The field data, by contrast, is an average of many real visits and so is far more stable.
How is the report laid out, and what are Insights and Diagnostics?
The report has a clear top-to-bottom order once you know it. At the top, when available, is the Core Web Vitals assessment, the field data, with a pass or fail and your real-user LCP, INP, and CLS. Below that is the lab section: the performance score, then the individual lab metrics, First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and Speed Index. Below those is the list of specific findings. Google recently reorganized this list: what older guides call Opportunities and Diagnostics is now shown as Insights and Diagnostics, with Insights giving merged, high-level performance areas and Diagnostics keeping the granular technical audits. The change rolled out to PageSpeed Insights through 2025 and is the current default. Each finding, render-blocking resources, unoptimized images, excessive JavaScript, names a specific fixable problem, and the rest of our speed pages handle each one.
Should I be aiming for a perfect 100 score?
No, and chasing 100 is usually a poor use of effort. The score bands are set so that 90 to 100 is green and good, 50 to 89 is orange and needs improvement, and 0 to 49 is red and poor. Getting comfortably into the green on mobile is a sensible target, but the last few points toward a perfect 100 often require disproportionate work, removing functionality your visitors actually use, and they deliver little real-world benefit because, again, the score is not the ranking signal. A site that passes Core Web Vitals in the field and sits at a solid green lab score is in excellent shape, whether that score is 92 or 99. The better goal than a perfect number is a fast, stable real-user experience that passes the field assessment, which is what serves both your visitors and your ranking. We aim for green and for passing the field data, not for a vanity 100.
Can you fix my WordPress PageSpeed Insights report for me?
Yes, and the first thing we do is read it correctly so the work targets what matters. We separate the lab score from the field assessment, so you know whether you have a ranking-relevant Core Web Vitals problem or just a diagnostic to improve, then we use the lab metrics and the Insights and Diagnostics to find the specific causes, and we fix them in order of impact, usually the main-thread JavaScript that drives Total Blocking Time, the hero image behind Largest Contentful Paint, the layout shift, the images, and the caching underneath. Because the score weighting and the report point at different culprits on different sites, the diagnosis is what makes this fast, and it is what we are good at. We optimize the existing site, no rebuild. Flat $49 to $149, done in two hours when scope fits, money back if we cannot improve your measured speed.
Sources and further reading
Every technical claim on this page traces back to the Lighthouse and PageSpeed Insights documentation, the Chrome developer blog, web.dev, or Google Search Central.
- Chrome for Developers: Lighthouse performance scoring (metric weights and score bands)
- Google: About PageSpeed Insights (lab and field data)
- Chrome for Developers: Lighthouse is moving to performance insight audits
- web.dev: Defining the Core Web Vitals metrics thresholds
- Google Search Central: Core Web Vitals and page experience