WordPress Performance Factors

Tweaking the performance of your WordPress site can involve pulling on a lot of levers. From how your browser is configured to the device type you’re using, to the way the webserver and database servers are configured – they all play a part in how fast or slow a user perceives a WordPress site.

In this article I will list as many components as possible that all affect WordPress site speeds in one way or another. If you’re working on an optimization project this list can serve as a handy checklist of things you should be tweaking.

There’s no order to the list – depending on your project, some things will have an outsized impact while others will barely move the needle.

The WordPress Site

Let’s start off with looking at the things you can control on the WordPress site itself.

Cache

If your web server /host has a caching mechanism it is usually better to use it rather than using a plugin for your cache. However, if you do not have access to a native web-server cache then you should use a plugin such as WP-ROCKET. Sites with any decent level of traffic will benefit substantially from cached pages even when those pages are served from a plugin cache.

But even with a cache solution in place, you also need to make sure that your pages can be cached. So, for example, try not to put forms directly on your pages or use query variables in your page URLS. Sometimes, something as simple as placing a shopping cart count icon at the top of the site can render all pages uncacheable because the cart count varies for each user and is rendered with each page.

So, enable the cache and make sure that there aren’t any features on your site that prevents most of your pages from being cacheable.

Images

Use images on your pages sparingly. Instead use SVGs for images and icons when you can.

And when you do use images, make sure that you set them to a size that is closer to how they will be viewed – there is no point in having a 3000x3000px file when the viewing area is 800×800.

Also, “smush” your files – this reduces the file size by removing elements of the image that most users cannot see.

Finally, “lazy load” as many images as possible – but only the ones BELOW the header (“fold”) of the page. How you can accomplish this varies depending on the level of control you have over the code. If you don’t have direct access to the theme and plugin code or you do not want to edit them directly, you can use plugins like WP-ROCKET that provide general purpose options to lazy load all images.

But because these plugins cannot be aware of all the thousands of plugins out there and how they all combine together, you’ll need to do a lot of trial and error to figure out which images can be safely lazy loaded without nasty unwanted side-effects.

JS Code

Try not to load up a lot of third party JS scripts. Facebook pixels, Google tracking, Google Fonts, Adobe Fonts, Font Awesome Pro etc., all involve JS scripts and each one will increase the time it takes to load your sites’ pages.

For JS code that is part of your plugins and themes you can sometimes try to combine them together so that they are available in a single http request. BUT, this tends to be problematic and requires a lot of trial and error to get right.

You can also try to load most JS code at the end of the page. Again, some trial and error will be required to make sure you don’t break the site – some JS scripts just need to be left alone.

CSS

As with JS code you can try to combine CSS files so that they load in a single HTTP request. Again, some trial and error will be required to make sure you don’t break the site. And that you make sure “critical” CSS loads first.

Plugins

You really want to reduce the number of plugins you use. The more plugins on your site, the more code that has to be parsed before a page can be served up to the browser. Some general purpose plugins try to do a LOT of things – if you have one of these but you’re only using one or two functions, it might be worth it to write a custom plugin to handle only those functions and turn off the general-purpose plugin.

Themes

Avoid general purpose themes that try to load up the kitchen sink. As far as page builders go, the best one in our experience has been Beaver Builder. OXYGEN is actually more efficient but it requires a lot of work to make it compatible with plugins that aren’t well known. So we prefer to stick with Beaver Builder.

Over the next couple of years, the WordPress editor (AKA “Gutenberg”) will likely replace a lot of existing themes and page builders for most users. Even in its current form its page output is far more efficient than standard themes and page builders. So if you can build pages with Gutenberg today you should do that and only build complex pages with 3rd party page builders.

Page Design / Page Size

For the fastest pages, keep them small. Need to show the benefits of using a product? Split the information among a series of smaller pages. Each page will load faster!

The Web Server

If you have control over your webserver, there are a number of things you can do to improve performance. These include:

• Using a native webserver cache and couple it with a compatible WordPress plugin to sync up the webserver data with WordPress. For WPCD, we use a page cache in NGINX and couple it with the KEY CDN PLUGIN to sync it up with WordPress.
• Enable long-lived browser caching for static files such as images, js and css files.
• Enable GZip for compressible file types such as JS & CSS files. This is especially useful if most of your users are on mobile devices. Gzip will reduce the time it takes to transfer certain files (but will add a little bit of web server overhead).
• Enable HTTP/2 if possible. This allows parallel loading of files in a more efficient manner which is especially great for desktop users who might have more bandwidth available and more cpu power to quickly churn through parsing multiple files simultaneously.

Each webserver has parameters that can be further tweaked based on how much traffic you’re receiving. For example, in NGINX you can tweak things such as:

• worker_cpu_affinity
• worker_rlimit_nofile
• pcre_jit
• multi_accept
• worker_connections
• accept_mutex
• epoll
• reset_timedout_connection
• keepalive_timeout
• variables_hash_max_size
• variables_hash_bucket_size
• server_names_hash_bucket_size
• aio threads

PHP

PHP Version

This recommendation is simple – use PHP 7.4. If you have a plugin that is not compatible with PHP 7.4, ditch it. Really. Because the difference in performance between PHP 5.6 and 7.4 is HUGE.

Op Cache

Make sure that the PHP OP CACHE is turned on. Most providers turn this on automatically for you but if you’re running your own server you will need to modify the php.ini file to enable it.

Caution: If you’re running multiple sites on your server you should turn on the flags that segregate the data in the cache between sites! By default these flags are not turned on when you turn on the OP CACHE – you need to explicitly enable them!

PHP Workers

Experiment with PHP workers. These come into play when serving pages that cannot be cached – they will process the PHP request including compiling the PHP code on the fly.

For smaller pages, the compilation process can be as fast as a few milliseconds. But for larger sites with dozens of plugins, it can take a second or two to compile a page.

The trick to tweaking this number is the speed of compilation for your most requested pages matched to the number of CPUs you have. So, if your most requested pages take 0.5 seconds to each compile and you have two cpus, there is usually little benefit to setting your max PHP workers far beyond 4 or 5.

The Database Server

In the ideal world, the size of your entire database would fit in memory and you would adjust the database caches to accommodate this.

But for larger databases this might not be practical.

For most installations of WordPress, all server components reside on the same server. If you have a super-large database or thousands of e-commerce requests per minute then it might be time to move it to its own server. Or graduate to a solution like Amazon’s RDS with multiple read-only replicas.

As far as the database itself goes, look at slow queries and see if any of them might benefit from an additional index or two on key tables. On the flip side, do NOT add indexes to all columns in a table – if you can’t determine if an index is needed then the chances are that you’re just slowing down the overall database performance by adding indexes to all columns.

The Linux Server

If you’re using a regular WordPress host, chances are you’re sharing a server with dozens or even hundreds of other WordPress sites. In many instances you can get a HUGE performance gain just by moving the entire site to its own cloud server with shared or dedicated CPUs.

In fact, this might be the first thing you want to try because the performance gains can be amazing vs the amount of work required.

General

Browser Type

Some browsers parse and render data faster than others. This goes for desktop browsers as well as browsers on tablets and phones. The variance is particularly acute for Javascript. So, for sites with a lot of JS code, the perceived site speed can depend a lot on which browser is being used.

While you can’t control which browsers your users select, you can probably figure out which are the most commonly used and then optimize for those.

Network Connection

The speed of your connection to the website server is a factor in how fast a website loads and runs. Mobile speeds and desktop speeds tend to be two very different beasts. When you’re optimizing a site, do so for the connection type likely to be used by the majority of your users (or your high-value users.)

Other

CDN

Configuring a CDN such as CloudFlare can sometimes make loading static assets (JS, CSS, IMAGES) faster.

Using plugins such as OFF LOAD S3 (by Delicious Brains) can help media heavy sites by moving those files to AWS S3 buckets.

Search

If you have a large site with lots of content, you might need to investigate using a solution such as Elasticache to help speed up search and queries on your site.

Bleeding Edge

CloudFlare has a new service that attempts to cache major portions of a WP site on its edge servers. It does this by using a plugin on your site to communicate with its servers. You should check it out and see if you can make it work for you. When it works it’s fabulous but, as with most general purpose optimization solutions, it can require trial-and-error to get it to work without unwanted side-effects.

Wrap Up

Optimizing a WordPress site (or any site for that matter) is not a trivial task. There are many areas where performance can bottleneck – you just need to plough through and tweak them them one at a time.

It takes a lot of time and sometimes you just want someone else to do the job for you. A simple Google search will throw up dozens of companies that specialize in WP performance so you really aren’t going to be at a loss for options if you want to out-source the whole thing.

And sometimes, brute force can help you get some fast gains – increase CPUs if you’re already on a dedicated server or move to a dedicated cloud server if you’re still on shared hosting.