At StackPath we love Sitespeed.io, an open source tool that helps developers test website speed and performance. So when its creator Peter Hedenskog told us about his and Tobias Lidskog’s latest project the coach, we tried it out immediately. We were so impressed that we invited Peter to tell you about it and show you how it works.
Do you remember what happened 2007?
Apple released the first iPhone, MySpace was popular, and Yahoo open-sourced YSlow.
That was nine years ago, and the web has changed since then: People now use phones to access your site, browsers update themselves regularly, and we have a new version of HTTP.
The point? Rules that applied in 2007 for making a web page fast aren’t the same as they are today. Which is why we built the coach, or why we’re building the coach. The coach will never be finished; she will continue to learn as the world changes.
How the Coach Is Different from YSlow
Chrome will drop support for SPDY with the official release of Chrome 51. The coach knows that. Your site is using HTTP/2. The coach will adjust advice accordingly. And when browsers release new functionality that can make your page render faster (like Chrome shipping Preload), the coach will learn by a new pull request.
The coach will evolve at the same rate as browsers because she is a living project. Yes, YSlow was once the best web page performance test that was open-sourced, but it has been dormant for years. Open pull requests date back to 2013.
How the Coach Helps You Optimize Pages
In the future the coach will be able to help you in ways unknown to me. But how can the coach help you today? Well, since you’re reading this on StackPath, let’s talk about caching.
Is your server correctly configured for caching? The coach will help you determine that. It will also show you how long it’s been since you changed a file and compare it with your cache time.
Say that for all assets loaded on your page, the median time since they were changed is 7 weeks. But the median cache time for all assets is one hour. That’s a mismatch that you should look into. The coach will not say that it’s wrong; rather, she’ll point you in the right direction.
The coach will also give you a performance score between 0 and 100. We have benchmarked against YSlow and Page Speed Insights and, in almost all cases, YSlow gives you a higher score than the rest.
As for PSI, results are pretty similar but each web page performance test checks different things. Or at least we think they do. PSI is open source but it’s kind of hard to find the source code.
The Coach Giving Obama Some Tough Love
Below I’m going to “coach” Wikipedia’s mobile page for Barack Obama.
First I’ll use the mobile switch for using a mobile user agent, choose Chrome (you will get slightly different results depending on the browser you choose), and add details (this will give you info about the exact assets that have performance problems).
You can also use
–help to get all parameters. I didn’t add this in the test below, but it’s good to include if you need direction on making the improvements that the coach suggests.
Here is the input:
webcoach https://en.m.wikipedia.org/wiki/Barack_Obama --mobile --details -b chrome
Here is the full output.
So here the coach is giving us best practice advice, accessibility advice, and performance advice.
In terms of best practice, the coach is saying that Wikipedia uses HTTPS and HTTP/2. In terms of accessibility, the coach is saying that images are missing the alt tag. And in terms of performance, well, there’s a lot to be said as this is the coach’s main focus.
Let’s take a look at why this Wikipedia page got a performance score of 87 and not 100:
- The Obama page has 43 requests that don’t get cached by the browser because Wikipedia doesn’t set cache headers. If we fix this, 561.5 kilobytes will be saved if the user decides to view this page again. Setting a cache header is the most important advice the coach provides so this really hurts the performance score.
- We get a warning that the page has five requests with a cache time but they are set to smaller than one month. It’s good to have longer cache headers.
- The page both inlines CSS and does CSS requests inside the head. We should either push the CSS (when we have push support available with HTTP/2) or inline the render blocking CSS. But we should not do both.
- The coach also warns us about two requests with private headers. This advice has low priority because the coach doesn’t know if they should really be private. In some situations, having private headers is a best practice. But for assets that are shareable between users, it’s a big no-no. So you need to figure out whether they’re needed or not.
Coach Your Pages to 100
Now it’s your turn to test the pages on your website. Install the coach and test them out. What can you do to get them to 100? Also, if you think the coach is missing any advice during your tests, submit a pull request. We love that!
Originally published by MaxCDN, a StackPath company.