WordPress speed optimization is important because of two main reasons – a direct reason that concerns user experience and an indirect reason related to search engine optimization.
WordPress Speed Optimization 101
Because the user experience is multi-faceted (design, website structure, spelling, etc.), we cannot sacrifice design for speed. Take the example of a chat plugin that’s needed for a website – sure, it slows down the load time, but it shouldn’t be avoided in favor of speed. This is the context in which we must examine how and what we can do to achieve optimal speed.
WordPress Speed Optimization consists of two main parts: content download time and render time.
Download Time
Download time itself can be further examined in terms of other aspects that we will address one-by-one.
Time to First Byte (TTFB)
TTFB, or Time to First Byte, shows the amount of time it takes for the first byte of a reply to reach the requesting sender’s browser. This usually depends on the speed of a server, how far is it physically located from the browser and whether the content that’s being served is dynamic or static.
TTFB can also be influenced by DNS lookup as well as the time of the SSL handshake, but these are not WordPress specific factors, therefore, we will not examine them in this article.
Size of the Page
Obviously, the size of the page also influences the download time. However, this is not the only reason why we should strive for as small a size as possible.
Unsurprisingly, the size of the page is increased mostly by multimedia content, therefore, images and videos should be optimized primarily using lazy load technology or WebP format for images.
Queuing and Number of Requests
Luckily, most websites already use HTTP2 protocol, which in practice minimizes this problem. However, it must be mentioned that in the case of websites that use HTTP1 protocol, the browser cannot simultaneously open multiple connections to the server, therefore, some requests are queued until previous requests are handled.
Bottlenecks can appear even under HTTP2 because the server itself does not maintain unlimited connections, therefore, if the page has multiple requests (every image, CSS file, JavaScript file is a separate request), then the server will queue the connections, which means that even when using HTTP2, it’s best to strive for as few requests as possible.
Render Time
The render time is much more complex than the download time, but it’s an equally, or even more important part of page speed index. To render the page, HTML, font type and CSS are needed. However, modern websites generally also use JavaScript for final render (slider, masonry grid, full width rows, etc.)
HTML Optimizing
The planning stage is where we can do the most. We should aim to use a template that doesn’t generate a too complex – or too lengthy – DOM tree. In addition, we can minify the HTML, although we’d only gain 1-2 Kbytes on the whole (removal of excess whitespace characters, comments).
CSS Optimizing
This is one of the most important factors. The best thing we can do is to only load the critical CSS in the <head> part, which only contains the minimally necessary rules to render the page.
All other CSS should be moved into the footer, preventing certain CSS files to needlessly block rendering. CSS should also be minified, and although we would only gain a few Kbytes, which isn’t much, it still adds up.
Font Type Optimization
Font type optimization can be achieved in two different ways. If we use a custom template, we should load font types without conditional loading, e.g.:
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
If this is the case, the browser downloads the entire content, renders the page, analyzes the type of characters the page contains and loads the corresponding font type. It’s worth mentioning that Google Fonts works like this by default.
The other solution is to preload the fonts that the website actually uses by adding the <link rel=”preload”> tag manually or using a plugin.
JavaScript Optimization
Ideally, JavaScript is not needed to render a website, therefore, we can defer every script (or move them to the footer). This is in practice. However, in some situations things are different, which is why we will need to use exceptions.
Naturally, JavaScript itself can be minified as well, and we will gain a bit more than in the case of CSS or HTML.
Speed Optimization in Practice
So far, we’ve examined the most important factors, next we’ll examine the best solutions to the problems that we face.
Cache
Caching is the most notable way to speed up WordPress. With the help of caching, we can generate static HTML from dynamic content, allowing the server to deliver it faster.
It follows that the cache must be regenerated if we change something on the page, therefore — even though there are cache level solutions – a cache plugin will be required each time, which invalidates the cache if we change something. Cache significantly lowers TTFB and server load, and generally, we can achieve the most noticeable improvement when it comes to WordPress websites. Great cache plugin is WP Rocket.
Image and Video Optimization
When it comes to image optimization, there’s an abundance of options. It’s best to use a solution that supports WebP format as well. Because not all browsers are compatible with the WebP format, we need to find a solution that enables non-compatible browsers to receive the original JPEG or PNG format, while compatible browsers should receive the WebP format.
Most plugins can handle this, but you should still pay attention. Images can be optimized before uploading with your run-of-the-mill Desktop apps or other online services, but in practice, it’s best to leave this to a plugin.
Using CDN and/or Proxy Server
Some services are specialized in the fast serving of static files. Therefore, you should use these because using a CDN or a proxy server is guaranteed to speed up your website. The best choice is Cloudflare which offers us a lot even in its free version. If it’s set up correctly, it will speed up not only the images, CSS and JavaScript, but the page itself too.
Cloudflare works differently compared to traditional CDN solutions. The trick is to set Cloudflare’s own name servers for the domain and Cloudflare will always offer the closest edge server during name resolution.
What this means in practice is that if I’m accessing the website from Budapest, files will load from a server in Budapest. If I’m accessing it in Vancouver, then files are loaded from a Vancouver server, and so on. Therefore, the website will always load from the closest available server. Not to mention that these servers are extremely well optimized, which is guaranteed to serve things much faster than your own server.
Speed Testing
These kind of speed test tools are very important. Moreover, they help paint a whole map and provide vital data. Let’s talk about a few of the leading ones shortly.
Google PageSpeed Insights
The first tool that should be mentioned is the Google PageSpeed Insights, which not only allows us to test the speed but it also gives us detailed tips to optimize our websites.
Still, even though PageSpeed Insights uses great parameters, we shouldn’t treat everything it says as scripture, but more of a guideline. PageSpeed Insights uses Lighthouse for analysis, which can be accessed in Google Chrome in the DevTools > Audits tab.
GtMetrix
Another great tool for testing speed is GTMetrix, which, after a free registration, allows testing from various locations under relatively significant circumstances. Here too, results we get don’t entirely reflect the situation in real life, but it’s close, plus results can be compared to previous results.
When using GT Metrix, it’s best not to concentrate on Fully Loaded time, and by opening the Timings tab, focus more on FCP (First Contentful Paint) and Onload time respectively.
Although limited, there’s also the option to test on mobile devices and the bandwidth can be restricted. Scores shouldn’t be taken too seriously here either. Nevertheless, you should check the actionable advice GT Metrix is offering concerning further optimization.
Pingdom Website Speed Test
The next tool we’re going to discuss is the Pingdom Website Speed Test which also allows testing from various different locations.
The values you receive cannot be compared one-for-one with what you get in GTMetrix. Because Pingdom only measures until the onload event, which can be set in GTMetrix as well.
The default is the Fully loaded time, which means that after this the page no longer loads anything.
The Idea Behind Testing
The idea behind testing is that, if possible, we should avoid comparing the results of each tool one-for-one and understand what each result actually means (full load or onload event, etc.).
To measure real data, we can use Google Analytics’ Site Speed, which allows us to measure the average load speed. Of course, this will be an average consisting of mobile, non-cached hits, as well as visitors with very slow internet access.
Last but not least, we can also test load time on our own device, and while it’s true that it’s from a single location and on the same connection, it’s still an accurate measure. It’s important to always use incognito/private mode in our browser. Otherwise, a part of the content will load from the browser’s cache, which will falsely offer us a fast speed result.