How to Speed Up a Slow WordPress Site

Installing a caching plugin is the first thing most people do and the least useful. Caching helps the returning visitor. The first-time visitor who found you on Google — the one who matters — still waits, because their request was never cached.

Fix the causes in this order.

Measure with field data first

A lab score from a testing tool on a fast connection tells you very little. Look at field data — real users, real devices, real networks — in Search Console or the Chrome UX report. Optimise for what people actually experience, not for a number you can improve by testing at a quieter time of day.

1. Images, almost always

• Serve modern formats rather than the JPEG the client emailed
• Resize to the dimensions actually displayed, not 4000px scaled down in CSS
• Set explicit width and height so the layout stops jumping
• Lazy-load anything below the fold, and never lazy-load the hero
• Give the largest above-the-fold image high fetch priority

This is usually the largest single win and the least glamorous. A homepage carrying eight megabytes of unoptimised photography cannot be rescued by any plugin.

2. The plugin audit

Open the plugin list and justify each one out loud. Most sites carry two or three plugins loading their CSS and JavaScript on every page to power a feature used on one. Deactivate, measure, decide.

Plugins that consistently cost more than they return: page builders on simple sites, sliders, multi-purpose “optimisation” suites that conflict with each other, and social feed widgets pulling from a third-party API on render.

3. Render-blocking assets

• Defer JavaScript that is not needed for first paint
• Inline the small amount of CSS the top of the page needs
• Load fonts without blocking render, and preconnect to the font host
• Remove CSS and JS loading on pages that never use the feature

4. Third-party scripts

Chat widgets, heatmaps, ad pixels, analytics variants. Each one is a request to someone else’s server that you cannot control, and several of them block rendering while they resolve.

List every third-party script and put a value against it. Most sites find at least one that nobody has looked at in a year.

5. Hosting and caching, last

Now caching helps, because it is caching something already lean. Configure page caching, object caching where the host supports it, and a CDN for static assets.

If server response time is still slow after all of the above, the host is the problem. Cheap shared hosting with an oversubscribed server cannot be optimised around — that is a migration, not a tuning exercise.

What good looks like

Largest Contentful Paint under two and a half seconds, Interaction to Next Paint under two hundred milliseconds, Cumulative Layout Shift under 0.1 — measured on mobile, on field data. Hit those and stop. Chasing a perfect lab score past that point is effort better spent elsewhere.