“My WordPress site is slow” is one of the most common problems, and the most common mistake is to start with an all-in-one optimisation plugin, without knowing what the page is loading. The speed of a WordPress site comes from a few decisions, and their impact is not equal: hosting and caching matter far more than minifying a CSS file.
This guide takes you through optimisation in order of impact: what to measure, what to fix first and what is not worth doing. If you run a WooCommerce store, also read the guide on INP and Core Web Vitals in WooCommerce, which covers the cart and checkout. For an audit done by a team, see our speed optimisation service.
In short, in order of impact: (1) measure on real data; (2) choose suitable hosting and a suitable PHP version; (3) enable page and browser caching; (4) optimise images, especially the main one; (5) clean up plugins and the theme; (6) defer the CSS, JavaScript and fonts that block rendering; (7) control third-party scripts; (8) deal with the database last. Change one thing at a time and measure after every step.
1. Measure before you change anything
Use two kinds of data. Real data from users is in the Core Web Vitals report in Search Console and in the real-data section of PageSpeed Insights: it tells you how your visitors experience the site, including those on slow phones. Lab tests (Lighthouse, WebPageTest) are useful for finding causes, but they do not replace real data.
For each important page, note three things: the time to the first byte from the server (TTFB), the time until the main element appears (LCP) and the total weight of the page. If TTFB is high, the problem is in the server and the caching, not in the images. To see what slows down the code itself, a plugin such as Query Monitor shows slow database queries and the plugins responsible. Do not chase a score of 100 on a test: follow the timings and the real data.
2. Hosting and the PHP version
Hosting sets the floor for your speed. On an overcrowded server or one with too few resources, no front-end optimisation saves you. Ask what processor and how much memory your account gets, whether there are limits on simultaneous PHP processes and whether you are isolated from other sites. A WordPress site with steady traffic, or a store, deserves dedicated resources or hosting optimised for WordPress, not the cheapest shared plan.
Also check the PHP version. Newer versions are usually faster and safer, and outdated ones no longer receive security updates. Use a version that is still officially supported (check the list on php.net), after you have tested your plugins on staging. If you need an environment configured for WordPress and WooCommerce, see what optimised WordPress and WooCommerce hosting looks like. A CDN such as Cloudflare brings static files closer to the visitor and reduces the load on the server.
3. Caching: page, browser and object
Every visit to a WordPress page without caching means PHP executions and database queries. Page caching saves the ready-made result and serves it directly, which can cut response time a lot. Choose a single page caching mechanism (a dedicated plugin or the server’s cache), not two that overlap, and exclude the cart, checkout and customer account from the cache, because the content there is personalised.
Browser caching keeps static files on the visitor’s device. It is configured through expiry headers: on our own site, CSS, JavaScript, images and fonts have a 30-day expiry header, so a returning visitor does not download them again. Object caching (for example Redis) saves the results of repeated queries, and its effect is felt mostly on sites with a lot of dynamic content, such as a store.
4. Images, most often the culprit for LCP
Most of the time the main element of the page is an image, so it determines LCP. Four rules bring the biggest gains:
- A modern format. WebP or AVIF are much smaller than JPEG or PNG at the same visual quality.
- The right size. Do not load a 4,000-pixel image where an 800-pixel one is displayed. Use responsive images so the browser picks the right size.
- Lazy-loading for what is below the fold, but not for the main image: that one you load with priority.
- Width and height set, so the page does not jump while loading.
We applied these rules to our own article system too: hero images are converted automatically to WebP, at most 1,600 pixels wide, with the dimensions saved and a loading priority.
5. Plugins and theme: the cleanup that matters
The number of plugins is not the problem, what each one does is. A well-written plugin can be light, and a badly written one can slow down the whole page. Take an inventory: for each plugin, ask what it is for, whether it is still needed and whether it loads CSS or JavaScript on pages where you do not need it. Deactivate what you do not use, replace several small plugins doing the same thing with a single one and check with Query Monitor which are the slowest.
The theme matters just as much. Visual page builders add a lot of code and a large DOM, which slows rendering, and a “multi-purpose” theme often loads features you never use. For a site your business depends on, a custom theme or plugin can cost less over time than a heavy theme that must constantly be worked around; for that, see our custom WordPress development service.
6. CSS, JavaScript and fonts
CSS and JavaScript files that block rendering delay the page from appearing. Defer non-critical JavaScript (defer), load critical styles inline and the rest in a separate file, and remove unused code. Google fonts often slow the first display: preload critical fonts and load the rest without blocking rendering, as we did on our own site, where non-blocking font loading fixed a PageSpeed warning. Minifying and combining files helps less than people think, and aggressive minification can break functionality, so test after every change.
7. Third-party scripts
Marketing pixels, chat, review widgets, maps and embedded videos add request after request. Remove what you do not use, load the rest only when needed (for example a map, after a click) and tie pixels to consent, so they do not load before the visitor agrees. How to do that connection correctly is described in the guide on Consent Mode v2.
8. The database, WP-Cron and the final details
At the end, deal with the database: accumulated post revisions, expired transients and a large amount of autoloaded options, which are read on every request. WP-Cron, the mechanism that runs scheduled tasks, is triggered by visits by default; on a site with traffic, it is more stable to move it to a real server cron. Also reduce the frequency of Heartbeat requests from the admin if they load the server. These are small optimisations compared with the ones above, but they matter on large sites.
What does not help
- A score of 100 on a synthetic test. Users do not buy the score, they buy the page.
- An all-in-one plugin installed without measuring. It can fix two things and break five others.
- Aggressive minification without tests. It breaks forms, sliders and menus.
- Optimising images on a slow server. If TTFB is several seconds, images are not the first problem.
A 30-day plan
| Week | What you do | What you measure |
|---|---|---|
| 1 | Measure on real data, check hosting and the PHP version | TTFB, LCP, the Search Console report |
| 2 | Enable page and browser caching | TTFB, load time |
| 3 | Optimise images and clean up plugins | LCP, page weight |
| 4 | Defer scripts, handle fonts, clean the database | INP, CLS, the Search Console report |
After each step, wait for new data to accumulate: real data updates with a delay, because it is calculated over a window of a few weeks.
Frequently asked questions
Why is my WordPress site slow?
Usually because of one or more causes: weak or overcrowded hosting, no page caching, large images, too many plugins or a heavy theme. Measure first to find out which one it is.
What is the best caching plugin for WordPress?
There is no universal one. Choose a single page caching mechanism suited to your hosting and test it on staging. Do not use two caching plugins at the same time.
How many plugins are too many?
The number does not matter, what each one loads does. Use Query Monitor to see which are the slowest and deactivate what you do not use.
Do I need a score of 100 in PageSpeed?
No. The score is a lab indicator. Real data from users and actual load times matter more.
How long until improvements show up in Google?
Real data in Search Console updates with a delay, over a window of a few weeks. The effect on users is immediate, in your own measurements.
If you want a speed audit of your site, with priorities and estimates, or a WordPress maintenance plan that keeps your site fast and up to date, write to us.
