Optimising WordPress Performance.
We sponsored June’s WordPress North East event in Newcastle and this post is based on a talk on optimising WordPress performance I gave. Head over to the WPNE website to find out about future events and book your tickets.
Speed is everything on the web. Fast websites perform better on every front, be it search ranking, user experience, engagement and, most importantly, conversions. You can read plenty of research that demonstrates this.
A lot of the work we do at TAC is in the music festival market. The websites we build need the ability to handle large visitor numbers and huge spikes in traffic. This means optimising WordPress performance is something we’ve got down to a bit of an art form.
Some background on this post
When I was asked to speak at a WordPress North East event I thought this would be an ideal subject.
I decided against approaching the subject from an overly technical angle. Instead the talk, and this post, are based around a case study. Using the Wild Life Festival 2016 website we launched in February this year, this post explains how we go about optimising WordPress performance.
Wild Life Festival
First, a bit of an introduction to Wild Life Festival. It’s a new festival; 2016 is its second year. It takes place in Brighton. 70,000 people descend on the city’s airport in early June for two days of music across four stages. It won Best New Festival at the 2015 Festival Awards.
Some of the bands, DJs and artists performing include Disclosure, Rudimental, Ice Cube, James Bay, Skepta, Carl Cox, Annie Mac, De La Soul, The Avalanches.
Last year’s Wild Life Festival website, which at this point I need to emphasise was nothing to do with TAC, received a spike in traffic shortly after launch that caused it to go down.
It had received around 100,000 visitors in a short space of time which, in the grand scheme of things, isn’t really that many. The result of this was six hours of downtime.
The challenge for us was that we didn’t have starting point for the number of visitors to expect this year.
We knew that we had to prepare for some huge traffic spikes. This was due to mainstream media attention, social media activity and email marketing to several lists with in excess of a million subscribers.
What went wrong last year?
The first thing we did was to look at last year’s website and we quickly identified several pretty huge issues.
Last year’s Wild Life website was on off-the-shelf theme that had been bought for £35 or so, hacked about a bit and made to sort of work.
There’s literally thousands of free and nearly free themes and plugins available for WordPress. The pros and (mainly) cons of these is a long ranting blog post in itself.
Themes these days seem to be all encompassing and contain so many features and this is a problem from a performance point of view. You’re still going to be loading all the theme’s scripts and assets even if you’re only using 10% of its functionality.
Even if a theme is relatively simple how can you be 100% sure of its quality? There’s no way of guaranteeing the quality of code from either a performance or security point of view.
Lots of agencies seem to think that building a WordPress website on top of a theme they’ve bought is an acceptable way to approach a project. We always find this pretty alarming but that’s another rant in itself.
Don’t get me wrong, there’s a time and a place for bought themes, but a project of any real size isn’t it.
The same applies to plugins.
There’s some plugins we use on every website for mainly non-functional reasons. I’m talking about Yoast SEO, WP Rocket, Shield, WP Remote, BackupWordPress and the like.
Except in some specific circumstances we avoid using plugins for functionality wherever we can for the same reasons we avoid off-the-shelf themes.
(Lack of) optimising WordPress performance
Last year’s website had no optimisation to speak of. More on how we do it a bit later.
The old website was on a shared hosting platform. Again, there’s a time and a place for shared hosting but a high-traffic website isn’t it. To be flexible enough to handle the highest of traffic spikes and beyond it’s worth spending a bit of time thinking about the hosting environment.
Shared hosting also obviously means that the website is sharing a server with other websites. There’s implications here for both performance and security. There’s no way to know what traffic these other websites are getting, what they’re doing or how secure they are.
There’s loads of horror stories about WordPress websites on shared hosting platforms being hacked because of a vulnerability on another website on the server. Just take a look at the Sucuri blog.
We were pretty keen to avoid anything like this.
Delivering a media-heavy website
As you can see from the Wild Life website it’s pretty media-heavy.
We worked with Studio Moross who are responsible for the fancy illustration and the Wild Life brand.
From my point of view as a developer, the challenge was the make the website look as pretty as possible, utilising the great artwork at our disposal, whilst keeping performance high and load times as low as possible.
Optimising WordPress Performance – what we did
We built the website from the ground up on our own WordPress framework. All code was completely bespoke. The only plugins we used added performance, security and analytical features to the website.
The above is only a starting point; at this point the website was 6.0mb in size and was loading in 2.2 seconds. This isn’t awful by any stretch of the imagination, especially if you compare this to some of the other festival websites we looked at. But neither is it particularly good.
So here’s what we did to optimise performance.
The first thing we do as we start optimising WordPress performance is to set up caching.
As a Content Management System, WordPress generates dynamic pages from template files and database queries.
To reduce strain on the server and to decrease loading times we use caching to take a snapshot of pages and serve them as static HTML files. When a user updates a page or a post a new snapshot is generated.
There’s many free caching plugins out there. Notable plugins include W3 Total Cache, which I find is way over the top on settings and Super Cache.
At TAC we use WP Rocket. It’s a paid for plugin but the one we find gives best results with just the right amount of configuration available.
On top of caching WP Rocket also offers several other invaluable performance features including:
- Images on demand (or lazy loading)
- Minification of HTML/CSS/JS assets to reduce file size
- Combining HTML/CSS/JS files to reduce the number of requests to the server
Our preferred web host, SiteGround (more on that later), also provides their own caching plugin called SG CachePress. This plugin works alongside WP Rocket to help with optimising WordPress performance on SiteGround’s server setup.
Getting the size of our image assets down as much as possible without compromising on quality resulted in the biggest saving on the website’s size.
There’s a great post on image optimisation by our pal Steve over on his blog so I’ll not go too much into it here. Instead here’s a quick overview.
We used Kraken, a service that optimises and compresses images, on all our image files. Kraken integrates seamlessly with WordPress by way of a plugin and allows you to optimise your entire media library with one click. It’s also possible to set Kraken to optimise any new uploads to automatically.
We then used Kraken’s online app to optimise all theme image files (i.e. files that weren’t in the WordPress media library).
On top of this we also used the HTML srcset element to serve images with sizes appropriate to the device that a user is accessing the website on.
We knew we wanted a dedicated server to avoid the performance and security constraints of a shared platform. We also wanted the flexibility to cope with the huge expected spikes in traffic and the scalability to cope with anything unexpected.
The solution we agreed on was an auto-scaling dedicated cloud server.
The benefit of this approach is that we specced a relatively modest server but built in the ability for more resources (RAM, CPUs) to come online during traffic spikes.
This takes away the worry of having to spec a server with finite resources. It also keeps the client’s cost down as extra resources only come online if and when necessary.
Content Delivery Network
The next step was to set up a Content Delivery Network – we use MaxCDN. This gave us the ability to deliver the website’s static assets (images, theme files, CSS, JS) from high-performance distributed servers.
There’s two main benefits to a CDN. The first is the ability to deliver content to users from a location geographically close to them. A basic example of this is a user from the USA accessing a website in Europe and the CDN serving static assets to them from a node in the USA.
The second benefit is taking a load of strain away from the website’s server. The reason for this is because all static assets load from the CDN instead. This was particularly beneficial in this project.
After all this optimisation launch was a pretty smooth affair. The flexibility and scalability we built into the project meant that we’ve had no critical downtime. At the same time the work we did optimising WordPress performance meant that the website loads near enough instantaneously, even during the biggest of traffic spikes.
We only encountered one minor issue during the process and this was to do with CloudFlare.
CloudFlare is a layer of security and performance optimisations that sits in front of a website. To use the service we change DNS settings so a user is filters through CloudFlare’s firewall before reaching the website.
We’ve used CloudFlare a lot over the past couple of years and at times we’ve seen slight impact on performance. Activating it on this website resulted in a huge hit on performance. It reached a point where the website receiving any meaningful level of traffic would result in performance slowing to unacceptable levels.
We removed CloudFlare and things quickly returned to lightning speed. Because of the necessity to avoid any further degradation in performance weren’t able to dedicate time to solving the problem and instead had to act.
What were the results of all the work we did optimising WordPress performance?
Last year’s website:
- Load time: 3.8s
- Size: 12.8mb
This year’s website (pre-optimisation)
- Load time: 2.2s
- Size: 6.0mb
This year’s website (post-optimisation)
- Load time: 700ms
- Size: 1.1mb
The figures above show that optimising WordPress performance makes a huge difference to load times. In addition, we’ve seen no degradation in this performance during traffic spikes resulting in a consistent experience to users throughout the life of the website.
Want to know more?
Would you like to know more about optimising WordPress performance? Do you have a project you’d like to speak to us about? Why not get in touch?
Shoot us an email at email@example.com – we’d love to hear from you.