Preload key requests is an “opportunity” that you may see recommended by PageSpeed.
PageSpeed will show you this message when there are necessary files to render (display) your page which are referred to 3 levels deep in your code.
This is the blog post that accompanies a talk I gave at WordCamp Seattle in 2019. You can see the slides here.
Additionally, the HTTP Archive Web Almanac was published around the same time so I’ve also interspersed some of the insights from that report since they dovetail really nicely.
Providing excellent context for this post, the CMS chapter shows how sites built with a Content Management System (and WordPress sites comprise almost 75% of those in the report) tend to:
Additionally it reported that WordPress sites tend to have slower performance metrics.
Now this is not really the fault of WordPress itself, it’s really due to what we site owners have done.
While it’s possible to build bloated pages and use techniques to make them seem fast, that shouldn’t be the goal. Let’s just build lighter pages to begin with!
Listen, let’s keep it real, PageSpeed Insights is a tool best used by developers. Its intentions are good but it’s not targeted at the average WordPress site owner. Even with the recent introduction of some WordPress-specific messaging, many aspects of the report are too technical to be clearly actionable.
In this guide I’ll try to translate what PageSpeed is talking about and let you know which factors you can control, as a WordPress site owner, and which you can’t.
The basic principles that PageSpeed Insights is trying to communicate are:
These are solid principles but PageSpeed communicates them in somewhat obscure ways.
The Time To First Byte (TTFB), or server response time, of your WordPress site can be an important indicator of performance. It doesn’t represent the whole picture, but a very specific part in the process.
Time to First Byte is a measure of how fast your server responds when someone tries to visit a page on your site. Specifically, it’s measuring how long it takes from the time the browser asks the server for the page, to when the browser receives the first piece of data from the server.
Visitors want sites to feel fast, so the sooner some meaningful content is displayed on the screen, the better. TTFB can influence this – the faster the server responds, the faster content can get to the user.
Without boring the pants off you, HTTP/2 is an updated and more efficient way of delivering web site components from server to browser. There are 3 conditions:
Now that it’s becoming increasingly widespread, most articles on the topic make sweeping promises of faster performance, “just like that”, simply by enabling it. But there are fewer articles which actually back up these claims with test results.
I recently converted a couple of sites from HTTP to HTTPS and decided to take the opportunity to see what difference, if any, enabling HTTP/2 made.
Trying to make your WordPress site faster is an already technically complex process, further obscured by all the jargon you have to understand. Here’s an overview of some commonly used site “speed up” terms. I hope it helps demystify the process!
The program you open to get on the internet: Chrome, Firefox, Safari are the most common examples.
A special computer, provided by your hosting company, where your website actually lives. By “lives”, I mean where all the files and the database are stored. This machine delivers your website to all your website visitors.
Just like your phone and computer run on a certain software – Windows or MacOS for example – there are a few different types of software your server may run on.
Normally you don’t have to worry too much about this – it’s a decision made by your host and you don’t need to get your hands dirty. But if you get really into optimization, there can be a few differences depending on your server environment.
