Does page speed really mean performance?

The method of how Google grades you on SEO is a bit of a black box but there is one thing we do know they care about and that’s speed.

Back in January 2017, Google announced that starting in July 2018, page speed will be a ranking factor for mobile searches. We assume this idea is based on promoting relevant content and a fast website will ultimately deliver a better user experience.

For that reason, it’s easy to get obsessed with tools like Pingdom, Google PageSpeed Insights, and GTMetrix. Those tools and others like it are designed to analyze your site and grade it based on a few key points.

A few factors you’ll get graded on are things like combining JavaScript files, minifying CSS, and adding desired headers to your static assets. There are over a dozen factors that any page speed tool will consider and grade you on but what do they really mean and why is that score so important?

We believe that page speed tools are important but they don’t account for everything. Here are a few examples.

Combine JS and CSS

As of this writing, all the above-mentioned page speed testing tools have little to no support for HTTP/2.

So, what’s HTTP/2?

HTTP/2 is a newer protocol for how data can be delivered to your browser. In the most basic example, HTTP/1 (or just plain HTTP) delivers data one packet at a time. The evolution of this is known as HTTP/2 and can deliver many packets at a time.

Imagine a single lane highway with no shoulder and a driver in front that always obeys the speed limits. Now imagine a multi-lane highway running along another multi-lane highway and everyone has their own lane. That’s HTTP/2.

By using this new protocol combining JS and CSS files isn’t that important anymore. In fact, combining all your JavaScript files into one may actually slow down performance now because your browser will be waiting to download that single file rather than a collection of smaller files without waiting.

Page speed tools will mark you on this but don’t sweat it. It’s not the end all be all of the performance they just need some time to catch up. Almost all of the tools we mentioned have comments in their roadmaps or blogs about adding support for this.

Shifter support HTTP/2 to combat this so regardless of what any page speed tool says, when they catch up you’ll be ready.

Defer Parsing of JavaScript

If you have render blocking JS you’ll get a bad grade. Render blocking JavaScript is anything that can (and really probably should) load after the initial page load.

For example, one of the WordPress Twenty-Seventeen theme JS files that load is a file to control the ScrollTo function. When you click on a nav item, it can scroll down to the proper section of that page and this file loads before the DOM loads.

The issue with loading before the DOM is that ScrollTo function has nothing to “scroll to” but it’s loading first anyway. By setting this file to load after the DOM we could, in theory, save on page load time because it’s “Render Blocking”. That’s not what is really going on though.

Back to HTTP/2, there is a feature within that called Server Push. This allows assets to be loaded asynchronously by your browser. No special plugin or StackOverflow copy and paste JS required.

Server Push helps speed up the time it takes your browser to load by taking all the content and assets at once and rendering them without blocking.

Again, page speed or performance tools don’t account for this yet but it’s an always-on feature of any WordPress site using Shifter.

Remove Query Strings from Static Resources

This recommended from sites like GTMetrix or Pingdom are valid but they do not account for what the CDN or server is capable of.

In a recent post, we covered the topic of Query Strings and how they really aren’t that bad because those assets are cached on Shifter.

We’ve built Shifter on AWS and deliver content via CloudFront. With a recent update, our CloudFront settings system wide allow for those static WordPress assets to cache and include helpful Expires and Max-Age headers too.

For the full read on that topic check out our post, Don’t Hate the Query String.

What’s next?

While we can’t change how page speed tools work right now we can all be the champion of an update. If your favorite testing tool falls short on the topics we discussed reach out and let them know. Direct customer feedback goes a long way!

In the meantime, we’ll be here wishing and hoping and pursuing all things Serverless-Static WordPress.