Why website speed matters to a business
A slow page costs you before anyone has read a word. Someone on a train between Leeds and Manchester, on a patchy mobile signal, taps your result and watches a blank screen. Many go back to the results. Those who stay meet a page that jumps or ignores their first tap, which quietly lowers trust.
So the first reason to care is commercial: fewer enquiries, fewer completed checkouts and more wasted advertising spend.
The second reason is search. Google states in its documentation on Core Web Vitals and Google Search that these metrics are used by its ranking systems and recommends achieving good scores. The same guidance is clear that relevance and helpful content carry more weight. A fast page with a thin answer will not outrank a slightly slower page with an excellent one. Treat speed as part of the experience you offer, with search as a side benefit, not as a ranking trick.
In our own 10-point website score, Speed & Core Web Vitals is one fixed criterion, alongside Technical foundation & indexing and Mobile experience.
Core Web Vitals explained: LCP, INP and CLS
Google summarises the experience of real visitors in three metrics, described in detail on web.dev:
- Largest Contentful Paint (LCP) measures when the largest visible element, usually a hero image or main heading, has rendered. It is the closest metric to the feeling that the page has arrived.
- Interaction to Next Paint (INP) measures how quickly the page responds visually after a click, tap or key press, across the whole visit. It replaced First Input Delay as a Core Web Vital in March 2024.
- Cumulative Layout Shift (CLS) measures how much content moves unexpectedly while the page is in use.
Each metric is assessed at the 75th percentile of page views, separately for mobile and desktop. So at least three in four visits must be good. The thresholds below are the ones Google publishes; we have not added any of our own.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading of the largest visible element | 2.5 seconds or less | More than 2.5 up to 4 seconds | More than 4 seconds |
| INP | Responsiveness to interactions | 200 milliseconds or less | More than 200 up to 500 milliseconds | More than 500 milliseconds |
| CLS | Visual stability | 0.1 or less | More than 0.1 up to 0.25 | More than 0.25 |
How to test your website speed
For almost every business, two free Google tools are enough.
PageSpeed Insights
PageSpeed Insights tests one URL at a time and shows two different kinds of data. Field data comes from real Chrome users over the previous 28 days and is what the Core Web Vitals assessment is based on. Lab data is a simulated Lighthouse test with a score from 0 to 100 and a list of diagnostics. It is useful for finding causes, but it is one run under fixed conditions.
The Core Web Vitals report in Search Console
Search Console groups similar URLs and shows which groups are good, need improvement or are poor, for mobile and desktop. This is where you see whether a problem belongs to a single page or to a whole template, such as every product page or every blog post. Google explains how to read it in the Search Console Help Centre.
Reading the results without being misled
- Start with field data. If the assessment says real users pass, the page is in good shape for visitors, even when the lab score is in the 70s.
- Look at mobile first. The mobile test simulates a mid-range phone on a slower connection, which is where most problems appear.
- Expect variation. Lab scores can move several points between runs because of network conditions, server load and third-party scripts. Watch the trend over weeks, not a single number.
- Read the diagnostics, not just the score. The report names the LCP element, the scripts that block rendering and the elements that shift. That is where the fix begins.
A score of 100 is not a business goal. A page that passes in the field and feels quick on a phone is in order for people and for Google.
Fixing slow loading (LCP)
A poor LCP almost always comes down to one of four causes, each covered in Google's guide to optimising LCP.
The server responds slowly
Nothing can render until the server sends the HTML. Underpowered hosting, no page caching and heavy database queries delay everything that follows. Remedies: full-page caching, a current server stack, a CDN and hosting sized for your traffic.
The main image is too heavy or found too late
Serve images at the size they are displayed, in modern formats such as WebP or AVIF, with responsive image markup so a phone does not download a desktop-sized file. Never lazy-load the image that is visible on arrival; give it priority instead, for example with fetchpriority="high".
CSS and JavaScript block rendering
Large stylesheets and scripts in the head of the page hold back the first paint. Defer non-essential scripts, remove unused code and load web fonts efficiently.
Content is built in the browser
When a page only becomes visible after JavaScript has assembled it, the largest element appears late. Where possible, deliver the main content as HTML from the server.
Fixing slow responses (INP)
INP is about what happens after someone interacts. If the browser is busy running JavaScript at that moment, the visitor waits. Google's guide to optimising INP goes into the technical detail; in practice the usual fixes are these.
- Audit third-party scripts. Chat widgets, tracking pixels, testing tools, review badges and social embeds accumulate over the years. For each one, ask who still uses it and what it is worth.
- Load scripts when they are needed. A chat widget can load after someone clicks the chat button rather than on every page view.
- Break up long tasks. Code that keeps the main thread busy for a long time can be split so the page can respond in between.
- Keep the page lean. A very large number of HTML elements, common with some page builders, makes every update slower.
Preventing layout shift (CLS)
You go to tap a button and, at the last moment, the page moves and you tap something else. That is layout shift. Google's guide to optimising CLS lists the common causes:
- Images and videos without dimensions. Set width and height attributes, or reserve the space in CSS, so the browser knows how much room to leave.
- Adverts, embeds and iframes that load without reserved space.
- Banners inserted at the top, such as a promotional bar or a cookie notice that pushes content down. Overlay them or reserve their space. Your cookie consent tool, which PECR makes a fixture of most UK sites, is a frequent culprit.
- Web fonts that load at a different size from the fallback font. Choose a closely matched fallback.
Speeding up a WordPress website
WordPress is not slow by nature, but it slows down easily. These are the causes we see most often, with the remedy for each.
- Too many plugins. Each can add scripts and styles to every page. Remove what is no longer used and replace heavy plugins with lighter alternatives.
- A heavy theme or page builder. Many visual builders output a lot of extra markup. On a new build, a lean theme or custom blocks is usually the more durable choice.
- Missing or duplicated caching. Use one caching layer, at server level or through a single plugin, rather than several that conflict.
- Unprocessed images. Resize and convert images automatically on upload.
- An outdated server environment. A supported PHP version and adequate hosting often improve server response time noticeably.
Always back up and test changes on a staging copy first. Speed is not a one-off job: every update or new plugin can undo it, which is why it belongs in ongoing website maintenance. If the site needs deeper work, a WordPress agency can rebuild the theme or plugin stack properly.
Keeping it fast, and when to get help
- Check the Core Web Vitals report monthly in Search Console.
- Test after every significant change: a new plugin, a new tracking tag, a redesign.
- Name an owner for the tag manager. Someone should decide what goes in and remove what is no longer needed.
Outside help pays off when the cause sits in the server or theme architecture, when several templates fail at once, or when the site depends so heavily on a page builder that small fixes achieve little. At that point a website redesign on a lighter foundation can cost less over time than continual patching.
Speed is one part of technical SEO, and a faster page also supports conversion rate optimisation. If you are unsure whether speed is really what holds your site back, or whether something else matters more, our strategy session is a 50-minute conversation with the founder about your ambition, your market and whether we fit. It is a conversation, not an audit or report.