Skip to content
Shezad Ali Khan

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.

Shezad Ali Khan Shezad Ali Khan Trainer and SEO consultant, Mumbai

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.

Person frustrated at a laptop screen after seeing poor PageSpeed results 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 srcset attributes
  • 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-status should 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.

Code on a screen, the technical work behind a faster WordPress site 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:

  1. Audit: run PageSpeed, GTMetrix and WebPageTest. Find the top 3 bottlenecks by actual time impact, ignoring the score suggestions
  2. Images: compress, convert to WebP, add responsive sizes, lazy load below-fold images
  3. Script audit: map every JS and CSS file loading on the frontend. Remove or defer anything that isn’t critical
  4. Server: check hosting and PHP version (8.1+ minimum), enable OPcache, configure proper caching headers
  5. CDN: set up Cloudflare and verify caching is actually working
  6. 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

Learn with me

Small batches in Jogeshwari, taught by me in every session.

Practical AI training Next batch Tue 17 Nov · AI Practitioner 7 seats per batch · one batch a day

Don’t just learn AI. Build with it.

Use AI · Work with AI · Build with AI. Three steps. Each course builds on the last. Hands-on, in person in Jogeshwari (W), Mumbai.

  1. Step 1 · Use AI AI Practitioner 24 h · ₹7,999
  2. Step 2 · Work with AI AI Professional 36 h · ₹14,999
  3. Step 3 · Build with AI AI Builder 48 h · ₹24,999

Also: the AI Digital Marketing track, from ₹9,999. Compare both

Cover of the Practical AI prospectus Prospectus · 16 pages · PDF, Practical AI prospectus, 2.4 MB
WhatsApp Call