Make WordPress fast in 7 easy steps

Make WordPress fast in 7 easy steps. 7 simple measures you can take to ensure your WordPress performs well and passes core web vitals. This will improve both user engagement and search engine rankings for your website.

The hosting can make a considerable amount of difference to the performance of your website. Making sure that the Litespeed web server, object caching, and opcache are all available to you before you purchase hosting is an advisable course of action. If you’re working on an existing website, rather than making a new one, and your hosting doesn’t provide these facilities there is the option of moving hosting providers.

Hosting that provides the Litespeed web server, object caching, and opcache doesn’t always cost a lot. We provide this with all our hosting packages (even the £10 per year web hosting offering). We’d normally recommend the Unlimited hosting package for WordPress to provide a decent amount of RAM and CPU. We currently offer this package at £1 plus VAT per month for the first 6 months, and £4.99 plus VAT thereafter.

What each of these services do:

The Litespeed web server is a drop-in replacement for apache, it functions in a similar way and performs the same function (to serve websites).

There are three benefits to using the Litespeed web server.

The first is that the Litespeed web server take less time to spawn PHP processes compared to Apache. As WordPress is a PHP based application, PHP processes opening in a reduced amount of time is beneficial. This reduces the total time to first byte, first contentful paint, and largest contentful paint. As these are all measured as part of your website’s core web vitals, using hosting that provides the Litespeed web server alone improves the likelihood of you website passing core web vitals. Passing core web vitals in turn gives an improved user experience, and also improves page ranking in search results. This is covered in much greater depth in this blog post about WordPress and core web vitals.

The second benefit of using Litespeed web server based hosting, is that there’s an accompanying caching plugin that can be used in WordPress installations. This plugin is called Litespeed Cache. It’s made by the same people that make the the Litespeed web server, and is used to gain a greater level of integration between the WordPress installation and the underlying web server. This also improves performance.

The third benefit is that HTTP/3 can be used with Litespeed. HTTP/3 works over UDP, rather than TCP/IP. TCP/IP is what’s called a guaranteed protocol, and involves the acknowledgement of packet receipts. This acknowledgement has a data transfer overhead, increasing the total amount of data transferred. Although UDP isn’t a guaranteed protocol, most networks are reliable to the degree where this doesn’t matter, and the lack of acknowledgements reduces total data transfer.

Encryption handshakes generally happen faster with HTTP/3 compared to earlier versions of HTTP (like HTTP/1.1 or HTTP/2) due to its use of QUIC, a transport protocol that is designed for speed and efficiency. QUIC integrates TLS 1.3 directly into the transport layer. This eliminates the need for a separate handshake process for encryption, as is the case with TCP+TLS in HTTP/1.1 and HTTP/2. This encryption handshake takes place when pages of your site are requested if you’re using HTTPS and have the padlock in the browser’s address bar.

You may have seen a message that reads “you should use a persistent object cache” in the site health section of your WordPress. This is WordPress themselves recommending that you make use of object caching to improve your websites performance.

Although there are some caching plugins such as W3 Total Cache that can make use of your hosting account’s file system for object caching, this isn’t the greatest of ideas.

Object caching consists of caching parts of your website. These parts are often small and high in number. As most shared hosting has a limit on the amount. of files that can be stored, using the hosting account’s file system for object caching will, over time, consume the amount of files you can store in your hosting, and your site is likely to error when this limit is reached.

Often in hosting there are dedicated, underlying, object caching services that can be used to store the cached parts of your website. These are Redis and Memcached. These are both “in memory” datastores, so the cached objects are stored in RAM rather than in your hosting’s file system. Using RAM like this doesn’t contribute to the number of files stored in your hosting account.

You’ll need to use a plugin to make use of object caching. Many caching plugins provide this facility (this is covered in the use a caching plugin section below). Often Redis or Memcached will run on the same server as your hosting. If they do, the settings you need to configure object caching are:

• For Redis:
  Server address: localhost
  Port: 6379
• For Memcached:
  Server address: localhost
  Port: 11211

When a page of your site is requested. Parts of the page output are stored in the object cache. These parts can then be referred to when subsequent page loads take place. The parts being requested from the object cache mean that the parts don’t have to be generated. Requesting from an object cache takes less time than a fresh generation of parts of page content, so page load time is reduced when using object caching.

Opcache is built in to the PHP configuration of your hosting. In some types of hosting you can add this yourself, on other types of hosting, it has to be made available to you by your hosting provider.

You can check to see if Opcache is available by creating a file in the document root of your hosting (usually the public_html or the httpdocs directory) called info.php and putting this in the info.php file:

<?php phpinfo(); ?>

If you then browse to https://website-address.com/info.php and can see an opcache section, opcache is available to your website:

It’s not the best of ideas to leave the info.php file in place permanently as this broadcasts your hosting’s PHP configuration to the internet, so can have security implications. Delete the info.php files once you’ve checked to avoid this.

Opcache stores precompiled PHP byte code in RAM, allowing PHP scripts to execute faster by skipping the compilation process. By default, PHP uses an interpreter that compiles scripts into byte code ‘on the fly’ each time they are requested. This on-the-fly compilation introduces a performance/time overhead. With Opcache, the byte code is cached in memory after the first request, eliminating the need for repeated compilation when subsequent requests take place. As a result, using Opcache reduces the execution time of PHP scripts, leading to faster page loads for your WordPress site.

Page builder plugins make creating pages slightly easier. They came about due to the built in editor in WordPress being a bit hard to use. Since then the built in editor in WordPress has come on a long way, so it’s now a lot easier to use than it used to be.

Many page builder plugins will add a lot of elements to your website’s page output. The net approximate effect of this is a decrease in performance.

Not all page builder plugins will do this, but if you find that you’ve used one that does and would like to move away from using this page builder, you’d have to remake all pages on your website using the built in editor in WordPress.

Using the built in WordPress editor (Gutenberg) to create page content avoids additional code being added to your website’s pages. This decreases their size, means that browsers don’t have to do as much work when rendering pages, and improves page load times.

As I’ve mentioned above many page builder plugins will add a lot of elements to your website’s page output.

This means that:

1. The browser has more HTML to render, so it has to work harder, and the rendering process takes longer.
2. The total size of the page is increased so it takes longer to download.
3. The ratio of text to HTML is reduced, which can negatively affect HTML.

Not using a page builder plugin can help avoid these issues. Use the built in Gutenberg editor wherever possible, and your page output will be reduced, as will page load times.

Not all themes are created equal. Some can be really fast and lightweight, and others can be enormous and cumbersome.

There are some themes known to be resource heavy such as Avada and Divi.

There are more lightweight themes such as Generate press, Astra, Oxygen, Blocksy and Kadence that are a lot more light weight and less resource intensive.

There are over 7,600 free WordPress themes available, so it’s advisable to research themes and possibly test them, before making use of them.

If you switch from one theme to another, you’ll have to undertake customisation on the new theme that you’ve switched to, so that it appears in the manner you’d like it to.

This blog provides some very good concise advice about which themes are currently available that are fast and lightweight.

Caching plugins are usually used to improve a website’s performance and reduce page load times. Many caching plugins will also provides mechanisms to optimise your website’s page output such as minifying and combining JavaScript and CSS.

If you’re using hosting that provides the Litespeed web server, it’s strongly advisable to use the Litespeed Cache Plugin as it’s made by the same people that make the Litespeed web server. The caching plugin and the underling web server are effectively integrated to a greater degree than would normally be the case.

You’d install and activate the Litespeed cache plugin just like you would any other plugin. Then to carry out a base configuration click on “presets”, the “apply preset” in the recommended section:

You’d then need to configure object caching by clicking on:
Cache > Object

If Redis is available in your hosting, set:
Object cache: on
Method: Redis
Host: localhost
Port: 6379

Then save changes.

If you only have Memcached available or would prefer to use this set:
Object cache: on
Method: Memcahed
Host: localhost
Port: 11211

Then save changes.

Finally click on:
General > General Settings > Request a domainkey

Wait a few minutes then refresh the page and you should see dots appear in the domainkey field:

It would be advisable to check your site after making these changes to ensure that it functions as expected. In almost all cases it will, but you may need to disable the minify and combining of javascript files (cache > page optimisation > JS settings) if the mobile menu breaks, or Javascript based functionality is broken.

The configuration of the Litespeed cache plugin that’s outlined above covers quite a lot of different things with the 3 changes.

Object caching (as explained above) is bought in to effect.

HTML, Javascript and CSS is minified and Javascript and CSS are also combined. This reduces the size of JS and CSS files and the HTML in the page output by removing whitespace and comments. The combining of JS and CSS files reduces the number of CSS and JS files requested upon page load. Both of these reductions improve page performance.

A caching policy is also defined when you carry out the above, which instructs browsers with regard to how long they should cache and locally store static assets. This caching and local storage allows browsers to load some of your website’s resources from it’s local cache, rather than your site generating them, then them being transferred over the network. Again, this improves page load times.

You can find a detailed breakdown of the full configuration of the Litespeed cache plugin in this Litespeed cache configuration guide.

Next generation images are image formats such as webp or avif. Webp and avif files are smaller than their equivalent jpg of png equivalents without a loss of quality. As the images are smaller, they reduce the total size of your pages and the amount of data being transferred upon page load. This in turn decreases page load times.

The litespeed cache plugin can be used to automatically convert your sites images by clicking on:
Image optimisation > Send optimisation request

Your site and the QUIC.cloud then work together to reformat and replace images. The advantage of operating like this is that the conversion overhead takes place externally to your website, so there’s no processing overhead placed on your site when the conversion takes place.

There are other plugins such as smush and converter for media that perform the same function, but carry this out within your site, so there is an additional processing overhead when the conversion takes place, which can slow your site down.

It is also possible to manually convert images using a piece of image editing software on your computer before uploading them to your WordPress. This is the best option if you’re able to do this as the mage conversion takes place on your computer, so has no negative impact on your website.

Lazy loading images can be enabled in the Litespeed cache plugin configuration by clicking on:
Page optimisation > Media settings > On (next to lazy load images) > Save changes

As next generation images are smaller in size, the total size of your website’s pages is reduced by using these image formats. The reduction in page size means that less data is transferred over the network when a page of your website is loaded. Not only does this reduce the time it takes for a page to load, it also reduces bandwidth consumption which can help if you have a bandwidth limited hosting account.

Lazy loading images means that images are only loaded if they’re displayed on the part. of the page you see when it loads (above the fold). As you scroll down the page, the additional images then load.

Lazy loading images results in only the “seen” or above the fold images being displayed on the initial page load. As images further down the page aren’t loaded immediately, this results in less data being transferred over the network upon the initial page load, so it takes less time to display the part of the page you initially see.

Google now prioritises mobile performance when assessing websites performance. The way that the performance of a mobile page is measured is more stringent as it’s generally assumed that mobile devices are less powerful and may be using mobile network connections which are often slower the broadband.

Using a theme or a plugin that allows different images for mobile and desktop can help improve performance.

LCP stands for largest contentful paint. This is effectively the draw (or render) of the largest part of a web page. This usually involves an image, and in the context of WordPress this is usually a large image at the top of the page (just beneath the menu).

If you have a large LCP image being used for both mobile and desktop, this can make the mobile performance measurement worse due to the stringency of mobile performance measurement.

Being able to use different images for mobile and desktop allows you to put two different images in place for the same page, and then which is loaded is dictated by the device used to access the page.

You can create a smaller, optimised image for mobile devices to fit smaller screens and load faster. Meanwhile, a different, larger, high-resolution image can be used for desktops, ensuring the page looks great on larger screens.

The Blocksy theme can accomodate different images for mobile and desktop devices. The stackable add on for Gutenberg can be used to specify separate images for desktop and mobile.

By using device specific images, you can gain device specific page optimisations to improve performance and without compromising page quality, whilst minimising LCP times.

Preloading is a technique used to tell a browser to start loading resources sooner in the page loading processes. This works by putting a preload directive in the head of the HTML document that defines what should be preloaded.

The Preload LCP Image plugin is a really good, quick, and easy way of preloading LCP images. It can even be used to specify a different image to preload for mobile and desktop versions on different pages (rather than using a single universal site wide image), so works well with the “use different LCP images for desktop and mobile” methodology mentioned above.

You simply install and activate this plugin, and when you’re editing a page, at the bottom theres’s a section that allows you to specify which image should be preloaded for desktop and which image should be preloaded for mobile:

You simply use these options to preload the mobile LCP image for mobile, and to preload the desktop LCP image for desktop, then publish the page.

Without any preloading directives in place, a browser has to download a page’s HTML in fill before it will start to load the image at the top of the page. This means you have one thing taking place (the downloading and rendering of the HTML) then another thing taking place after (the downloading of the image). This “one then the other” type loading is slower compared to loading downloading both the image and the image and the HTML at the same time.

Preloading an image instructs the browser to start downloading the image while the page’s HTML is still being downloaded. This preloading results in two things happening at the same time (the downloading of the HTML and the downloading of the LCP image). Due to both happening at the same time, rather than one after the other, the total time for LCP is reduced when preloading the LCP image.

The time it takes for LCP to complete is one of the measurements used by Google when assessing a website’s core web vitals, so by improving LCP time with preloading, your be more likely to pass core web vitals and consequently rank better in google.