Why is my WordPress site slow? A safe order for trying fixes and measuring each one

Record a baseline before you change anything

Every fix needs a before and after, otherwise you end up judging speed by feel. The WordPress optimisation handbook recommends two kinds of measurement: the performance tools built into browsers such as Firefox and Chrome, and online page benchmarking tools that test from different locations, browsers and connection speeds.

Pick three or four pages that matter, such as the home page, a typical post and a product or contact page. Test each one several times with the same tool and settings, then write down the results with the date. Single runs vary, so a set of numbers gives you something steadier to compare against later. Our guide to measuring the affected pages helps when the slowness only shows up in certain places.

Before touching anything, take a backup you know you can restore, or work on a staging copy. The WordPress debugging guidance asks for exactly that before any modification, and the same rule protects you while you tune performance.

Change one thing at a time and keep a way back

The routine is simple, and the discipline is what makes it useful. Change three things at once and the site gets faster, and you have no idea which change helped. Worse, if the checkout stops working, you cannot tell which change broke it.

Treat each result as an observation rather than proof. A faster score after deactivating a plugin is a strong hint, but server load, traffic and testing conditions also shift between runs. Repeating the test, and reversing the change to see whether the slowness returns, separates a genuine cause from a lucky moment.

1. Write down exactly what you are about to change and how to reverse it.
2. Make that single change.
3. Clear any caches, then re-run the same tests on the same pages.
4. Compare the numbers with your baseline and check key features such as forms, logins and the basket.
5. Keep the change if it helped without side effects, or reverse it if it did not.

Step one: remove WordPress plugins you do not need

Plugins are the first and easiest place to look. Deactivating and deleting unnecessary plugins is a significant way to improve performance, and selectively disabling plugins lets you measure which one is costing you time. Your theme matters as well: a lightweight theme performs far more efficiently than a heavy, graphic-laden one.

Start with plugins you no longer use or that duplicate another plugin's job. Open the Installed Plugins screen under the Plugins menu, deactivate one, re-test, and only delete it once you are sure nothing relied on it. When a plugin you genuinely need turns out to be slow, check its documentation, ask in its support forum or look for an alternative with similar features. Our notes on avoiding duplicate features help when you choose a replacement, and keeping the survivors current is covered in our guide to updating plugins safely.

Step two: optimise your images

Heavy images slow pages down and use up bandwidth. Begin by asking whether some images are unnecessary or could be replaced with text. For the ones you keep, choose the correct format (JPG, PNG or GIF) and compression for each, and consider a modern format such as WebP, which produces smaller files.

Work on the heaviest images on your baseline pages first, since those are the pages you measured. Replace or compress them, then re-test the same pages so the comparison stays fair.

Step three: add page caching

If you only have time for one change, caching gives the biggest benefit for the smallest hassle. A caching plugin saves your posts and pages as static files and serves those instead of building each page from scratch, which cuts the work your server does for every visitor.

Check what your host already provides before adding a plugin, so you know which layer you are testing. Pages with plenty of dynamic content, such as shop baskets, account areas and forms, make caching more complex to configure. After enabling it, test as a logged-out visitor, confirm fresh content appears after you publish, and submit a form. Our guide to choosing a caching plugin walks through a simple first configuration and those checks.

Step four: ask your host about software versions and object caching

Some remaining fixes sit with your hosting rather than inside WordPress. Current versions of PHP, the database server (MySQL or MariaDB), the web server and the operating system matter, because upgrades fix bugs and improve performance. Ask your host which versions your site runs and whether newer supported versions are available.

Raise persistent object caching in the same conversation. Without it, WordPress reads data such as your site options from the database on every page view, which slows the time to first byte and strains the database during traffic spikes. A persistent object cache needs a cache server supplied by your host, so it is a question for them rather than a plugin you can switch on alone.

Your hosting type decides how far you can go. On shared hosting the provider manages the server and you have very little control over its settings, so caching and WordPress-level changes are your main tools. Managed hosting is more locked down, with the provider choosing the software stack. A VPS or dedicated server gives you full control over software, along with the responsibility to manage it. Once the earlier steps are exhausted, more CPU, more memory, faster SSD or NVMe storage, or higher shared-plan resource limits can make a big difference, and our comparison of shared hosting by PHP limits and support helps when weighing a move.

Know the limits of what you measured

No official speed target applies to every site, and results vary by site and host. The meaningful comparison is your own site against its own baseline. A better score on one testing tool also says little about visitors far from your server, because geographical distance affects speed too.

Leave deeper diagnostics to a staging copy. WordPress debug tools are meant for local and staging installs rather than live sites, and the debug setting that saves every database query carries its own performance cost and needs turning off when you finish debugging. If the dashboard is the slow part, our guide to fixing a slow admin area takes a different route, and a memory limit error calls for a separate fix rather than more caching.