At the core of site performance sits the raw HTML code of any given page. Within the HTML, we have images and CSS, JS and fonts, and each of these has optimization that may be done within the HTML, and some outside of that–compression, minification, etc. However, that HTML code can be optimized as well, nay must be optimized. In this pursuit then, one of the most fundamental and important measures of performance is TTFB, or Time To First Byte.
This measures the time between the browser making the request to your web server, and when your server responds with the very first byte of HTML code. Now why in the world ought there to be any time between those two things? That indeed is the question, never mind what some guy in the 15th century said… You might also see a related recommendation to “Reduce initial sever response time”, and that leads us to the first optimization that we can apply to our HTML.
Caching
Most commonly, folks think of page caching, but there are a whole host of things that can be cached for a WordPress site, and many of them affect the TTFB. We have the time it takes to compile the PHP, the time it takes to run the PHP and generate HTML, as well as the time spent accessing the database. While all of those are useful (and important), page caching typically eliminates the overhead of all those things by storing the HTML code that has been generated so none of that work has to be done for subsequent requests.
At least, that is the case for most of your visitors. But someone has to access a page for it to be cached in the first place, so uncached TTFB should be minimized as well. I’ve gone into great detail on all things caching, so I won’t repeat much of that here.
Server or Plugin?
When it comes to page caching, if your web host has it built-in, use that. If your web host does not have server-based page caching, or their cache lifetime isn’t to your liking, you can add a cache plugin to your site. These vary in complexity, with plugins like Super Cache and Cache Enabler being on the simpler side. I’m not a fan of the more complex plugins as they can be quite overwhelming, so our own SWIS Performance has a page cache option with only a couple options–and a host of overrides for you power users that like to tweak everything!
Compression
In this day and age, we can compress just about anything, and HTML is no exception. There are a couple different algorithms, but the general idea is to reduce the size of the HTML payload by using a “dictionary” of sorts to reduce duplication and use of whitespace. Most web hosts should support Gzip out of the box, while others will also offer the Brotli algorithm (like WP Engine). This is something that should generally be done at the server level, and SWIS will add rules for Apache servers that enables gzip if it isn’t already turned on.
You can check for HTML compression by using the developer tools in any modern web browser. Right click on your page, and choose Inspect. From there, go over to the Network tab, and refresh the page so the browser can log all requests. The very first request will be for the page itself, and when you click on it, you should see something like this:
The Content-Encoding header here is set to ‘br’ for Brotli, and if your server is using Gzip, you will see ‘gz’. The Timing tab in that same area will show you how long the HTML request took, and the “Waiting for server” time is the equivalent of the TTFB.
To Minify or Not to Minify?
No, that’s not the question! But I’ll answer it anyway: no… you don’t need to minify your HTML. Simply, when you minify HTML, you remove excess whitespace. Unfortunately, minifying HTML is fraught with problems, as removing a single line break can change the layout of your page. If you happen to have a plugin that does it already, you’re probably okay, but I wouldn’t mess with it.
Fortunately, Gzip and Brotli already do such a good job at reducing the impact of excess whitespace that the savings from minifying HTML are incredibly minimal. When we launched SWIS Performance in early 2020, I made the call to skip HTML Minify, and only months later, WP Rocket removed the feature for those same reasons.
Preloading
One of the interesting things about HTML, is that the browser can actually start interpreting the HTML and take action on that HTML before it is even done receiving all of it. This gives us the ability to preload other resources/assets that will be needed for our page very early in the page rendering process. I discussed the possibility of preloading images recently, but we use this mostly for fonts and theme CSS.
Most of the time, the images you want to preload are already very early in the page code and will not benefit from preloading. The same could probably be argued for CSS/stylesheets, so the biggest win is with web fonts. The browser won’t usually load fonts until it parses the CSS, and that can cause a FOUT or Flash of Unstyled Text. When you preload your essential (above the fold) web fonts, you can reduce or even eliminate FOUT. This can be done using SWIS, or Perfmatters, though there are certainly other plugins that can do this. That said, I had a hard time finding any free plugins that just do preloading, so your best bet is to use a good cache plugin that has it built-in.
And Pre-Other things…
Because the browser starts acting on the HTML before it is done receiving it, we can also get a little jump on a few other things. We can use “dns-prefetch” hints at the top of the HTML if we have resources that are loading from a separate domain name. For example, if we use a CDN, we can tell the browser to do the DNS lookup right away and speed up the requests that will be done as soon as the browser starts fetching things from the CDN.
Taking that a step further, we can use “preconnect” hints to minimize the impact of making separate connections to our CDN, or other third-party resources. In SWIS Performance, all of this is done automatically based on the domains you’re using in each page, but you can also manually add domains for dns-prefetch/preconnect via SWIS if you need to.
Optimize Asset Loading
I alluded to this earlier, but we can optimize the way our assets (images, CSS, JS, and fonts) load in the HTML. I’ve covered all of those in the linked articles, but I’ll highlight each of them briefly. With images, we can lazy load them, either with a plugin like EWWW Image Optimizer, or using the browser-native “loading” attribute.
In addition to preloading the most important stylesheets, we can also defer them to make sure they aren’t render blocking. Then, we can generate “critical CSS” that is needed for the “above the fold” portion of the page and inline that directly into the HTML. We already covered preloading, which is one of the best things you can do for web fonts. And if you’re using Google Fonts, you can also inline the font CSS within the HTML to avoid some of the unnecessary slow-down that is native to Google Fonts.
Lastly, we have JavaScript (JS), and this one ought to be the simplest, but sometimes isn’t. In short, none of your JS should be necessary to render the page, so defer it all, so that it loads afterwards. Inline JS can be tricky, but the Optimize JS Loading method in SWIS preserves the necessary script order by also deferring execution of inline JS.
Ultimately, of all the things you can do for your site, optimizing the HTML is one of the quickest things you can do. Some of them may even be done for you, so be sure you don’t neglect any of these foundational steps in making your site faster!
