Most “speed up WordPress” advice hands you a pile of plugins and wishes you luck. That is how sites end up slower, not faster. The reliable way is a loop: measure a baseline, fix the biggest bottleneck, re-measure — and stop when the numbers say you are done.
When someone asks how to make a WordPress site faster, the honest answer starts with a question of its own: faster than what? Without a baseline you are guessing, and guessing is how people install five caching plugins that fight each other. The method below is boring and it works: audit, fix by impact, verify. Everything else is detail.
Two tools, mobile first. Save the score + Core Web Vitals. This is what every later fix is measured against.
The ceiling no plugin can lift. If TTFB is high, fix the server before anything else.
Usually the biggest single win. Resize, compress, WebP, lazy-load. Video off- site, never uploaded.
One caching plugin, never several. Add a CDN. The multiplier once hosting and images are handled.
Trim plugins, defer JS, clean the database, host fonts. Re-test vs baseline; undo what didn't help. Loop.
Table of Contents
Audit before you optimize
The audit is the foundation of all WordPress speed optimization: it tells you what is slow, what to fix first, and later whether your fixes worked. Skip it and you optimize blind.
Run your site through two tools, not one, because results fluctuate:
- Google PageSpeed Insights — the official Core Web Vitals view, mobile and desktop separately.
- GTmetrix or WebPageTest — a request-by-request waterfall that shows which files are slow.
Test each a few times and save the report — that saved result is your baseline. For the full toolkit, see our free web-performance and media tools. Two rules keep an audit honest: test mobile first (Google indexes mobile, and mobile scores are always lower), and do not chase 100/100 — real load time and user experience matter more than a round number.
Our own baseline, before any caching
We ran this audit on bosonica.in itself before launch: four representative pages, PageSpeed Insights on mobile and desktop, plus five plain timed requests for the time to first byte. No page cache was running yet, so this is the honest “before”.
| Page | Mobile score | Mobile LCP | Desktop score | Desktop LCP | Time to first byte (median of 5) |
|---|---|---|---|---|---|
| Homepage | 69 | 4.5 s | 86 | 1.45 s | 2.1 s |
| This speed guide | 63 | 6.3 s | 87 | 1.43 s | 1.9 s |
| An article with screenshots | 61 | 7.2 s | 85 | 1.37 s | 1.7 s |
| Contact page | 68 | 4.5 s | 92 | 0.89 s | 1.6 s |
What it told us, in the order this guide recommends:
- The server is the first ceiling. Every page took 1.6 to 2.1 seconds before the first byte arrived, because nothing was cached: each visit built the page from scratch. That’s the job of page caching, so caching comes first.
- Mobile is where it hurts. Desktop is fine (85 to 92); on emulated mobile the main image shows up in 4.5 to 7.2 seconds, slowest on the pages with screenshots.
- Layout shift is already near zero, so CLS isn’t where the effort goes.
Two things we learned about measuring. Running Lighthouse on our own machine failed with a 403, because our CDN’s bot protection blocked the automated browser, while Google’s PageSpeed Insights worked normally; if your local runs fail, try PSI before you debug the site. And PSI reuses a recent result for the same URL, so three back-to-back runs can come back identical; space your repeats out. We’ll add the after-caching numbers to this table as each step lands.
Understand Core Web Vitals
Google’s three Core Web Vitals are the metrics your audit is really measuring, and the ones optimization should target:
- Largest Contentful Paint (LCP) — how fast the main content appears. Aim for ≤2.5s.
- Interaction to Next Paint (INP) — how quickly the page responds to input. Aim for ≤200ms.
- Cumulative Layout Shift (CLS) — how much the layout jumps as it loads. Aim for ≤0.1.
If any fails, the fixes below target it directly: LCP is usually hosting and images, INP is usually JavaScript, CLS is usually theme layout and un-sized media.
Optimize the metric that’s failing, not the score you wish you had. The Vitals tell you where to look.
Start with hosting — it sets your ceiling
No plugin can outrun a slow server. Time to First Byte (TTFB) — how long the server takes to send the first byte — should sit under ~200ms; if the waterfall shows it consistently high, that is your ceiling and the first thing to fix. A better host, or moving from crowded shared hosting to managed or cloud hosting with real CPU, does more than any optimization plugin. If you are choosing where to run, weigh it carefully — hosting is the one decision the rest of this list cannot undo.
Fix images — usually the biggest single win
Images are the number-one cause of a heavy WordPress page, so they are usually the fastest large win:
- Resize to the dimensions actually displayed — do not ship a 4000px image into a 800px slot.
- Compress with ShortPixel, Imagify or EWWW; most photos should land under ~200KB.
- Serve next-gen formats (WebP/AVIF) — most optimization plugins convert automatically.
- Lazy-load below-the-fold images and iframes so they load only when scrolled into view.
- Host video off-site (YouTube/Vimeo), never as a WordPress upload.
Turn on caching and a CDN
Caching stores ready-made copies so the server stops rebuilding every page, and a CDN serves them from close to the visitor. Together they are the biggest infrastructure win after hosting.
- Caching plugin — LiteSpeed Cache (free, if your host runs LiteSpeed), WP Rocket (premium), or W3 Total Cache. Enable page, browser, and object caching. Run one caching plugin, never several.
- CDN — Cloudflare, BunnyCDN or KeyCDN. Combined with caching, a CDN commonly cuts load time substantially.
Always clear the cache before you re-test, or you will measure a stale page. Caching also shapes where bot traffic hits you — see where to block bots across cache layers.
Hosting is the ceiling; images are the heaviest payload; caching is the multiplier. Fix those three first.
Trim the code: plugins, database, fonts
With the big rocks handled, clean up what is left:
- Plugins — use Query Monitor to find slow ones; replace heavy plugins with lean alternatives or a small code snippet instead of a plugin. Fewer active plugins is almost always faster.
- Code — minify and combine CSS/JS, defer non-critical scripts, and remove unused CSS with a tool like Perfmatters or Asset CleanUp.
- Theme — disable unused features and demo content; a lean theme beats a feature-heavy one. See how to select a WordPress theme.
- Database — clear revisions, transients and leftover tables; our guide to removing orphaned database tables covers the safe way.
- Fonts — host Google Fonts locally, limit to one or two families, and preload the critical face.
Go advanced: PHP, HTTP/2-3, server-level
Once the basics are done, these give a final push:
- Upgrade PHP to the latest supported 8.x — often a 10–20% speed gain for free.
- Enable HTTP/2 or HTTP/3 (they multiplex requests) and Brotli compression; confirm with our modern web-protocol check.
- Server-level — LiteSpeed or Nginx, OPcache for PHP, and Redis or Memcached object caching on high-traffic sites.
- Tame the Heartbeat API and lazy-load embeds to cut background admin-ajax requests.
Verify against your baseline
This is the step people skip, and it is what turns optimization from superstition into engineering. Clear all caches, run the same two tools on mobile and desktop, and compare against the baseline you saved in step one. If a change did not move the numbers, undo it — every active plugin has a cost. Then put a monthly re-audit on the calendar, because plugin updates, new content and theme changes all erode speed over time.
If you can’t show the before-and-after, you didn’t optimize — you just changed things and hoped.
The short version
WordPress speed optimization is a loop, not a plugin haul. Audit first with two tools to get a baseline and find the real bottleneck. Fix in order of impact: hosting and TTFB set the ceiling, images are the heaviest payload, caching plus a CDN multiply the gains, then trim plugins, code, the database and fonts, and finish with PHP, HTTP/2-3 and server-level tuning. Verify by re-running the same tests against your baseline and undoing anything that didn’t help. Don’t chase 100/100, don’t run two caching plugins, and re-audit monthly so the speed you won doesn’t quietly leak away.
Frequently Asked Questions
Why run a speed audit before optimizing?
Because without a baseline you cannot tell what is slow or whether a fix helped. An audit shows the real bottleneck — often hosting or images — so you spend effort where it pays off instead of installing plugins at random and hoping.
What slows down a WordPress site the most?
Usually hosting (a high TTFB you cannot fix with plugins) and large, unoptimized images. Too many plugins, missing caching, render-blocking JavaScript, and a bloated database are the next most common causes.
Do I need a caching plugin and a CDN, or just one?
Both, and they do different jobs: caching stops your server rebuilding pages, while a CDN serves those pages from near the visitor. Use exactly one caching plugin — running several causes conflicts — and pair it with a CDN for the biggest infrastructure gain.
Is a perfect 100/100 PageSpeed score worth chasing?
No. Past a good score, the effort rarely improves real-world load time and can hurt the experience. Aim for healthy Core Web Vitals and fast actual loading; treat the score as a guide, not the goal.
How often should I re-check WordPress speed?
Monthly, and after any big change — a new plugin, a theme update, or a batch of new content. Speed erodes over time as a site grows, so a recurring re-audit against your baseline keeps the gains you worked for.
