Why is WordPress so slow?

Why is WordPress so slow? This is one of the most common search queries that starts with the words “why is WordPress…”. It’s a topic that a lot of people are affected by, and they’re searching for answers to help with their slow WordPress. This post aims to provide guidance covering what can make WordPress so slow, and also provide you with some actionable suggestions to improve the speed of your WordPress.

WordPress is an open platform. This means anyone can write plugins or themes for it. While this is part of what makes WordPress great, it’s also part of what can make it slow.

The main benefit of WordPress being an open platform is that a vast number of people contribute to it. This means there’s a massive variety of themes, which allows for a wide variety of visual customisations. It also means there’s an enormous range of plugins that can be used to gain additional functionality.

If you want to make your WordPress look like a squarespace website, there’s a theme for that! If you want to integrate a booking calendar or run a fantasy football league there are plugins for that.

WordPress’ open platform nature is what gives it this flexibility in appearance and customisation.

Let’s say you have a WordPress installation that’s made up of 12 plugins and some non-built in theme. That’s 14 different parties all contributing to your website’s code base.

Do you think these parties all talk to each other? Unfortunately they don’t.

Do you think these parties all take your website’s page output in to account? I probably wouldn’t be writing this if they did.

To give you a real world example of how installing plugins can affect page output, there’s a certain popular contact form plugin that a lot of people use. This plugin integrates it’s CSS on all your website’s pages, not just the one on which the contact form is placed.

LOOK AT ALL THIS FREE STUFF! LOOK AT WHAT IT CAN DO! I’LL HAVE THE BELLS! I’LL HAVE THE WHISTLES! I’ll also have a slow WordPress.

The more plugins you install, the more there’s going to be in your page output. Just as I’ve used the example of a contact form plugin adding CSS to all pages, there’s other plugins that add other things to page output that can make browser rendering slow.

Some themes use external google fonts, some page builders add lots of JavaScript to pages, some plugins hook themselves into everything, some plugins or the way you use your WordPress can result in lots of data being held in the site’s database. All of these types of things can make, or contribute to a slow WordPress.

There’s a very wide range of what can happen to make WordPress slow, simply due to the variety of plugins and themes, that all come from a variety of people. This means that you need to have a bit of a handle on how things work and what they do to avoid WordPress being slow.

Most people use WordPress to negate the need to code, and maybe so that they don’t have to know how things work, and that’s really the problem with WordPress, and what makes it slow.

Gaining a general understanding of how WordPress works will help you identify why your WordPress is slow. Once you know what’s causing WordPress to be slow, you’ll have an idea of the best course of action to improve your WordPress website’s performance.

1. A browser requests a WordPress website.
2. The request for the website is sent to the web server.
3. The web server loads WordPress from the site’s document root (where the WordPress installation exists).
4. WordPress executes and loads its core files, plugins, and theme.
5. WordPress obtains required content from the database (this involves a database server).
6. WordPress generates page output (based on database content, plugin and theme code).
7. The web server sends the finished page output back to the browser.
8. The browser renders the page content in to the page displayed in the browser.

If you don’t know what’s causing your WordPress installation to be slow, and try and cover everything at once, that’s quite a lot to cover!

What really helps when trying to work out what’s making WordPress slow, is to consider that the steps above can be categorised in to areas of “what might cause the slow”:

• The WordPress installation.
• The hosting server.
• The browser rendering page output.

It’s very easy to look at things from an “in WordPress” perspective, and try to do things in your WordPress back end to make it faster.

I can completely understand why people would take this course of action, as the back end is effectively the driving seat when it comes to WordPress. Unfortunately approaching things in this manner can make things worse.

In many cases, although not all, it’s the browser rendering the page output that’s generated by WordPress that’s casing the slow. This isn’t the WordPress application being slow, or the web hosting server being slow, and it’s not really the browser being slow. So what is it then?

The page output generated by WordPress can result in slow page load times.

I’m going to cover the hosting sever and WordPress installation first, as they aren’t as extensive to cover as page output.

A very quick way to gain some direction is to run your site through a Lighthouse based tool such as Page Speed Insights, GTmetrix or Debug Bear’s Page speed test. Do you see anything about the server being slow to respond?

Yes. Your WordPress is either slow because either:
WordPress is taking a long time to generate page output.
You have some kind of issue with your hosting.

No. It’s not your WordPress that’s slow, it’s that the page output generated by WordPress causes a delay in the browser displaying the page. Skip to the page output part by clicking here.

It’s very easy to think that a slow server response time is a hosting specific problem. This isn’t always the case though. The hosting server has to wait for WordPress to generate page output before it can respond to a request for a web page.

A slow server response time can, in some cases, be caused by a slow WordPress, when the hosting server is fine.

A very quick way to find out if it’s slow hosting or a slow WordPress would be to install a fresh copy of WordPress in a subdirectory or on a subdomain. If this fresh copy of WordPress isn’t slow, you’re probably not looking at hosting specific problem. You’re most likely looking at an “In WordPress” type problem that’s making things slow.

Skip to the “In WordPress” type problem part by clicking here.

There are exceptions to the above, and there is a strong relationship between the WordPress installation and the hosting. For example, you need to make sure that your hosting provides enough CPU to operate the amount of plugins you’re using, and you need to have enough RAM to handle database queries.

There are some sensible things to aim for on the hosting side of things:

• Opcache (this caches precompiled PHP in RAM).
• HTTP/3 (this makes encryption handshakes a bit quicker, and also reduces data transfer).
• Object caching (this caches commonly used parts of your site).
• Recent PHP versions.
• Litespeed web server (this is faster to spawn PHP processes than apache).

If you’re using shared hosting, the above is a good set of requirements, as all help WordPress run faster. If your hosting provider doesn’t provide the above, you do have the option of moving your website. One of the good things about WordPress is that it’s very portable and will run on most hosting.

If you decide that you don’t want to use shared hosting, and instead would like a dedicated server and resource set, using a managed VPS is an option. If you’re thinking of moving to a VPS the two main considerations are cost and administration/support.

Good shared hosting will be fine for most WordPress based websites. You might need a VPS if you’re running a high traffic blog with lots of posts, or if you’re running a busy online store that contains lots of products and historical invoices and orders.

You’ll usually be able to tell if you need to upgrade your hosting, or need a a VPS if:

• You see account resource limits being reached (there’s usually some kind of monitoring in this capacity).
• Your site periodically shows a 500 or 503 errors.
• Your site is slow sometimes, but not at others.
• Your site is consistently slow (maybe).

The reason the last point is a maybe, is because you can have a consistently slow WordPress and it not be a hosting specific problem.

Checking your hosting for resource monitoring and, if possible, checking historical usage is a good start. Usually this comes in the form of graphs, and if the line on the graph is always at the top, that tends to mean you need to upgrade.

It is usually possible to reach out to your hosting provider if you need help checking resource usage.

Many hosting providers will offer upgrades that provide more RAM and CPU resources.

Upgrades can be a quick win to address a hosting specific problem. Most providers offer in place upgrades (for shared hosting) and will help you move to a VPS.

Generally speaking getting better hosting is usually a case of paying money to gain more resources.

Upgrading doesn’t always guarantee and improvement in performance, so it’s usually a good idea to have either established that you’re reaching hosting account limits, or to rule out other causes of your site being slow before paying to upgrade.

It is possible to analyse this to work out what’s going on in your WordPress to make it slow…. Or you can disable all your plugins and see if things are still slow.

Enabling plugins one by one, then checking your site can help identify a problem being caused by a specific plugin.

Conversely if the problem you have is due to too many plugins being used, what you may see is your site becoming slightly slower as each plugin is enabled.

Some general plugin related advice that can help speed up your WordPress is:

• Don’t use an excessive amount of plugins.
• If you only periodically use a plugin (such as a migration plugin) remove it, then reinstall it when you need it.
• Don’t use plugins to do things that you can do without using a plugin (convert images to webp prior to upload, rather than using an image converter plugin, for example).
• Don’t use multiple plugins that perform the same function (using multiple caching plugins, for example).
• Try not to use multiple plugins to do things that can be covered using one plugin (you could use Litespeed cache for object caching, CSS and JS minify and combine, and image conversion, rather than using a plugin for each, for example).
• Don’t use multiple plugins that do the same thing. 4 caching plugins in the same WordPress installation are likely to make things slower rather then faster.

Generally speaking, keeping the number of plugins as low as you can is usually a good practice when using WordPress. A plugin’s code will still run when a page of your website is requested, even if that plugin is nothing to do with the page itself.

Although the above does sound counterintuitive, bear in mind that the entire WordPress application (including all plugins) runs as a whole upon a page load.

The Code Profiler plugin will give you a generalised breakdown of which plugins have a high time overhead.

The Query Monitor plugin gives a lot more in depth information about things like what’s generating a lot of queries, what’s generating long queries, outgoing HTTP calls and so on.

While both of the above can help identify plugins contributing to making WordPress slow, the only course of action you can really take is to remove the plugin in question.

Databases can become bloated with information that you don’t need.

WP Optimize and Litespeed cache both have facilities that can be used to clean databases of old data.

The Index WP MySQL For Speed plugin can be used to add performance keys to database tables (make sure you’ve taken a backup) that makes data retrieval faster.

If your site has a very large database, you might need to start using a VPS so that you can dedicate RAM to the database server itself, to improve database performance.

There’s lots of different types of caching, and there’s lots of caching plugins, and there’s lots of different things these caching plugins can do.

The two types of caching that you’ll gain benefit from that affects your WordPress as a whole which are opcache and object caching.

Opcache speeds up PHP (and your whole WordPress uses PHP) by storing precompiled PHP in RAM. This means that the overhead associated with compiling PHP on the fly as and when it’s run is partially negated. Opcache needs to be available server side for you to make use of this (you can check using a phpinfo), if this is present server side, it’s used by default.

Object caching in WordPress stores database query results and processed data in memory, reducing the need to query the database repeatedly. This speeds up page loads, especially for dynamic sites like e-commerce stores and membership sites. Again you need to make use of this by using a plugin to bring object caching in to effect.

There are a lot of plugins that you can use to bring object caching in to effect. Object caching options/config is often available caching plugins (although it does need to be configured on many cases). Both the litespeed cache plugin and W3 total cache offer object caching options, plus more (and it’s a good idea to use one plugin to do many things, rather than many plugins to do many things) so both are good options for overall improvement.

The litespeed cache plugin can also be used to cache wp-admin, so it can speed up your site’s back end as well as the front end.

The main thread of a browser is single-threaded. This means it can only execute one task at a time, such as:

• Parsing HTML
• Applying CSS
• Running JavaScript
• Rendering the page (layout + paint)

So, if the browser is busy running JavaScript, it can’t do anything else (like rendering the page) until that task is complete.

A browser renders a web page in three stages, using the HTML, CSS and JavaScript (JS) that the web server has served.

The browser initially reads the HTML of the page output and uses this to construct the DOM (Document Object Model). The DOM is a bit like a basic map of the page. A raw unstyled, static version of the page.

The browser then uses the CSS (mostly styling information) to create the CSSOM (CSS Object Model). The CSSOM is then applied to the DOM.

Just as a child colours in a black and white picture, the CSSOM brings colour and style to the DOM. At this point an initial “draw” of the page takes place. This is when you begin to see things in the browser. The proper name for this is the First Contentful Paint (FCP), as it’s the first time page content is painted.

JavaScript runs next. JavaScript may change the page (to suit the screen size of the device, for example) or add interactive features (such as the mobile menu trigger, or mouse over effects). The browser runs this code, then update what’s been displayed as the FCP.

The main part of the page (like a large image or main heading) then becomes visible. This called is the Largest Contentful Paint (LCP), as it’s the largest part of the displayed part of the page. A this point the page is almost fully loaded.

JavaScript is still loading, running while FCP takes place. This can do things like add features, such as buttons or pop ups. it can also do things like set up event listeners, which listen for, and respond to user interaction. Background images, icons, or custom fonts might then also load a bit later. Once this last phase is done the page then becomes fully loaded and interactive.

The time it takes from initial request to the end of the process above is called TTI (time to interactive).

I’ve written the above as a nice step, by step, by step process. The problem is, that this doesn’t always happen in such a nice step by step by step way… and that’s what causes delays in page load times.

Render blocking CSS is an example of how page output causes a delay is introduced to the rendering process. If page output looks like this:

<!DOCTYPE html>
<html>
<head>
  <title>Render Blocking CSS Example</title>
  <!-- This CSS file is render-blocking -->
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <h1>Hello, world!</h1>
  <p>This content won't appear until the CSS is loaded.</p>
</body>
</html>

Because

<link rel="stylesheet" href="styles.css">

is in the

<head>

The browser stops rendering the page until it downloads and processes styles.css. This blocks the page from being shown to the user, even if the HTML is ready.

What’s being blocked in the example above is FCP, because FCP doesn’t take place until the CSS is loaded and applied.

To avoid render-blocking CSS, the CSS needed to carry out the initial draw of the page (known as the First Contentful Paint, or FCP) should be included directly within the HTML.

CSS included this way is called inlined CSS. Because it’s already in the HTML, the browser doesn’t need to download a separate CSS file before rendering the content, which helps eliminate delays and improves page load speed.

An example of inlined CSS looks like this:

<!DOCTYPE html>
<html>
<head>
  <title>Inline CSS Example</title>
  <!-- Inline CSS to avoid render-blocking -->
  <style>
    body {
      font-family: sans-serif;
      background-color: #f9f9f9;
      padding: 20px;
    }
    h1 {
      color: #333;
    }
    p {
      color: #666;
    }
  </style>
</head>
<body>
  <h1>Hello, world!</h1>
  <p>This content can appear right away because the CSS is inline.</p>
</body>
</html>

This is why the de facto CSS advice is:
Inline critical CSS and defer non-critical assets.

What this means in human terms is:
Include what’s needed for the initial draw (FCP) within the HTML to avoid delays. The CSS that isn’t needed for the initial draw can be obtained later (after FCP).

The main thing to bear in mind about JavaScript is that this is code run within the browser. The main thread is where the browser does most of its work:

• Parsing HTML
• Applying CSS
• Running JavaScript
• Rendering the page (layout + paint)

Only one task runs at a time, so if JavaScript is running, the browser can’t do anything else until it’s done.

If a large

<script> 

Is in the

<head>

without async or defer, the browser must stop parsing HTML to download this JS, then and run the JS before it can continue rendering HTML. This results in a delay in rendering.

If a JS script runs complex code (such as animations, calculations, or DOM manipulation), it keeps the main thread busy, which means:

• The browser can’t paint anything to the screen yet.
• FCP is delayed, even if the HTML and CSS are ready.

Third-party code is any script or resource loaded from outside your website, such as:

• Analytics tools (e.g. Google Analytics)
• Ads (e.g. Google AdSense)
• Social media widgets (e.g. Facebook, Twitter)
• Googel fonts
• Video players (e.g. YouTube embeds)

These can cause delays in page loading by being prioritised (i.e. in the of the HTML, without defer or async attributes). This is because the browser has to take time fetching this external asset, and while it does this, rendering stops.

You could be running and amazing code based on the most powerful server in the world, but if your page output includes some of what I’ve mentioned above, your page load time will still be poor.

The key point here is that this isn’t WordPress being slow, it’s the page output WordPress generates that causes delays in page load times.

Lighthouse is your friend here. Lighthouse is an open-source tool developed by Google to help developers audit and improve the performance and quality of their websites. It provides detailed reports on various aspects of a web page’s performance, accessibility, SEO, and more.

A lot of tools are based on Lighthouse, such as Page Speed Insights, Debug Bear’s Page Speed Test and GTMetrix.

It’s really the performance aspect of Lighthouse that’s the most relevant when it comes to page output.

With the possible exception of the server response time, the opportunities flagged by lighthouse based tools are what’s causing delays in browser rendering and therefore slow page load times.

Thinking about this as a single action doesn’t always help. Lighthouse based tools can report a variety of problems, and in many cases, each problem has it’s own fix.

The time it takes for the server to respond to a request (Time to First Byte, TTFB) is too high.

• Use Page Speed Insights > Diagnostics > Reduce Initial Server Response Time.
• Test with WebPageTest or GTmetrix (look for TTFB).

CSS and JavaScript files are delaying page rendering.

• Use Page Speed Insights > Diagnostics > Eliminate Render Blocking Resources
• Chrome DevTools > Coverage Tab to check unused CSS/JS.

Images are too large and should be resized for better performance.

• Page Speed Insights under Opportunities > Properly Size Images.
• Right-click an image, Inspect Element, and check the display size vs actual size.

Images not visible on load are slowing down the page.

• Page Speed Insights under Opportunities > Defer Offscreen Images.
• Chrome DevTools Lighthouse Panel.

Using JPEG and PNG instead of WebP or AVIF reduces performance.

• Page Speed Insights under Serve Images in Next-Gen Formats.
• Check file extensions manually.

Unminified CSS and JS files increase page load time.

• Page Speed Insights under Minify CSS / Minify JavaScript.
• Chrome DevTools > Network Tab (check file sizes).

Some CSS/JS is loaded but not used on the page.

• Page Speed Insights under Reduce Unused CSS / Reduce Unused JavaScript.
• Chrome DevTools > Coverage Tab.

Gzip or Brotli compression is not enabled for assets.

• Page Speed Insights under Enable Text Compression.
• Check via Gzip Test or DevTools Network Tab (check content-encoding).

JavaScript is taking too long to execute, delaying interactivity.

• Page Speed Insights under Reduce JavaScript Execution Time.
• Chrome DevTools > Performance Tab.

Elements move unexpectedly during page load.

• PSI under Avoid Large Layout Shifts.
• Chrome DevTools > Performance Tab > Layout Shift Events.

There’s A LOT that can cause WordPress to be slow. A slow WordPress is usually caused by a combination of factors and problematic components. Each component causing delays or slowing things down often requires it’s own individual fix.

Identifying issues, then addressing them on an individual basis is more effective that either randomly trying things, or aiming for one global fix.

If your’e REALLY stuck with a slow WordPress, there are some companies that offer WordPress optimisation services that can help speed up your WordPress.