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. Although the direct effect in search engine optimization is negligible, it can decrease the abandonment rate. Google values both for organic and paid search results traffic.
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 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.
The 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. For instance, the home page of index.hu is usually around 5-6Mb, which means that even if we check the home page 2-3 times a day, it can generate 4-500Mb monthly traffic. Think about mobile internet counts as a significant waste just for a single page.
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.
The planning stage is where we can do the most, that is, 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).
Luckily, this isn’t such an important aspect when it comes to speed.
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.
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.
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.
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
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.
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
This too is an important aspect because a faulty speed testing will give us skewed data. 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. Even google.com itself gets only 90% on mobile, and it’s not a complex page. PageSpeed Insights uses Lighthouse for analysis, which can be accessed in Google Chrome in the DevTools > Audits tab.
Another great tool for testing speed is GT Metrix, 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. In addition, we have the option to create a video of the test, which we can slow down to ¼ to check in which (hundredth)second will the page become visible to the user.
Although limited, there’s also the option to test on mobile devices and the bandwidth can be restricted to 3G. 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 GT Metrix. Because Pingdom only measures until the onload event, which can be set in GT Metrix as well. However, the default is the Fully loaded time, which means that after this the page no longer loads anything. The most physical locations are offered by WebPageTest, plus there’s a filmstrip type viewing of how the website is loaded. A kind of site loading wireframe.
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.