Speeding up WordPress is one of the most common requests we get, and it usually arrives with a list of plugins the owner has already tried. The site has a caching plugin, an image plugin, a minification plugin and a "performance" plugin that promises to do all three. It is still slow, and now it is also fragile.
The reason is simple. Most slow WordPress sites are slow for the same handful of reasons, and adding tools on top of those reasons does not remove them. This guide goes through seven fixes in the order that normally pays off, starting with the ones that affect every page and ending with the ones that only matter once the basics are right.
Why speeding up WordPress starts with measuring
Before changing anything, record where the time actually goes. Run your home page, one typical inner page and one heavy page (a product listing, a long article, a page with a slider) through PageSpeed Insights. Save the results. Note three things for each page: how long the server takes to send the first byte, how large the page is in total, and how many separate requests it makes.
Those three numbers already tell you which fix comes first. A slow first byte points at hosting or caching. A heavy page points at images, fonts or a builder. A very high request count points at plugins and third-party scripts loading on every page. Guessing skips this step, and guessing is how sites end up with four optimisation plugins fighting each other.
Google's own guidance on Core Web Vitals explains the three user-facing measures worth watching: how quickly the main content appears, how quickly the page responds to input, and how much the layout shifts while loading. Keep those in mind as the goal. A score is only a summary of them.
Fix 1: Hosting that is not starving the site
WordPress builds pages with PHP and a database. If the server is underpowered, overloaded with other customers, or running an outdated version of PHP, every uncached request waits. No front-end trick recovers time the server has already lost.
Check three things with your host. First, the PHP version: current supported versions are noticeably faster than old ones, and running an old version is also a security problem. Second, whether the plan includes server-level caching or an object cache. Third, where the server is located relative to your visitors. A site serving customers in one region from a data centre on another continent pays for that distance on every request.
If the first-byte time stays slow even for a simple page with caching turned on, the hosting is the bottleneck. Moving to better hosting is often the single biggest improvement available, and it is worth doing before anything else on this list. The official WordPress optimisation documentation covers server-side options in more detail.
Fix 2: Page caching, done once and done properly
Page caching stores the finished HTML of a page so the server does not rebuild it for every visitor. For most brochure sites and blogs it is the most effective change after hosting, because it turns a database-driven page into a file that can be sent almost instantly.
The rule is one caching layer, configured deliberately. Many hosts already provide caching at the server level. If yours does, a second caching plugin on top usually adds nothing and can cause stale pages or conflicts. If yours does not, choose one reputable caching plugin and learn its settings rather than installing three and hoping.
Pay attention to what must not be cached. Cart, checkout and account pages on a shop, and any page showing personalised content, need to be excluded. A cache that serves one customer's cart to another is worse than no cache at all. Test logged-out and logged-in behaviour separately after you configure it.
Fix 3: Images sized for the screen they appear on
Images are the heaviest part of most pages. The usual problem is not the format but the size: a photo straight from a phone or camera, several thousand pixels wide, displayed in a column a few hundred pixels wide. The visitor downloads all of it and the browser throws most of it away.
Resize images before uploading, to roughly the largest size they will ever be displayed. WordPress then creates smaller versions automatically and serves an appropriate one to each screen, as long as your theme outputs images in the standard way. Compress them sensibly, and use a modern format where your setup supports it.
Two further details matter. Images below the first screen should load lazily, which current WordPress does by default for most images. The main image at the top of the page should not be lazy-loaded, because delaying it delays the moment the page looks ready. Many themes and plugins get this second point wrong.
Fix 4: Fonts and third-party scripts
Web fonts and third-party scripts are the quiet cost on many sites. Each font family and weight is a separate file. A theme that loads four families in six weights each can add a surprising amount of weight before any content is visible. Choose one or two families and only the weights you actually use.
Third-party scripts are harder, because each one was added for a reason: chat widgets, analytics, heatmaps, advertising pixels, embedded reviews, social feeds. Each one also downloads code from another server and competes with your own page for the visitor's connection and processor.
List every script the site loads and ask who still uses it. Tracking tools installed for a campaign that ended long ago are common. So are two analytics tools measuring the same thing. Remove what nobody uses, and load what remains only on the pages that need it. A chat widget rarely needs to load on every blog post.
Fix 5: Plugins that load everywhere
The number of plugins matters less than what each one does on every page load. A plugin that adds a contact form should load its styles and scripts on the contact page. Many load them site-wide, so every page carries the weight of every feature the site has ever had.
Go through the plugin list and sort each one into three groups: essential, useful on specific pages, and no longer needed. Deactivate and delete the third group. For the second group, check whether the plugin offers a setting to load only where it is used, or whether a small amount of code could replace it entirely. Features such as adding a tracking snippet or a simple redirect rarely justify a whole plugin.
Be careful with plugins that promise to "optimise" by combining and delaying scripts. They can help, but they also cause some of the hardest bugs to trace, because they change the order in which other plugins' code runs. Use one, configure it conservatively, and test forms, menus and checkout after every change.
Fix 6: The theme and page builder underneath
Some sites are slow because of what they are built on. Multipurpose themes include styles and scripts for dozens of layouts the site never uses. Page builders wrap every element in several layers of markup and often load their full library on every page.
That does not mean every builder site must be rebuilt. Most builders now include settings to load assets more selectively, and turning those on is worth doing. Removing unused sections, sliders and animations also helps. Sliders in particular are heavy and rarely add much for visitors.
When a site has been extended over years and every change makes it slower, a rebuild on a lean, well-coded theme can be cheaper than continuing to patch. That is a judgement call based on the site's size and how often it changes. We cover the trade-off in more detail on our WordPress development service page.
Fix 7: The database and scheduled tasks
Over time the database collects clutter: hundreds of stored revisions per page, expired temporary data, leftovers from deleted plugins, and spam comments. On a small site this is harmless. On a site with years of content and a busy shop, it slows down the admin area and uncached pages.
Limit the number of revisions WordPress keeps, clear out data left by plugins you have removed, and make sure the database tables are healthy. Always take a full backup before any database clean-up, and restore-test it, because a clean-up that removes the wrong rows cannot be undone.
Check scheduled tasks too. WordPress runs background jobs such as sending emails and publishing scheduled posts. On some sites a broken or overly frequent task runs constantly and slows everything. Switching WordPress's built-in scheduler to a real server schedule is a common and reliable fix on busier sites.
Mistakes that undo the work
A few mistakes come up again and again after a speed project. The first is testing only while logged in. Logged-in administrators usually bypass the cache and load extra admin tools, so the site looks slower to them than it is for visitors, and they keep changing settings that were already right. Test in a private browser window.
The second is chasing a perfect lab score. A page that scores slightly lower but loads its main content quickly for real visitors on real phones is better than a page tuned to a test at the expense of features customers use. The third is making several changes at once. When something breaks, nobody knows which change caused it, and the safest response becomes undoing everything.
Finally, keep a short record of what you changed and why. The next person to work on the site, possibly you in a year, will need it.
Keeping the site fast after speeding up WordPress
Performance drifts. New plugins, new tracking scripts, new sections on the home page and larger images all add up. A site that tests well at launch is usually slower a year later without anyone deciding to make it slower.
The simplest defence is a routine. After any significant change, re-test the same three pages you measured at the start. Once a month, look at the field data for real visitors in Search Console's Core Web Vitals report. Treat new plugins as a cost that needs a reason, not a free addition.
It also helps to agree a rule with whoever adds content: images resized before upload, no new embeds without checking their weight, no new plugin without asking. Speeding up WordPress once is useful; keeping it fast is where the lasting benefit comes from.
When to bring in help
You can make most of these fixes yourself if you are comfortable in the WordPress admin and take backups first. Bring in a developer when the first-byte time stays slow on good hosting, when the site uses a builder you cannot safely change, or when optimisation plugins keep breaking parts of the site.
A good developer will measure before and after, change one thing at a time, and explain what each change did. Be wary of anyone who promises a particular score without looking at the site first. If you would like us to review yours, our services overview explains what we do, and you can reach us through the contact page.