WordPress9 min read

Why your WordPress site is slow (and what actually fixes it)

You installed a caching plugin. Maybe two. The score in PageSpeed Insights went up by six points and your site still feels slow on a phone. This is the most common situation we get contacted about, and the reason it happens is that caching plugins fix the one problem most WordPress sites do not have.

Caching stops the server rebuilding the same page on every request. That is genuinely useful, and it is the last 20% of the problem. The other 80% is what the browser has to download, parse and execute before anything appears on screen — and no caching plugin can reduce that, because it is baked into your theme and your plugin stack.

This guide walks through the four things that are actually slowing the site down, in the order they usually matter, and how to check each one yourself.

First, measure the right thing

The PageSpeed Insights score is a weighted composite and it is not what Google ranks on. What Google actually uses is Core Web Vitals, measured on real Chrome users visiting your site — the Chrome User Experience Report, shown in the top half of the PageSpeed Insights page as 'Discover what your real users are experiencing'. If that section says you have insufficient data, your site does not get enough traffic to be measured, and the lab score below is a simulation.

There are three thresholds and they are the numbers to care about:

  • Largest Contentful Paint (LCP) — under 2.5 seconds. How long until the biggest thing on screen appears. This is the one most WordPress sites fail.
  • Interaction to Next Paint (INP) — under 200 milliseconds. How long the page takes to respond when someone taps. This replaced First Input Delay in March 2024.
  • Cumulative Layout Shift (CLS) — under 0.1. How much the page jumps around while loading.

Run the test on mobile, not desktop, and run it on a real page — a product or service page, not the homepage, which is usually the most optimised page on the site and the least representative.

Cause 1: plugin count (the big one)

Every active plugin can add CSS and JavaScript to every page, whether or not that page uses the plugin. A contact form plugin typically loads its stylesheet and its script on your blog posts. A slider plugin loads on pages with no slider. A page builder loads its entire runtime everywhere.

The usual WordPress site we are asked to look at has somewhere between 25 and 45 active plugins. The realistic floor for a business site is closer to eight. Each one is not just weight — it is another thing that can conflict, another thing that needs updating, and another author who can abandon it.

To check what your plugins actually cost: open Chrome DevTools, go to the Network tab, filter by JS, and reload. Sort by size. If you see more than about 300KB of JavaScript on a page that is mostly text, plugins are your problem, and the individual filenames will tell you exactly which ones.

A page builder — Elementor, Divi, WPBakery — is usually the single heaviest thing on a WordPress site. It is also the hardest to remove, because the page content is stored in its own format. This is worth knowing before you install one, and it is the main reason a rebuild is often cheaper than an optimisation.

Cause 2: render-blocking CSS and JavaScript

When the browser hits a stylesheet or a synchronous script in the head, it stops rendering until that file is downloaded and processed. A typical WordPress page has fifteen to thirty of these. On a fast connection that is invisible. On a mid-range Android on a mobile network in Hyderabad or on rural US broadband, each one is a round trip, and they add up to seconds.

Optimisation plugins try to fix this by combining and deferring files. It works about half the time. The other half it breaks your layout or your forms, because deferring a script that another script depends on changes the execution order. This is why 'I turned on optimisation and the site broke' is such a common experience — the plugin cannot know your dependency graph, so it guesses.

Cause 3: images

This is the most fixable one and it is still wrong on most sites. The three questions:

  • Format. Are they WebP or AVIF, or still JPEG and PNG? WebP is typically 25–35% smaller than an equivalent JPEG.
  • Dimensions. Is a 3000px-wide photo being displayed in a 600px slot? The browser downloads all 3000 pixels regardless.
  • Loading. Is anything below the fold loading lazily? And critically — is your hero image loading lazily by mistake? Lazy-loading the LCP element is a very common own-goal that directly worsens the metric it was meant to help.

Cause 4: hosting and TTFB

Time To First Byte is how long the server takes to start responding. On shared hosting — the ₹200/month or $5/month plans — you are sharing CPU with hundreds of other sites, and a TTFB of 800ms to 2 seconds is normal. Everything else on the page starts after that. You cannot optimise your way out of it from inside WordPress.

The other half of this is geography. If your customers are in Hyderabad and your server is in the US, every request crosses an ocean twice. If your customers are in Texas and your server is in Mumbai, the same. A CDN helps with static assets but not with the initial HTML on a dynamic WordPress site.

So: optimise, or rebuild?

Honest answer, and it depends on one thing — how much of the weight is structural.

Optimise if the site is on a reasonable theme, has under about fifteen plugins, and no page builder. In that case you are looking at image work, hosting, and careful script handling, and you can usually get to passing Core Web Vitals without rebuilding. This is real work, but it is a few days, not a project.

Rebuild if there is a page builder, thirty-plus plugins, or a theme you bought from a marketplace with a demo importer. In these cases the weight is the architecture. You can spend weeks fighting it and land at 'acceptable', or spend comparable money on a build that starts fast and stays fast because there is nothing extra in it.

We give this answer for free, including when the answer is 'do not rebuild'. Sending someone a proposal for a rebuild their site does not need is a good way to get one project and no referrals.

Common questions

Will a caching plugin fix my slow WordPress site?

Partly. Caching reduces server processing time, which improves Time To First Byte. It does nothing about the CSS and JavaScript your theme and plugins send to the browser, which is where most of the delay is on a typical WordPress site. If you installed caching and saw a small improvement, that is the expected result, not a sign you configured it wrong.

How many plugins is too many?

There is no hard number, because a well-written plugin that loads nothing on the front end costs nothing. In practice, most business sites can run on eight to twelve, and most of the ones we see are running thirty-plus. The better question is how much CSS and JavaScript reaches the browser: under 300KB of JavaScript on a content page is reasonable, and over 1MB means something is badly wrong.

Does site speed actually affect Google rankings?

Core Web Vitals are a confirmed ranking signal, but a weak one compared to relevance and links — a fast page about the wrong thing will not outrank a slow page about the right thing. Where speed matters enormously is conversion: people leave slow pages, and that happens whether or not Google is counting.

Is Next.js actually faster than WordPress?

Not inherently — a badly built Next.js site can be slow too. The difference is the default. A Next.js site ships only the JavaScript that page needs and can serve pre-rendered HTML from a CDN edge near the user, so a fast result is the starting point rather than something you fight for. WordPress can be made fast, but you are removing weight rather than never adding it.

Want us to look at your site?

We will tell you whether the problem is hosting, plugins, architecture or something else entirely — including when the answer is that you should not rebuild and should spend the money on traffic instead. No charge for the assessment.

Run the free audit tool

Pricing: US clients (USD) · India clients (INR)

Related guides

All 21 guides