Why do I score low on PageSpeed, and what you can really do about it

PageSpeed looks like one number, but it is a summary of several parts. The most important are the load time of the first content (first contentful paint), the load time of the largest element, interactivity and layout shift. Not every part matters equally to your visitors.

For SEO it comes down to three questions: how quickly can somebody read something, do your buttons respond straight away, and does the page stay still while it loads?

There are a few stubborn misunderstandings as well:

• You do not need a hundred. A very low score does point at real problems, but a hundred is not a goal in itself.
• The score varies per test. Two measurements in a row rarely give exactly the same number.
• A brilliant report does not automatically mean more customers. It is a signal, not a guarantee.

Behind that single score sit three measurements Google itself calls the Core Web Vitals, and only those three count as an experience signal. They each have a hard threshold, and those thresholds are public. Those are the numbers you are aiming at.

• LCP, largest contentful paint. How long it takes before the largest element is on screen, usually your hero image or your big heading. Good is 2.5 seconds or faster. Above 4 seconds counts as poor.
• INP, interaction to next paint. How quickly the page visibly responds after the visitor clicks or taps. Good is 200 milliseconds or less. Above 500 milliseconds counts as poor. This measurement replaced the older FID in 2024, and it is stricter: FID only measured the delay before the browser started on your click, INP measures until you actually see something happen.
• CLS, cumulative layout shift. How much the page jumps around while it loads, in front of your visitor. Good is 0.1 or lower. Above 0.25 counts as poor. This is the one you feel yourself when you are about to press a button and a banner slides in above it.

Source for the thresholds and for the fact that they are measured at the 75th percentile: web.dev, Defining the Core Web Vitals metrics thresholds and web.dev, Web Vitals, both checked on 25 August 2026.

That 75th percentile matters more than most people realise, and it explains why your site feels fast to you and still does not score well. What is measured is not how it goes on average, but how it goes for the quarter of your visitors who have it worst. If three quarters of your visitors are under 2.5 seconds, you are in the good band. If three quarters sit just above it, you are outside it, even though your average is fine. So you are not optimising for the average visitor but for the visitor with the oldest phone and the worst connection.

This is the question that gets asked most and answered well least often: my PageSpeed says 42 and Search Console says it is fine. Which one is lying? Neither. They measure two different things, and until you know that difference you are chasing the wrong numbers.

Lab data. The score at the top of PageSpeed Insights comes from a simulated measurement. A virtual phone is imitated with a throttled processor and a throttled connection, and your page is loaded on it once. A laboratory, in other words: identical everywhere, repeatable, and not reality. It is excellent for seeing what is wrong, because the report points straight at the file causing the problem.

Field data. Below it, if you have enough visitors, sits a block with data from real visitors. That comes from the Chrome User Experience Report, a rolling twenty-eight day window that is updated daily. Source: Chrome for Developers, Overview of CrUX, checked on 25 August 2026. The same source feeds the Core Web Vitals report in Search Console, which also covers the last twenty-eight days. Source: Search Console Help, Core Web Vitals report, checked on 25 August 2026.

Three rules follow from that difference, and they save you a lot of time.

• Fix on lab data, judge on field data. The lab report tells you what to tackle. Whether it worked only shows up in the field data, and that is slow by definition: a change you make today is only fully through that twenty-eight day window four weeks later. Anyone concluding after two days that it did not help is measuring too early.
• Never measure the lab once. Run the same page three to five times and look at the middle result. The simulation is sensitive to chance: an external server answering slowly just then, an advert that does load this time. A difference of five to ten points between two measurements is normal and means nothing.
• Always compare the same page. Your home page, your service page and your blog article each have their own score, because they load different things. A low score on your home page says nothing about the article that brings in most of your traffic. So measure your three most important pages separately and write them down, so you know later where you came from.

If you have too few visitors for field data, the lab report stays your only source. That is not a disaster, but be extra careful with conclusions: what you are measuring then is a simulated visitor who does not exist. Useful for finding faults, useless as proof.

Many websites with low scores have fundamental problems you have to solve first, before you even look at images. An old PHP version, clutter in the database and too many plugins push the score down.

Work through these basic checks:

• Your server runs on a recent PHP version
• WordPress, your theme and your plugins are up to date
• Unused themes have been deleted
• A recent backup is ready

A good hosting choice with WordPress specific support and a cleaned up database helps more than you would think. Not sure whether your current site is still worth that investment? Then read what it costs to have a website made.

The biggest drops in PageSpeed scores usually come not from your theme but from extra scripts. Cookie banners, tracking, chat widgets and translation plugins are heavier than you expect.

Cookie banners. Every banner adds JavaScript and CSS. Some load external scripts before the rest of the page is finished. So choose a light banner, switch the animations off and load it after the main content. And check first whether you need one at all: under regulation 6 of PECR consent is required as soon as you store or read something on the visitor's device, so a site that stores nothing is carrying weight for a permission it never needs.

Translation plugins. Handy, but heavy. They make copies of pages, add database queries and load extra JavaScript. Stick to the languages you genuinely need and use one reliable solution.

There is often ground to be won as well by:

• Removing scripts from old chat widgets
• Loading tracking through one central tag manager
• Limiting the number of font files
• Checking whether social media widgets are really needed

Our own biggest gain came not from ten plugins at once, but from a considered combination: one cache plugin, image optimisation and a few small PHP functions through Code Snippets.

• Choose one modern cache plugin with page cache and script optimisation
• Install image optimisation that shrinks your photographs and converts them to webp. You do not need to install lazy loading: WordPress has done that itself since version 5.5, and deliberately skips the top image because lazy loading slows things down there
• Use Code Snippets for small improvements

Two examples of such small improvements: switch off the WordPress emoji script and remove the oEmbed scripts from the head. Both load on every page while practically nobody uses them. A few lines of remove_action in Code Snippets switches them off.

PageSpeed is extra strict about the first screen. Exactly where the heaviest parts usually sit: large images, video and effects. Our solution: fewer effects and better scaled images, while the style stayed the same.

Use this checklist for your hero block:

• Only one clear message
• A light image instead of a heavy video
• Fast font loading with no jumps
• Buttons that are clickable straight away
• Mobile just as calm as desktop

You can keep polishing forever. These five deliver most of the gain on almost any WordPress site, and they are listed in order of return divided by effort. Do them one at a time, and measure in between.

• Get the image in the first screen right. This is almost always your LCP. Three things at once: scale it back to the size it is actually shown at, save it as webp, and make sure it is not lazy loaded. That last one is counter-intuitive and goes wrong most often: lazy loading is useful for everything below the fold and harmful for the image above it, because that image is only requested after the browser has worked through the rest. WordPress skips the top image itself for that reason, but a plugin or a page builder sometimes overrides that rule. Check it.
• Push external scripts back. Everything that comes from another domain, from tracking to chat to review widgets, hardly ever needs to load before your visitor can read anything. Let them start once the page is done, or only after the visitor's first movement. This hits both your LCP and your INP, because every script that runs keeps the browser busy while somebody is pressing a button.
• Reserve space for everything that slides in later. This is the whole solution to CLS and it costs almost nothing. Give every image a width and a height, give your cookie banner and your advert slots a fixed height, and load your fonts so the text does not jump from one typeface to another. You change nothing visible and the page stands still.
• Turn on a page cache. Without a cache your server rebuilds every page for every visitor out of the database. With a cache the answer is waiting. This lowers the time to the first response, and that time sits underneath all your other measurements: it delays everything that comes after it.
• Clear out what you do not use. The plugin from that campaign last year, the second forms plugin, the slider plugin still running one slider on a page nobody visits, three font families of which you use one. This is dull work and it consistently returns more than the exciting fixes.

What is deliberately not on this list: minifying and combining files, and deferring CSS. They appear in every report, but on an average site they return little and they are the most common cause of a site that is broken after optimisation. Do them last, one at a time, and then check on your phone whether everything still looks right.

There is a limit to what clearing out achieves. That limit is the time your server needs to send the first piece of the answer, before the browser can draw anything at all. If that alone takes more than half a second, you can shrink every image you like: you start every measurement with a gap you will never close.

You recognise this by a pattern. You have done everything the report asked, you have removed plugins, and the score gets no further than the middle. At the top of the report sits an item about server response time you have kept skipping because there was no file name attached to it. That is the one.

What you can do about it, from small to large:

• First check whether it really is the server and not your own code. A slow response time often comes from a plugin that calls an external service on every page view: a price feed, a stock level, a review score. Switch it off temporarily and measure again.
• Ask your host what your neighbours are doing. On shared hosting your site sits on the same machine as dozens of others. If one of them spikes, you feel it. A host that gives you no answer to that has given you your answer.
• Check your PHP version and your database maintenance. An outdated PHP version is slower and no longer gets security updates either. A database full of old revisions, expired transients and logs from a plugin you no longer use makes every query longer.
• Put a network in front of your site. If your server sits in the United Kingdom and your audience is in the United Kingdom, there is little to win here. If you serve visitors on another continent, the distance itself is part of your delay and a network that keeps your page closer to the visitor helps.
• Move. The most expensive and sometimes the only one. Do not do it on instinct but on a measurement: run the same page on a test environment at another provider and compare the response time. If that makes no difference, it was not your host and you have saved yourself a migration.

Here the question also becomes legitimate whether you are pushing on the right side at all. A site that works against you on every single layer is sometimes cheaper to rebuild than to keep repairing. What that trade-off looks like is in making your WordPress site faster, and the wider technical side in technical SEO.

Our own site did not score well by itself either. This is what was wrong:

• Too many scripts in separate blocks
• The cookie banner loaded late and shifted the layout
• Images were larger than they needed to be
• Several tracking scripts were running alongside each other

This is what we changed:

• Simplified the layout
• Chose one performance plugin
• Replaced the cookie banner with a light variant
• Optimised images with lazy loading
• Loaded all tracking through one central layer

The work ends with two checks: a report that no longer flashes red and a website that feels calm. Check whether your mobile scores have improved, whether the site feels faster, and whether your cookie banner and translation plugin are not noticeably slowing things down.

If your site scores well by now but visitors or positions lag behind, the problem is probably somewhere else. In that case read why your WordPress site is not in Google while everything looks fine. Would you rather we looked at it with you? Then see our service improving SEO. And if the lag you see is a drop in impressions rather than in positions, do not go looking in your speed report at all: that is usually a change in how Search Console counts, which we take apart in why are you getting fewer impressions in Google Search Console.

Do I really have to aim for a score of a hundred?

No. A hundred looks good in a screenshot, but it is not a goal in itself. Aim for a steady green or high amber score.

Why is my mobile score so much lower?

The mobile test is stricter. It calculates with slower devices and slower connections.

Can one plugin solve everything?

A good performance plugin helps, but it cannot hide wrong choices. It is a tool, not a miracle cure.

Is a cookie banner always bad for your score?

A banner always adds something, but the impact depends on how light it is and when it loads. Choose a light variant, and check whether you need one at all.

What if my score is good but the site feels slow?

Test with real users. Sometimes one specific page or feature is slow while the report shows average values.

A low PageSpeed score rarely comes from one thing. It is the sum of hosting, basic maintenance, scripts, banners, plugins, images and design choices. By clearing up step by step and testing again after every change, you work towards a website that feels good to visitors and sends better signals to search engines.

More practical explanation like this is in our knowledge base.

The awkward part of a speed report is that it lists thirty things and does not tell you which two of them are yours. Most sites we open have one dominant cause and a long tail of items that would change nothing. Working through the list from the top is therefore the slowest possible route.

If you would rather skip that, send us the address of the page you care about most and the score you are seeing. We will tell you which measurement is actually failing, whether it is your images, your scripts or the server underneath, and what we would change first. Including when the answer is that your score is fine and the problem is somewhere else entirely. You can reach us through the contact page, where you pick a slot in the calendar yourself. A first conversation carries no price and no obligation. If you would rather have it taken off your hands afterwards, that runs through our service improving SEO.