Why is my WordPress website so slow?

Jem, why is my WordPress website so slow?

This question has landed in my inbox several times this week. Site owners, desperate to know why their WordPress website is so so slow, getting little to no answers from their existing developers or agencies.

So, why not put together a list? Here are the top 5 reasons I’ve found for slow WordPress websites, based on the work I’ve done on site performance and speed over the past 18 months:

5) Poor web hosting

Although this seems to be getting less of an issue as the WordPress web hosting space gets more competitive and customers demand more from their hosts, bad web hosting can still have an impact upon your website speed and response times. More specifically, hosting appears ‘bad’ because of two core reasons:

• Overcrowding: lots of websites crammed into small resellers accounts, which themselves are crowded onto a shared hosting server
• Reliance on ancient versions of PHP; one benchmark of WordPress builds on PHP5.6 vs PHP7.0 showed a 100% speed increase for PHP7.0, another by Kinsta benchmarked PHP 7.4 as over 3 times faster than 5.6

Good web hosting can (literally!) make or break your website. Saving a few quid a year on cheaper packages is false economy when it comes to hosting.

4) Excessive plugin use

Although there’s nothing inherently bad in relying on third party plugins to increase the functionality of your website, many plugins tends to bundle their own JavaScript and CSS dependencies (often unnecessarily, but that’s another moan for another time!) Add 20, 30 or more plugins to your website all loading their own JavaScript and/or CSS, and suddenly you have 50 or more ‘http requests’ to various files.

A HTTP (hypertext transfer protocol) request is, simply put, a way of retrieving information from a server. When you visit a website, your browser asks for information relating to the page you’re looking at: images, JavaScript files, HTML files, etc. The server then sends these files back.

Browsers only support a certain number of connections to a server which means they can only request a certain number of files at one time (in most cases, around 6). When a website tries to load tens of files at once (images, scripts, etc), you start to experience “blocking”; blocking occurs when a file or resource has to wait for a free connection before it can begin to download, essentially a queue of resources waiting to download. Read more about blocking and its effect on web performance.

By reducing the amount of plugins a site is reliant on, we reduce the amount of resources loaded, reduce blocking and increase the speed of our sites.

3) Frequent use of ‘nonoptimal’ images

What’s a nonoptimal image? Well, in the case of websites striving to improve their WordPress website speed, a nonoptimal image is:

• An image inserted at a large physical size (thousands of pixels tall/wide) but resized down to a smaller size in the HTML or CSS
• An image that is improperly saved: that is, photographs saved as .png instead of .jpg, or images with a simple limited colour palette (e.g. logos) saved as .jpg instead of .png
• An image that hasn’t been ‘web optimised’ in any way

All images should be resized to best suit their purpose, even before upload (WordPress will generate multiple sized images to use in different scenarios on your website, but you still don’t generally need a 5000 x 5000 pixel photograph sat on the server.) Images should be saved using the more appropriate image format. Lastly, images should be optimised using tools like JPEGmini and tinyPNG to save space and bandwidth without compromising on quality. (For the sake of simplicity, I’ve ignored SVGs, webP etc – more on those another day!)

2) ‘Kitchen sink’ themes

This term comes from the idiom “everything but the kitchen sink”, meaning “including nearly everything possible”. These themes are normally distributed on sites like ThemeForest and Envato, although other more popular “kitchen sink” themes are also owned and distributed independently. So-called because they’re designed for literally everyone, and therefore contain every possible bit of functionality you could need. This is fantastic if you want something flexible, but less so if you want the leanest build for the fastest experience.

One of the most popular “kitchen sink” themes that people come to me using is Astra. Astra is described as “fast and lightweight”, with “just 0.5 second load times” on its own homepage. However, this is misleading as it describes Astra alone, out of the box, with lots of things turned off. Nobody uses Astra like this. Even their own example sites don’t get this kind of speed; running GTMetrix on one of the home decor demos gives a load time of 4.2 seconds:

3.1 seconds for ‘brand store 2‘, etc etc.

Astra isn’t alone in this, of course, but it’s definitely one of the most popular themes of this ilk. This is partly due to loaded resources, extra functionality, more stylesheets etc, but the biggest problem is because Astra is most often used with – and advertises itself as ideal for – pagebuilders. Which brings me nicely onto the biggest reason why WordPress websites are slow…

1) Pagebuilders: Divi, Elementor and WP Bakery/Visual Composer

WordPress pagebuilders are, hands down, the biggest pain point for anyone looking for a fast, lean website.

If we go back to the Home Decor demo of Astra, we can see by looking at the source that it’s built with Elementor. On the home page of that site, Elementor is loading in excess of 15 stylesheets as well 6 JavaScript files. That’s over 20 http requests just to load Elementor resources; with Astra and WordPress core JavaScript/CSS on top of that (and those plugins mentioned earlier), add all of the images and content that a typical site would need to load, and you’re hitting blocking-central.

Let’s not pick on Elementor here: Divi and WP Bakery have exactly the same problems. And it’s not just http requests. The mark-up these pagebuilders generate is Bloated (yes, with a capital ‘b’). What is bloated mark-up? HTML that is littered with code that needn’t be there: usually ‘div soup’ (lots and lots of nested div tags) and tags that aren’t necessarily semantically correct (not the most appropriate for the content inside).

This matters because it adds to the page size (which makes it slower), it makes code less readable (which makes it harder to debug), less accessible and less meaningful from an SEO perspective. Munir Kamal did an excellent side-by-side comparison of Elementor vs the new WordPress editor Gutenberg which covers this in more detail.

Pagebuilders undeniably have their place, and may be the difference in having and not having a web presence for small business owners. However, in my opinion, if your WordPress website is business critical – i.e. without it you cannot earn a living – you should be investing in a website which avoids these common pitfalls for the optimum experience for your customers.