WordPress Slow? 10 Steps That Make Your Site Fast Again

Your site takes noticeably longer to load, PageSpeed Insights shows red bars, and Google Search Console is flagging your Core Web Vitals. No reason to panic, but a good reason to act. Speeding up a slow WordPress site is one of the most rewarding projects there is, because every second you save shows up directly in bounce rate, revenue and rankings.

This article walks you through ten concrete steps, from choosing a host to the uncomfortable question of which plugins are actually holding you back. You do not have to do all of them in one afternoon. Each step on its own produces measurable progress.

Your roadmap in ten steps

Before you start changing settings at random, here is the overview. The steps build on each other loosely, from the server layer through delivery in the browser to ongoing monitoring:

• 1. Hosting: check server response time and switch if it is bad
• 2. PHP version: move to a current, supported release
• 3. Caching: switch on page cache and object cache
• 4. Images: compress them and move to WebP or AVIF
• 5. Database: clean it out and keep it lean
• 6. Plugins: declutter, the most common brake of all
• 7. Theme: check for lean code instead of page builder ballast
• 8. CDN: move static files closer to your visitors
• 9. Lazy loading: load content only when it is needed
• 10. Measure: verify with PageSpeed Insights and Core Web Vitals

If you only have one afternoon, it helps to sort the list by effort, payoff and risk rather than working through it top to bottom. The ratings below come from our own support practice. The single measured figure in it is backed up further down in this article.

The list is sorted by technique. Sorted by result per minute invested it looks different: start with steps 3 and 6, because both cost little and give a lot. Steps 1 and 7 are for the day you have the calm for a clean migration.

Step 1: Pick hosting that is actually fast

Server response time, measured as Time to First Byte, is the foundation everything else rests on. On oversold budget shared hosting, even a perfectly optimised site will never feel fast, because hundreds of websites share the same resources. Managed WordPress hosting with server-side caching, enough PHP workers and modern storage (NVMe rather than classic SSD) often makes more difference than any plugin.

Also look at where the data centre sits. A location close to your audience shortens the round trip. If you serve visitors in the European Union, a data centre inside the EU also makes your GDPR paperwork simpler, because no third-country transfer has to be justified.

Step 2: Keep your PHP version current

WordPress runs on PHP, and the speed gap between old and current PHP releases is large. Moving from PHP 7.4 to a current PHP 8 release regularly produces double-digit percentage gains in benchmarks, with no code changes at all. Most hosts let you switch the PHP version yourself in the control panel.

Take a backup first, then test both the front end and the admin area thoroughly. Older plugins or themes are occasionally not fully compatible yet. That is useful information in itself: a plugin that breaks on current PHP is usually a plugin nobody is maintaining any more. How to roll out that kind of update without taking your site apart is in our guide to updating WordPress plugins.

Step 3: Use caching properly

A cache plugin saves WordPress from rebuilding the whole page out of the database on every single request. A page cache serves finished HTML files directly. An object cache, via Redis or Memcached if your host offers it, speeds up repeated database queries on top of that. Browser caching headers make sure returning visitors do not download your images, CSS and JavaScript all over again.

One side issue that gets overlooked: redirect chains and unanswered 404 errors cost extra time on every request, because the server has to resolve several hops before the real page loads. Clear those up in parallel. Our comparison of free WordPress redirect plugins covers the tooling for it.

Step 4: Shrink your images and move to WebP or AVIF

On most websites, images are the single largest consumer of load time. Two levers work immediately. First, the right file size: an image displayed at 800 pixels wide does not need to be delivered as a 4,000 pixel camera original. Second, the format: WebP and the newer AVIF compress with far less quality loss than classic JPEG or PNG and often save 30 to 50 percent in file size.

Many modern image optimisation plugins handle resizing, format conversion and responsive sizes automatically on upload. Check that exactly one such plugin is doing the job. Two of them running in parallel is a common and entirely self-inflicted problem.

Step 5: Clean out the database

Years of post revisions, expired transients, spam comments in the trash and orphaned tables from plugins you uninstalled long ago all inflate the database, and every query gets marginally slower as a result. A one-off cleanup, limiting revisions, deleting transients and optimising tables, rarely makes the biggest difference on its own, but it is a solid building block, especially on sites that have been running for years. Put it on a fixed rhythm, once a quarter is a sensible default.

Step 6: Declutter your plugins, the most common brake of all

When we dig into a slow WordPress site through a support request, this is where we end up in most cases. Not at the hosting, at overloaded plugins. One page builder with its own CSS and JavaScript framework, plus a mega plugin with fifty features of which you use three, plus two overlapping SEO tools, and every page ends up loading ten extra scripts to deliver one function that would take three lines of code.

Our advice, and we will say plainly that as a plugin vendor we are not neutral here: favour lean, focused plugins over all-rounders. A plugin that does one thing and does it cleanly is usually faster than a bloated suite that drags every feature along whether you need it or not. Gallery plugins are a classic example, and we put actual weight figures side by side in our NextGEN Gallery alternative comparison.

That is the principle behind Linkjet, MemberJet and Adjet: free, lean GPLv2 plugins with local statistics and no external calls, each solving one job and solving it quickly. Linkjet and the free edition of Adjet are in the official WordPress plugin directory, so you install them straight from your admin area. How much difference that makes is easiest to see against bloated ad plugins, which we wrote up in detail for our Advanced Ads alternative.

Here is the practical method. Deactivate every plugin you do not actively use on a daily basis, then measure load time again. What do you genuinely miss? Everything else can go, or be replaced with something leaner. If you want to see what a focused toolset costs, our pricing overview lists every plugin with its free tier. For the comparison to be worth anything, fix your method first: the same page, the same device, three runs per measurement, and the median counted. Single runs vary so much that you will otherwise mistake noise for progress.

Which plugin is actually eating the time is something the free Query Monitor tool will tell you far more reliably than your gut. Logged in as an administrator, it shows you for every page view how many database queries run and which plugin triggers them, which CSS and JavaScript files each plugin hangs into the page, and whether external HTTP calls are waiting in the background. Those calls are the quiet brake: a plugin that asks a foreign server on every page view makes your site exactly as slow as that server answers. We measured how often that actually happens across 72 plugins: what WordPress plugins load from external servers. So measure first, then deactivate, and do it one plugin at a time rather than five at once, or you will not know which one it was. If nothing loads at all after a deactivation or an update, our guide to the white screen of death gets you out again in a few minutes.

Step 7: Check your theme for lean code

Plugins are not the only thing that slows a site down. Themes do it too, especially visual page builder frameworks that ship large amounts of extra CSS and JavaScript for the sake of maximum flexibility, most of which goes unused on most pages. A lean, semantic theme loads noticeably faster because the browser has less code to parse and execute.

Open your browser developer tools, go to the Network tab, and look at how many CSS and JS files your current theme loads and how large they are. It is frequently an unpleasant surprise, and a good reason to consider a change. We build our own free block theme, Hafen, along exactly these lines. The theme does presentation and nothing else: structured data, llms.txt and the answer blocks sit in the companion plugin Hafen Core, because the directory requires that functions survive a theme switch. Install the theme on its own and you get no JSON-LD, which is why we recommend running both. Version 1.1.0, with 38 looks, has been in the official WordPress theme directory since 22 September 2026.

How much a theme switch actually returns is something we measured instead of estimating. flirtuniversity.de, a site with 17 years of content, a members area, consent management and video embeds, moved from Neve to Hafen on 1 September 2026, then at version 0.9.0. Measurements were taken on the same day, on the same machine, with Lighthouse 13.4.1 in headless Chrome, three runs per page and device, median counted. The plugin stack stayed untouched, so this is the theme effect on its own:

• Mobile Lighthouse score: plus 14 to 18 points on all four page types measured, from 56 to 71 on the home page
• JavaScript: minus 34 to 40 per cent, from 621 to 382 kilobytes on the home page
• First Contentful Paint on mobile: from around 4 seconds to 1.3 seconds
• Requests: 22 to 38 per cent fewer, with layout stability staying at 0.00

For a sense of what a theme itself has to weigh: Hafen 1.1.0 ships 38,191 bytes of CSS and 3,344 bytes of JavaScript, which is 12,987 bytes compressed across two requests. Everything beyond that is a decision, not a necessity.

Honesty demands the other half of the story. The 360 to 400 kilobytes of JavaScript left after the switch came almost entirely from the plugins, and the Largest Contentful Paint stayed at 4 to 6 seconds on mobile, because the largest element was a video poster loaded in by JavaScript. A light theme does not rescue heavy content, it only reveals who is carrying the weight. That is why step 6 comes before step 7 in this article. Every number, including the disappointing ones, is in our theme switch case study.

Step 8: Put a CDN in front

A content delivery network spreads static files such as images, CSS and JavaScript across servers around the world, so visitors load them from the nearest location rather than from your single origin server. It pays off particularly if you have an international audience or serve a lot of large media files.

When choosing a provider, check the data protection terms. If any of your visitors are in the EU, GDPR applies to you regardless of where your company sits, so make sure the provider offers a proper data processing agreement. This is an assessment for orientation, not legal advice. Speed is not worth a compliance problem.

Step 9: Use lazy loading

Why should the browser load images and embedded videos that the visitor only sees after scrolling a long way down? Lazy loading prevents exactly that: content outside the visible area loads only when it is actually needed. Modern browsers support this natively through the loading="lazy" attribute, and current WordPress versions already apply it to images automatically. What the browser handles on its own, and which image you must exclude, is covered in lazy loading in WordPress.

Still, check embedded videos, maps and ad slots further down the page specifically. Those are the places where lazy loading gets forgotten most often, and they are usually the heaviest items on the page.

Step 10: Measure instead of guessing

Optimisation without measurement is flying blind. Google PageSpeed Insights shows you for free where exactly your site loses time and scores it against the three Core Web Vitals metrics: LCP (Largest Contentful Paint, how quickly the main content becomes visible), INP (Interaction to Next Paint, how quickly the page responds to clicks) and CLS (Cumulative Layout Shift, how much the layout moves around while loading).

Google Search Console aggregates those values across your whole site as well, using real user data rather than lab values. Measure before every larger change and again afterwards. That is the only way to see which of the ten steps actually helped on your site, and which one was not worth the effort.

What to do first

Speeding up a slow WordPress site is rarely one big move. It is the sum of many small adjustments across hosting, PHP version, caching, images, database, theme and CDN. In our experience the best result per minute invested comes from step 6: consistently clearing out overloaded, poorly maintained plugins and replacing them with lean, focused alternatives, which leaves fewer plugins to keep current and makes updating WordPress plugins less of a chore. Start there, measure with PageSpeed Insights, then work through the rest of the list one step at a time.

Frequently asked questions