The WordPress Performance Challenge, part 1: Can it be done?
I’m obsessed with a lot of things. Clean code, design patterns and workflows are some of them. Website performance, #webperf, is another topic that I find very interesting, but also important.
This is the first part in a series of blog posts where I’ll try to make this WordPress blog as fast as possible. The goal is to avoid making modifications to the code as much as I can and try to only use plugins.
This is a standard installation of WordPress with the default Twenty fifteen theme. It uses two stylesheets and one webfont which is loaded from Google Fonts. Once the font stylesheet is loaded, it fetches six different font files.
The theme is also loading five different scripts, so we have eight HTTP requests to deal with from the start.
I also have the WP Markdown plugin installed which adds two scripts and one stylesheet. Finally, Google Analytics adds the eighth and last script.
Since the front page will change over time, I will be measuring the performance on this blog post since it won’t change and give me consistent test results.
The page has a total of 22 HTTP requests.
- Scripts: 8
- Stylesheets: 4
- Fonts: 6
- Images: 4
Let’s get started. There are mainly two sites that you should know about and probably already is if you have any interest in performance. These are PageSpeed Insights and WebPagetest.
Here is the test results from both sites:
- Mobile: 47/100
- Desktop: 57/100
- Load time: 3.702s
- Start render: 2.386s
- Speed index: 2438
- Load time: 2.202s
- Start render: 1.999s
- Speed index: 2014
Well, that doesn’t look to good. I’d like to at least get a score which is above 80 in the PageSpeed Insights test. I don’t think the numbers from the WebPagetest is a complete disaster, but it would be nice to come as close to a speed index of 1000 as possible. If you get 1000 or below, then your site is really fast.
But is it even possible to make the site that fast? It’s located at a cheap, shared hosting environment which I’m afraid might prevent me from reaching really good test results. WordPress itself might also be a potential bottleneck, even with a caching plugin installed.
However, I have no idea if I actually need to be concerned about the server and/or WordPress. So let’s find out!
A static file
I copied the source from the page and saved it as a static HTML file in the server root. By doing this I could find out how big of an impact WordPress has on the performance.
- Mobile: 49/100
- Desktop: 57/100
- Load time: 3.316s
- Start render: 2.295s
- Speed index: 2354
- Load time: 1.857s
- Start render: 1.858s
- Speed index: 1900
Okey, the results are more or less exactly the same. The PageSpeed test on mobile increased from 47 to 49 but remained at 57 on desktop.
I guess that I don’t have to worry about WordPress then. But what about the server?
An almost empty file
I created this very basic HTML file on the server and ran the tests on that.
<!doctype html> <html> <head> <meta charset="utf-8"> <title>stefanledin.se</title> </head> <body> <h1>stefanledin.se</h1> </body> </html>
This would tell me which the best possible test results the server could give me is.
- Mobile: 100/100
- Desktop: 100/100
- Load time: 0.285s
- Start render: 0.484s
- Speed index: 500
- Load time: 0.001s
- Start render: 0.161s
- Speed index: 200
Okey, it seems like I can’t blame the server for preventing me from reaching 100/100 and below 1000.
This is where to journey begins! The first question has been answered. Can it be done? Yes!
I’ll be writing the upcoming parts as I’m working and trying different things. This series will cover the entire process, so stay tuned!