WordPress speed: the 12 fixes that take a site from 40 to 95 on Lighthouse

To speed up a slow WordPress site, fix things in this order: measure properly, move to decent hosting on a current PHP version, add page caching and a CDN, get rid of the page builder or bloated theme, cut plugins, then optimise images, fonts, JavaScript, CSS and third-party scripts, and finally stop layout shift. Those 12 steps, done in sequence, are how we take a typical small business site from a mobile Lighthouse score in the 30s or 40s to 95 or above. Below is each fix, what it involves, roughly how long it takes, and what it typically gains.

A note on the numbers: Lighthouse scores on mobile are measured on a simulated mid-range phone over a throttled connection, so a site that feels fine on your office broadband can still score 38. That is the point. Plenty of your visitors are on a train out of Manchester Piccadilly or a patchy 4G signal in rural Wales, not on fibre.

Why speed matters beyond the score

Google uses Core Web Vitals as part of its page experience signals. The “good” thresholds are Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds and Cumulative Layout Shift (CLS) below 0.1, measured on real visitors at the 75th percentile. Speed will not rescue weak content, but between two similar pages, the faster one tends to win, and it almost always converts better. If those three terms are new to you, our Core Web Vitals guide explains them without the jargon.

The commercial case is simpler. Every second a phone user stares at a white screen is a chance for them to hit back and tap the next result. We have yet to meet a client whose enquiries went down after their site got faster.

The 12 fixes, in order

1. Measure properly before touching anything

Run PageSpeed Insights on your home page and two or three key templates (a service page, a blog post, a product page). Note both sections: the field data from real Chrome users (if your site has enough traffic) and the lab data from Lighthouse. Record LCP, INP, CLS, Total Blocking Time and the LCP element itself. Run each test three times; Lighthouse scores wobble by several points between runs. Without a baseline you cannot tell which fix helped.

2. Hosting and PHP version

If your server takes over a second to respond, nothing else will save you. Check Time to First Byte (TTFB) in PageSpeed Insights or your browser’s network tab; Google’s guidance suggests about 0.8 seconds or less is good, and on a well-hosted cached WordPress site we aim for well under that. Cheap shared hosting with hundreds of sites per server is the most common cause of slow TTFB we see. Move to a managed WordPress host or a properly configured VPS, ideally with UK or nearby EU data centres, and run a currently supported PHP 8 version. Upgrading from PHP 7.4 alone often gives a noticeable improvement in back-end response time, provided your plugins are compatible.

3. Page caching and object caching

Full-page caching means WordPress builds each page once and serves the saved HTML to everyone else, instead of running PHP and database queries on every visit. Use your host’s server-level cache if it has one, or a single well-supported caching plugin. Do not stack two caching plugins. For sites with logged-in users, WooCommerce carts or heavy admin use, add a persistent object cache such as Redis so repeated database queries are held in memory.

4. A CDN in front of the site

Cloudflare’s free plan is enough for most small business sites. It serves static files from locations close to each visitor, handles HTTP/3 and Brotli compression, and absorbs a lot of junk traffic before it reaches your server. With careful rules, you can also cache full HTML pages at the edge, which takes TTFB down dramatically for visitors anywhere in the UK and beyond.

5. Replace the page builder or bloated theme

This is the big one, and the one nobody wants to hear. Multipurpose themes and visual page builders load large CSS and JavaScript files on every page and wrap content in deeply nested markup. You can tune them, but there is a ceiling. On many sites we audit, the page builder alone accounts for most of the unused CSS and JavaScript Lighthouse complains about. A hand-built theme using native WordPress blocks typically ships a fraction of the code. We explain why we work this way in custom WordPress development without page builders.

6. Audit your plugins

Count them, then ask of each one: is it used, and does it load anything on the front end? Common offenders are sliders, social sharing buttons, multiple form plugins, “all-in-one” toolkits and plugins that add a feature to every page when it is only used on one. Query Monitor will show you slow database queries and which plugin is responsible. Delete what you do not need, and replace heavy plugins with lighter ones or a few lines of theme code.

7. Images: size, format and loading order

• Resize uploads to the largest size they display at. A 4,000-pixel photo straight off a phone has no business in a 400-pixel card.
• Serve WebP or AVIF. WordPress supports both formats, and most optimisation plugins and Cloudflare can convert on the fly.
• Make sure responsive srcset and sizes attributes are present so phones download small versions.
• Never lazy-load the LCP image (usually the hero). Give it fetchpriority="high" instead. Recent WordPress versions do much of this automatically, but themes and builders frequently override it.
• Lazy-load everything below the fold, which WordPress does by default for most images.

8. Fonts

Self-host your web fonts instead of loading them from Google Fonts (which also avoids sending visitor IP addresses to a third party, a point the UK ICO and EU regulators have both taken an interest in). Use WOFF2, subset to the characters you need, limit yourself to two families and three or four weights, add font-display: swap and preload only the one font used above the fold.

9. JavaScript

Defer non-essential scripts, remove jQuery from the front end if your theme does not need it, and load scripts only on pages that use them. Heavy JavaScript is the main cause of poor INP, because the browser cannot respond to a tap while it is busy running code. Long tasks over 50 milliseconds show up as Total Blocking Time in Lighthouse.

10. CSS

Inline the small amount of critical CSS needed for the first screen and load the rest without blocking rendering. Remove unused CSS where your tooling allows it safely, and tell WordPress to load block styles only for blocks actually used on each page. A lean custom theme often ends up with a stylesheet under 30 KB; a builder site can easily exceed 300 KB.

11. Third-party scripts

Tag managers, chat widgets, review carousels, heatmaps, embedded YouTube videos and social feeds are frequently the biggest drag on a site that is otherwise well built. Audit them with the business owner, not just the developer: half are often left over from a campaign that ended years ago. Replace YouTube embeds with a lightweight facade that loads the player on click, delay chat widgets until user interaction, and load analytics only after consent where your cookie banner requires it.

12. Stop layout shift

CLS comes from elements moving after the page appears: images without width and height, cookie banners pushing content down, late-loading fonts and ads or embeds without reserved space. Set dimensions on every image and iframe, reserve space for anything that loads late, and make cookie banners overlay the page rather than push it.

What each fix is worth

Every site is different, so treat this as a guide to where the effort goes rather than a promise.

What it costs to have it done

On a site that does not need a rebuild, fixes 1 to 4 and 6 to 12 usually fit into a speed sprint of 10 to 15 hours. Worked examples at our WordPress development rate of £50 per hour, excluding VAT unless stated:

• 10 hours: £500, less our 10-hour discount of 5 % (£25), is £475 plus £95 VAT, so £570 in total.
• 15 hours: £750, less our 15-hour discount of 10 % (£75), is £675 plus £135 VAT, so £810 in total.

Hours bought through Hire us never expire, so anything left over can go towards later work. If the audit shows the page builder is the ceiling, compare the cost of continued tuning with a rebuild. A hand-coded WordPress site through our fixed-price packages starts from £750 for the Pro Website and £999 for the Elite Website, both excluding VAT, and every template we deliver is built to score 95+ on Lighthouse and meet WCAG 2.2 AA.

Common mistakes we see

• Installing three “speed” plugins that fight each other and break the checkout.
• Chasing a perfect 100 on the home page while product pages sit at 45.
• Testing only on desktop. Google ranks mainly on the mobile version of your site.
• Lazy-loading the hero image, which makes LCP worse, not better.
• Fixing speed once and never checking again. New plugins, new tracking tags and a marketing video on the home page will drag it back down within months.

Keeping it fast

Speed is not a one-off job. Check PageSpeed Insights monthly, keep an eye on the Core Web Vitals report in Google Search Console, and ask whoever adds new plugins or scripts to test before and after. A good WordPress maintenance plan should include this alongside updates and backups.

Quick checklist

• TTFB under about 0.8 seconds on mobile tests
• Current PHP 8 version, page cache and Cloudflare in place
• No page builder, or a clear plan to remove it
• Fewer than 20 active plugins, each justified
• Hero image not lazy-loaded, served as WebP or AVIF with fetchpriority high
• Two font families at most, self-hosted, WOFF2
• No render-blocking scripts in the head except what is essential
• Third-party scripts audited and delayed where possible
• Width and height on all images and embeds
• LCP under 2.5 s, INP under 200 ms, CLS under 0.1 in field data

If you would rather hand it over, we do this work for WordPress sites across the UK from our base in St Albans. Send us the address through our contact page and we will tell you which of the 12 fixes matter for your site, or see our CMS development service for rebuilds.

Photo: Julian Hochgesang via Unsplash