How to Get a 90+ PageSpeed Score on WordPress (and When It Doesn't Matter)

A 90+ mobile PageSpeed score on WordPress is achievable, but it usually takes more than a caching plugin: a lightweight theme, a page cache with a fast server response, a properly sized hero image that loads first, very little render-blocking CSS and JavaScript, and a short list of third-party scripts. Past 90, every extra point costs more than the one before. And if your Core Web Vitals field data already passes, the lab score matters much less than it looks.

This article used to be called 'How to Get a 99 Google PageSpeed Score on WordPress'. A 99 is possible on a simple site, but chasing one is usually the wrong goal, and this rewrite explains why. For what the PageSpeed Insights report shows and why its two halves disagree, see PageSpeed Insights explained. This page is about the WordPress side: what drags the score down, and what getting it up actually involves.

What the WordPress PageSpeed score is made of

The 0 to 100 score comes from a Lighthouse lab test: one simulated page load on a mid-range phone. Lighthouse's performance scoring documentation gives the weights at the time of writing (October 2026). Here they are, mapped to the WordPress causes I see most often:

Lighthouse colours 90 to 100 green, 50 to 89 orange and below 50 red. That green band is why '90+' has become the number people quote.

Why WordPress sites score badly on mobile

The mobile test simulates a slower device and connection, so the cost of JavaScript is multiplied. That hits WordPress harder than most platforms, for structural reasons:

• Every active plugin can add CSS and JavaScript to every page, whether or not that page uses it: a contact form plugin loading on the blog, a slider library loading on pages with no slider.
• Page builders and multipurpose themes ship code for features you are not using, because they have to support every possible layout.
• Marketing scripts accumulate. Analytics, a tag manager, a pixel or two, a chat widget, a review badge. Each is small; together they are often the largest single cost on the page.
• Hero sliders combine the two worst things for the score: large images and a JavaScript library that has to run before the first slide settles.

What a 90+ actually takes

On most business sites, getting the mobile score into the 90s needs all of these, not one of them:

1. A lean theme that loads only what each page needs. Heavy multipurpose themes and builder layouts can reach 90, but with much more effort; custom WordPress theme vs Elementor covers that trade-off.
2. Page caching and a fast server response. Cached HTML served quickly is the foundation; if the server takes a second to respond, every other metric starts a second late. WordPress caching explained and how to reduce server response time cover both.
3. A hero image that loads first. Sized for the space it fills, in WebP or AVIF, never lazy-loaded, ideally given a high fetch priority. Recent WordPress versions try to do the last two automatically for the first large image, but builders and sliders can defeat it. How to improve Largest Contentful Paint goes through the checks.
4. Less render-blocking CSS. Remove unused CSS where your optimisation plugin can do it reliably, and stop plugins loading their stylesheets on pages that do not use them.
5. Deferred JavaScript, and less of it. Defer what the first view does not need, and remove what nothing needs. Replacing a slider with one static image often does more than any setting.
6. Self-hosted fonts, and few of them. One or two families, a couple of weights, with a font-display setting that shows text immediately.
7. A short list of third-party scripts. Audit every tag, and keep only the ones whose data someone actually uses.
8. Per-page asset control. Tools such as Perfmatters or Asset CleanUp can stop a plugin's files loading where they are not needed. Use them carefully and test each page type afterwards.

Shortcuts that raise the score but not the speed

Some popular settings improve the lab number more than the real experience. The best known is delaying JavaScript until the visitor interacts. WP Rocket's Delay JavaScript execution setting, for example, holds scripts back until the visitor moves the mouse, scrolls, touches the screen or presses a key, and other optimisation plugins offer the same idea.

It is a legitimate technique and on many sites a good one. But understand what it does to the test. A Lighthouse run does not move a mouse or tap the screen, so delayed scripts may never run during the test, and Total Blocking Time falls sharply. A real visitor still downloads and runs those scripts, at the moment of their first interaction, which is exactly when you want the page to respond.

Use delay settings deliberately: exclude anything that affects the first view or the first interaction, such as the mobile menu, then check real-user INP in the field data rather than trusting the new score.

Why the last few points cost the most

The scoring curve is not linear. Lighthouse's own documentation notes that taking a score from 99 to 100 needs about the same amount of metric improvement as taking it from 90 to 94.

In practice the first fixes are cheap and large: images, caching, removing a slider. Moving from the high 80s into the high 90s usually means removing things the business wants, such as the chat widget, the booking embed or the analytics, or rebuilding the theme. Sometimes that is worth it. Usually it is not.

When the score does not matter

• Your field data passes. If the Core Web Vitals assessment at the top of PageSpeed Insights is green on mobile, real visitors are having a good experience. A lab score of 75 on that page is a diagnostic note, not a problem.
• You are comparing yourself with a competitor's number. Their score tells you nothing about their rankings or their sales.
• It costs you conversions. If the price of 95 is removing the chat that brings in enquiries, keep the chat.

It matters more in one situation: a low-traffic site with no field data. Then the lab test is all you have, and a poor mobile score is a reasonable warning that visitors on slower phones are struggling. Treat it as a guide, test each main page template, and fix the obvious causes. Google's page experience signals use Core Web Vitals field data, not the lab score, as Core Web Vitals explained sets out.

A worked example

Say a service business runs a page-builder site with a homepage slider, three font families, a chat widget and twelve plugins. The mobile score is 41 and the field data fails on LCP. It is hypothetical, but a common starting point.

1. Replace the slider with one optimised static image, excluded from lazy-loading. This is where LCP usually improves most.
2. Turn on page caching and confirm the cache is actually hit for logged-out visitors.
3. Cut to one font family in two weights, self-hosted.
4. Stop the form plugin and the slider library loading on every page.
5. Load the chat widget after the main content rather than in the head.

Those five changes typically lift a score like that a long way, but the number to watch is field LCP falling under 2.5 seconds over the following four weeks. Whether to push on to 90+ after that is a business decision, not a technical one. Why is my WordPress website slow? covers the diagnosis that comes before step one, and the website speed optimisation checklist is the working list.

Next step

Open PageSpeed Insights on your three most important pages and read the field data first. If it passes, stop worrying about the score. If it fails, note which metric and fix that. If you would like it done for you, speed work is part of the WordPress development service, field-data checks are part of website maintenance, and the WordPress speed optimisation showcase shows the order I work in.