Web Dev · 7 min read · 5 Jun 2026
Why your WordPress site is slow (and why WP Rocket didn't fix it)
You installed a caching plugin, enabled all the settings, and your PageSpeed score barely moved. What's actually making your WordPress site slow, and what to do about it.
On this page
- Caching doesn't fix structural problems
- The five things actually making your site slow
- 1. Unoptimised images — the #1 offender
- 2. Page builder bloat
- 3. Too many plugins loading frontend scripts
- 4. No CDN, or CDN misconfigured
- 5. Cheap hosting that throttles under load
- The PageSpeed score that actually matters
- What a proper WordPress speed optimisation actually looks like
- If WP Rocket didn't fix your site
Short answer: WP Rocket didn’t fix your slow WordPress site because caching only serves already-built pages faster. It can’t shrink 3MB images, strip unused page-builder CSS, silence 40 plugins injecting scripts, or upgrade cheap hosting, and those structural problems are what keep mobile scores under 50. The fix is usually 6–10 hours of focused work on images and the CDN, render-blocking scripts, page-builder bloat and hosting that matches your traffic. After that, caching finally pays off.
You search “how to speed up WordPress,” and every article says the same thing: install WP Rocket (or LiteSpeed Cache, or W3 Total Cache), enable minification, turn on lazy loading, done.
You do all of that and run PageSpeed Insights again. The score goes from 38 to 44.
What?
You’re not alone. WordPress site owners bring me this frustration more than any other, and the caching plugin isn’t at fault. For most slow sites, caching plugins fix a bottleneck that was never the main one.
That face when you’ve tried every “speed optimisation” tip and your PageSpeed score hasn’t moved.
Caching doesn’t fix structural problems
Think of a caching plugin as a faster waiter in a slow kitchen. The food still takes 20 minutes to cook. You’re only serving already cooked food faster to returning customers.
Caching helps when:
- Your server is slow to generate pages (TTFB)
- You have repeat visitors who benefit from browser cache
- You serve the same pages to many visitors
Caching does not help when:
- Your images are 3MB each and served without a CDN
- Your theme loads 14 JavaScript files in the
<head> - Your page builder adds 400KB of unused CSS to every page
- You have 40 plugins and half of them inject scripts on the frontend
Those are structural problems, and no plugin setting will toggle them away.
The five things actually making your site slow
1. Unoptimised images — the #1 offender
I’ve audited a lot of WordPress sites, and in most of them images were the main performance bottleneck, ahead of server speed and PHP version.
The pattern:
- A 4000×3000px photo uploaded directly from a phone
- Served as a full-resolution JPEG (2–5MB per image)
- No WebP conversion
- No responsive
srcsetattributes - Hero image loads before anything else, blocking LCP
What to actually do:
- Resize before upload (max 1600px wide for full-width images)
- Use WebP format (ShortPixel or Imagify handles this automatically)
- Serve through a CDN (Cloudflare free tier is enough for most sites)
- Add
loading="lazy"to images below the fold (but NOT the hero image, which you want to load fast)
That alone can cut 2–4 seconds off your load time.
2. Page builder bloat
Elementor, Divi and WPBakery make building easy and performance terrible.
A page builder generates CSS and JavaScript for every possible widget, even if your page uses only three of them. A typical Elementor page loads 300–500KB of CSS. A hand-coded page with the identical design loads about 30KB.
The honest options:
- If you’re keeping the page builder: use its built-in “Improved Asset Loading” (Elementor has this now), disable unused widgets, and accept that your floor is ~60 on PageSpeed mobile
- If you want 90+: rebuild with a lightweight theme (GeneratePress, Kadence) or go headless
- If you’re building new: skip page builders entirely
I know nobody wants to hear this, but I’ve never seen a Divi site score 95 on mobile in the wild.
3. Too many plugins loading frontend scripts
Your SEO plugin, analytics, chat widget, popup builder, social sharing buttons, cookie consent, reCAPTCHA, Hotjar, Facebook Pixel and Google Tag Manager each add JavaScript that the browser has to download, parse and execute.
A real audit I ran last month:
| Plugin | JS loaded | Actually needed on every page? |
|---|---|---|
| Elementor | 180KB | Yes (if using the builder) |
| MonsterInsights | 95KB | No — use GA4 direct |
| tawk.to chat | 310KB | No — load on contact page only |
| WP Forms | 85KB | No — load on pages with forms only |
| Social Warfare | 120KB | No — load on blog posts only |
| AddToAny | 75KB | No — load on blog posts only |
| Cookie consent plugin | 45KB | Maybe — but 45KB for a banner? |
Total: 910KB of JavaScript on the homepage, of which 650KB was unnecessary.
What to do:
- Audit every plugin’s frontend footprint (check View Source, look for
<script>tags) - Remove plugins you don’t actively use
- Use conditional loading (Asset CleanUp or Perfmatters) to keep scripts off pages that don’t need them
- Replace bloated plugins with lightweight alternatives or direct code snippets
4. No CDN, or CDN misconfigured
Your hosting server is in Singapore and your customer is in Mumbai, so every request travels 5,000 km and back. A CDN puts copies of your files on servers in Mumbai (and 200+ other cities).
Cloudflare’s free plan does this, and it takes 15 minutes to set up. Even so, roughly half the WordPress sites I audit don’t use one.
Common CDN mistakes:
- CDN enabled but not caching static assets (check headers:
cf-cache-statusshould say HIT) - CDN caching HTML pages when it shouldn’t (breaks logged-in users, WooCommerce carts)
- CDN configured but images still served from the origin domain
5. Cheap hosting that throttles under load
Shared hosting at ₹99/month means your site shares resources with hundreds of others, and when any of them spike, yours slows down. Your TTFB (Time to First Byte, the time before the browser receives any data) can be 800ms–2 seconds on cheap shared hosting.
A proper WordPress host (Cloudways, RunCloud on DigitalOcean, or even a ₹500/month VPS) brings TTFB under 200ms. No plugin can give you that 1–1.5 second improvement.
Real WordPress speed work happens in the code and server config. Plugin settings panels won’t get you there.
The PageSpeed score that actually matters
Most people obsess over the overall score. For rankings, Google looks at three metrics:
- LCP (Largest Contentful Paint): when the main content becomes visible. Target: under 2.5s
- INP (Interaction to Next Paint): how fast the site responds to clicks. Target: under 200ms
- CLS (Cumulative Layout Shift): how much the page jumps around while loading. Target: under 0.1
You can score 50 overall and still pass all three Core Web Vitals, which is fine for SEO. You can also score 85 and fail LCP, which is worse for rankings.
So watch those three metrics more than the headline number.
What a proper WordPress speed optimisation actually looks like
This is the process I follow for clients:
- Audit: run PageSpeed, GTMetrix and WebPageTest. Find the top 3 bottlenecks by actual time impact, ignoring the score suggestions
- Images: compress, convert to WebP, add responsive sizes, lazy load below-fold images
- Script audit: map every JS and CSS file loading on the frontend. Remove or defer anything that isn’t critical
- Server: check hosting and PHP version (8.1+ minimum), enable OPcache, configure proper caching headers
- CDN: set up Cloudflare and verify caching is actually working
- Measure again: test from Mumbai on a throttled 4G connection instead of your office Wi-Fi
The typical result: PageSpeed mobile goes from 30–45 to 75–90, and LCP drops from 4+ seconds to under 2. The site feels fast, and that’s what moves conversions.
If WP Rocket didn’t fix your site
WP Rocket is a good plugin, but it won’t fix everything. If your site is structurally slow, with oversized images, a bloated page builder, 40 plugins injecting scripts or cheap hosting, no caching layer will save it.
The fix is usually 6–10 hours of focused work by someone who understands WordPress internals and web performance. Another plugin install won’t do it, and neither will a Fiverr “speed optimisation” package that runs the same automated tools you already tried.
If your site scores below 50 on mobile and you’ve already tried a caching plugin, stop collecting plugin recommendations and find a developer who can read a waterfall chart.
I do this work on WordPress projects: a performance diagnostic first, then a fixed quote for the fixes, with before/after PageSpeed numbers in the handoff report. If your site is slow because it’s infected and not just bloated, start with the cleaning service instead.
- #wordpress
- #page-speed
- #core-web-vitals
- #performance
- #web-dev





