performancewordpress site slow fixwordpress performance optimisation9 min read
Why your WordPress site is slow — and how to fix it in a week
Why your WordPress site is slow, the seven real culprits, and a five-day fix plan from a UK web agency that does this every week.
By NEXUS EditorialPublished
A slow site bleeds money quietly. You don't see it on the dashboard. You see it in the bounce rate creeping up, the Google Search Console "Poor URLs" count climbing, the paid traffic that converts a third as well as it used to. Then one day someone in your team runs PageSpeed Insights, sees a mobile score of 28, and forwards it to you with a question mark.
If your WordPress site loads slowly, you're not alone and you're not stuck. WordPress isn't fundamentally slow — millions of fast WordPress sites exist. Your WordPress site is slow because of specific, identifiable things, almost all of which can be fixed in a working week without rebuilding from scratch.
Here's why it happens, and a day-by-day plan to make it stop.
What "slow" is costing you
Before the fixes, a quick reality check on the business case. Google has been clear since 2021: page experience is a ranking factor. Beyond rankings, the conversion impact is brutal and well-documented.
A one-second delay in page load drops conversions by around 7%. Mobile users abandon a site after three seconds 53% of the time. If you're running a £100k/month e-commerce shop with a five-second LCP, you're leaving roughly £15k–£20k a month on the floor that better-funded competitors are picking up.
That's the size of the problem. Now the seven reasons it's happening.
Cheap shared hosting is the silent killer behind most slow WordPress sites. Source: Pexels
The seven most common reasons WordPress sites are slow
1. Unoptimised images
The single biggest culprit, in our audits, every single time. Someone uploads a 4MB hero image straight from a stock photo site, WordPress serves it at full resolution to mobile users on 4G, and your Largest Contentful Paint goes through the roof.
Concrete fix: install ShortPixel, Imagify or Smush. Bulk-optimise the existing media library — most sites we audit save 60–80% of their image weight. Convert to WebP (or AVIF where supported). Set max upload dimensions to 2400px. Stop uploading PNG screenshots when JPEG would do.
2. Bloated plugins
The average WordPress site we audit has 32 plugins. The fastest WordPress sites we run have 8–12. Each plugin adds queries, scripts, stylesheets, and sometimes admin overhead even on the front end.
Concrete fix: install Query Monitor and look at what each page actually loads. Deactivate plugins you don't use. Replace bloated all-in-one plugins (looking at you, Jetpack with 30 modules enabled) with focused single-purpose alternatives. As a rule of thumb, every page builder addon plugin you can remove is a measurable speed win.
3. No caching layer
WordPress regenerates every page on every request by default. PHP runs, MySQL gets queried, the page is assembled. For a logged-out visitor reading your About page, this is absurd — that page hasn't changed in months.
Concrete fix: install a proper caching plugin. WP Rocket (paid, the easiest) or LiteSpeed Cache (free, if your host supports it) or W3 Total Cache. Enable page caching, browser caching, GZIP compression and database optimisation. On a fresh install of WP Rocket alone, we routinely see Time To First Byte drop from 1.2s to under 200ms.
4. Cheap shared hosting
The hard truth. If you're paying £4/month for hosting, your site is on a server with hundreds of other sites, your PHP version is probably out of date, and your database is on a spinning disk somewhere. There is no plugin in the world that fixes a server that takes 1500ms to respond before WordPress even starts running.
Concrete fix: check your Time To First Byte. If TTFB > 600ms, your host is the bottleneck. Move to managed WordPress hosting — Kinsta, WP Engine, SiteGround GoGeek, Cloudways with Vultr High-Frequency, or Pressable. Expect to pay £25–£60/month. The TTFB difference is usually the single biggest win in any WordPress speed audit.
5. Render-blocking scripts
You open the page source on a slow WordPress site and find 14 <script> tags in the <head>, each one stopping the browser from rendering until it's downloaded and parsed. Google Tag Manager. Hotjar. A live chat widget. The cookie banner. A font loader. Three different analytics scripts.
Concrete fix: defer or async everything that isn't critical for first paint. WP Rocket and FlyingPress have script-delay features that wait until user interaction before loading non-essential scripts (cookie banners, chat widgets, analytics). Move Google Tag Manager to load on interaction. Inline critical CSS, defer the rest. PageSpeed Insights' "Eliminate render-blocking resources" section tells you exactly what to defer.
6. No CDN
Your server is in London. Your visitor is in Sydney. Without a CDN, every asset — every image, every CSS file, every script — flies halfway round the planet on every request. That's 200–400ms of latency for nothing.
Concrete fix: Cloudflare's free plan. Sign up, point your nameservers, enable "Auto Minify", "Brotli" and "Rocket Loader" (carefully — test it doesn't break your JavaScript). For e-commerce or anywhere you care about page rules, BunnyCDN at $1/month per site is also excellent. Either way, you've just put your static assets within 50ms of every visitor on earth.
7. Theme overhead — Elementor, Divi, WPBakery
This is the unspoken one. Page builders are wonderful for marketers. They are catastrophic for performance. A vanilla WordPress page with the Twenty Twenty-Four theme weighs about 80KB. The same page rebuilt in Elementor weighs 400–600KB and ships 12 separate CSS files.
Concrete fix (in order of pain):
Easiest: enable the page builder's own performance settings (Elementor "Improved Asset Loading", Divi "Performance" tab). Switch on "Optimised DOM output", "Inline font icons", "Improved CSS loading".
Medium: audit which builder widgets you actually use and disable the rest. Elementor loads CSS for every widget type by default.
Hard but worth it: rebuild key landing pages in Gutenberg blocks or with a lightweight builder like GeneratePress. Conversion-critical pages don't need 600KB of CSS.
Every good fix starts with an honest audit. Source: Pexels
The week-by-week fix
A concrete five-day plan you can hand to a developer, or follow yourself if you're technical enough to read this article.
Day 1 — Audit
Don't fix anything yet. Measure. You can't improve what you don't track.
Run these, save the reports:
PageSpeed Insights on three URLs: home, top landing page, top blog post. Note the mobile scores and the four metrics: LCP, INP, CLS, TBT.
GTmetrix on the same three URLs (London server). Note TTFB specifically.
Query Monitor (free plugin): install it, open your homepage logged out, then logged in as admin. Note the slowest queries and the heaviest plugins.
Lighthouse in Chrome DevTools: mobile, throttled "Slow 4G". This is what Google sees.
You're looking for the headline numbers: LCP target < 2.5s, INP < 200ms, CLS < 0.1, TTFB < 600ms.
Day 2 — Images and hosting
The two biggest needle-movers.
Morning: install ShortPixel or Imagify. Bulk-optimise the entire media library to WebP. Run the script overnight if it's a big library.
Afternoon: check your TTFB from Day 1. If it's above 600ms, start the host migration conversation. Most managed hosts will migrate your site for free. The move itself takes a few hours and is the single biggest performance gain available to you.
Day 3 — Plugin audit and caching
Morning: list every plugin. For each one, ask "what does this do, when did we last use it, can we live without it?" Deactivate (don't delete yet) the bottom 20%. Test the site. Delete after 48 hours if nothing breaks.
Afternoon: install WP Rocket. Default settings are already good. Enable page caching, browser caching, GZIP, lazy-load for images and iframes, defer JS, delay JS execution (start with gtm.js, googletagmanager, chat widgets, hotjar). Test.
Day 4 — Script deferral and CDN
Morning: sign up for Cloudflare, change nameservers (allow 24h propagation). Enable Brotli, Auto Minify, Always Use HTTPS. Set browser cache TTL to 1 month.
Afternoon: run PageSpeed Insights again. Look at "Eliminate render-blocking resources". For each script flagged, either defer it in WP Rocket's File Optimization, or — if it's not needed at all on this page — conditionally remove it (use Asset CleanUp or Perfmatters for per-page script control).
Day 5 — Test, compare, document
Re-run every measurement from Day 1. Same URLs, same conditions, same tools. Drop the numbers into a before/after spreadsheet.
A realistic outcome from a week's work: mobile PageSpeed score from 35 → 75–85, LCP from 5.2s → 1.8s, TTFB from 1100ms → 250ms, total page weight halved.
Document what you changed and why. The next person to touch the site (or future you, six months from now) needs to know which plugins are deliberate and which are essential.
Some problems aren't fixable in software alone. Source: Pexels
When DIY isn't enough — signs you need a rebuild
The week-by-week plan works on roughly 80% of slow WordPress sites. For the other 20%, the rot is too deep. Honest signals it's time to consider a rebuild rather than another fix:
Your theme is a heavily customised Divi or Avada job from 2018 with hundreds of custom CSS overrides.
You have 80+ plugins and removing any of them breaks something.
The site uses a long-abandoned page builder or theme framework.
Even after the full week of fixes, mobile PageSpeed sits below 50.
The database is over 500MB and full of orphaned data from plugins you removed years ago.
You're paying more in monthly plugin licences than a managed host would cost.
Rebuilding doesn't necessarily mean leaving WordPress. It often means a clean install with a lean theme (GeneratePress, Kadence, Blocksy), Gutenberg + ACF instead of a page builder, and 10 carefully chosen plugins instead of 40 accumulated ones. Or it might mean moving to a headless setup, or to Webflow. That's a different conversation.
How Nexus approaches WordPress performance
When a client asks us to fix their slow WordPress site, our first 48 hours are measurement, not action. We replicate their real-world conditions (mobile, throttled connection, common geographies), audit the database, audit the plugin and theme stack, profile actual page loads in WebPageTest filmstrip view, and identify the three changes that will produce the biggest delta.
We then quote a fix sprint with concrete targets — "LCP under 2.0s on mobile, mobile PageSpeed above 85, TTFB under 300ms" — not vague "we'll make it faster" promises. Performance targets are written into the SOW.
If during the audit we find the site is past saving, we say so. Rebuilding is usually cheaper than three years of patching.
Want us to audit your site?
We'll run a full performance audit on your live WordPress site and send you a written report with the top five issues, the business impact of each, and what it would cost to fix them. Turnaround is 48 hours. There's no obligation to use us for the fix — most reports give you everything you need to brief your existing developer. Request an audit.
Performance triage often looks less glamorous than people imagine.
FAQ
Q: Will switching hosts break my WordPress site?
No, if it's done properly. A good managed host migrates the site for you, often in 2–4 hours, with no downtime if DNS is handled correctly. Test thoroughly on the staging URL before you flip the DNS.
Q: Is WP Rocket worth the £49/year?
Yes, easily. It's the single most cost-effective performance investment available to WordPress. The free alternatives (LiteSpeed Cache if your host supports it, W3 Total Cache otherwise) work but require more configuration and more frequent troubleshooting.
Q: How fast can a WordPress site realistically be?
A well-built WordPress site on managed hosting with a lean theme, ten plugins, a proper CDN and caching layer can hit mobile PageSpeed 90+ with sub-1.5s LCP. That's slower than a hand-coded Next.js site, but well inside Core Web Vitals "good" thresholds and indistinguishable to users.
Q: Should I move off WordPress entirely if it's this much trouble?
Not necessarily. WordPress runs 40% of the web for good reasons: enormous ecosystem, easy editing, vast talent pool. The question is whether your WordPress site is past the point where fixing it costs more than rebuilding. For most sites the answer is no. For sites with five years of accumulated plugin debt and a page builder addiction, the answer is yes.
