WordPress Speed Optimization: From 6 Seconds to Under 2
Most slow WordPress sites are slow for two or three specific reasons. Here is how to find which ones, in the order that gives you the biggest drop in load time for the least work.
A client sends the same message every few months: the site takes forever to load. They have usually already installed three caching plugins, which is part of the problem.
Slow WordPress sites are almost never slow for mysterious reasons. In the 50+ sites I have built and inherited, the cause is nearly always one of five things, and they are not equally expensive to fix. This is the order I work in, because the first two usually account for most of the improvement.
First: measure the right thing
Before changing anything, get two numbers. Both are free.
- PageSpeed Insights, gives you Core Web Vitals: LCP (how long until the main content appears), INP (how fast the page responds to a click), CLS (how much the layout jumps).
- Time to First Byte, from any speed checker, how long the server takes to send the first byte back.
That split matters. High TTFB is a server or database problem and no image optimisation will fix it. Low TTFB but slow LCP is a front-end problem: images, fonts, render-blocking scripts. Fixing the wrong half is the most common wasted afternoon in WordPress work.
1. Hosting, the fix nobody wants to hear
If TTFB is above roughly 600ms consistently, the host is the bottleneck and everything else is decoration. Cheap shared hosting puts hundreds of sites on one machine; when a neighbour gets traffic, your site slows down and no plugin can help.
Signs it is the host: TTFB varies wildly between tests, the admin panel is slow even with all plugins disabled, and the site is fine at 3am. Moving to decent hosting frequently takes more off the load time than every other item on this list combined.
2. Images, usually the largest single win
The single most common cause of slow WordPress pages is a 4000-pixel-wide photo displayed in a 600-pixel-wide slot. The browser downloads all of it.
- Resize before upload. If the largest display size is 1200px, do not upload 4000px.
- Serve WebP or AVIF. Typically 25, 40% smaller than JPEG at the same visible quality.
- Lazy-load anything below the fold, WordPress does this by default now, but themes sometimes break it.
- Never lazy-load the hero image. It is your LCP element; delaying it directly worsens your worst metric.
- Set width and height attributes so the browser reserves space. This is what fixes CLS.
3. Plugins, count them, then read them
Plugin count matters less than what each one loads. One badly built slider that injects jQuery UI and three stylesheets on every page hurts more than fifteen well-behaved plugins.
Use Query Monitor to see what each plugin actually costs in queries and load time. Then be ruthless: deactivate, measure, and delete rather than leave deactivated. A deactivated plugin still sits on the server as an attack surface, I cover this in the WordPress security checklist.
The frequent offenders: page builders loading their full asset bundle sitewide, contact form scripts on pages with no form, social sharing widgets calling external APIs, and analytics loaded three separate times because three plugins each added it.
4. Caching, one plugin, configured once
Caching is genuinely effective and genuinely easy to get wrong. The rules are short:
- Use exactly one caching plugin. Two will conflict and produce bugs that look random.
- Enable page caching first and measure before touching anything else.
- Minification and file combining help, but break things often enough that you should test every template afterwards.
- Exclude the cart, checkout and any logged-in view. Cached carts are how customers see somebody else's order.
- Turn on a CDN if your visitors are not near your server. If your audience is entirely in Baku and the server is in Europe, the gain is small.
5. The database, once a year
WordPress accumulates post revisions, expired transients, orphaned metadata and spam comments. On a site that has run for a few years this can be most of the database. Clean it, then set a revision limit in wp-config.php so it does not grow back.
Take a backup first. This is the one item on the list that can lose data.
What good looks like
- TTFB under 400ms
- LCP under 2.5 seconds on mobile, on a real 4G connection rather than your office wifi
- CLS under 0.1
- INP under 200ms
- Total page weight under about 1.5MB for a content page
Test on mobile. Google indexes mobile-first, and a site that scores 95 on desktop and 40 on mobile is a slow site as far as search is concerned.
The mistake I see most
Installing an optimisation plugin, enabling every toggle it offers, and never measuring. Half the toggles do nothing on that site, two of them break the layout on mobile, and nobody notices for a month because nobody looked at the site on a phone.
Change one thing. Measure. Keep it or revert it. It is slower to work this way and it is the only method that reliably ends with a fast site.
Related
Lock the site down while you are in there: WordPress security checklist. Or see WordPress development and SEO and recent projects.
More posts
AI can draft your test cases in seconds. Whether those cases find anything is a different question. What a year of using AI tools inside a real QA job actually changed.
AI writes the code in seconds. Someone still has to find out whether it works. A QA engineer’s view of what vibe coding actually costs, and how to use AI tools without shipping their mistakes.
Ten UX/UI trends worth knowing, sorted by whether they change what you actually build or just what design blogs look like this year.
A working checklist for hardening a WordPress site, logins, files, database, hosting and monitoring, written from what actually breaks on sites in production.
AI can lay out a screen, read behaviour data and run usability checks. It cannot decide what the product should be. A practical look at where the line sits.