We Have a Long Way To Go
When you work on web performance every day, it is easy to assume that the best practices are widely known, widely understood, and widely followed. Unfortunately, as I have learned through a couple of different experiences recently, this is not the case. It is frankly astounding how many websites are still failing to implement the best practices that Steve Souders outlined in his book "High Performance Websites" over six years ago. Six years is an eternity when it comes to web development, but I still regularly meet professional software engineers who are surprised when they hear about the rules that the WPO community evangelizes on a daily basis.
First, The Data
Let's try to scope the problem. Using data from the HTTP Archive, we know that:
I mentioned that I have had a few experiences recently that led me to write this post. First, I was recently speaking on a panel at a "Web Performance Day" for portfolio companies of a prominent VC firm in San Francisco. Steve Souders was giving the opening talk, and he opened with a scary comment. He mentioned that as he was putting his talk together, he surfed around some of the portfolio company websites so he could target his material to the audience members. He found that in the vast majority of cases, even the most basic optimizations were not being done. He was forced to alter his talk and give a "Performance 101" talk during which he dredged up slides from decks that he presented over 5 years ago. Yikes.
The second experience was during a recent episode of JavaScript Jabber. Alex MacCaw was talking about how he optimized monocle.io, and he mentioned Google's PageSpeed Insights tool. The tool was new to pretty much everyone on the show, and was a lot of "wow, this is so cool!". Remember, these are professional front-end web developers that are recording a podcast about JavaScript and front-end best practices in their free time. If they haven't heard of PageSpeed, and are getting surprised by some of the checks that it exposes, then we have a TON of work to do.
What Should We Expect?
Perhaps I am an idealist, but I think we should be able to get to 95%+ compliance with gzip. I don't expect every site to sprite all of their images (a best practice that SPDY/HTTP 2.0 will negate anyway), but I do expect every single site on the internet to figure out how to compress text resources. It's probably the easiest, most impactful, most well supported, and safest optimization that you can do.
This is just an example, but I think it is indicative of the problem, because we're only at 77% compliance with it. There are enormous benefits with literally zero downsides, and we still can't get a quarter of the sites on the internet to do it (and don't talk to me about CPU usage on shared hosting - if a host doesn't let you turn on gzip you should find another host).
The more concerning thing for me is that people expect new standards and browser improvements to come in and save us, like the aforementioned HTTP 2.0. While I'm extremely excited about HTTP 2.0, I worry that we will run into the same problem that we have today with gzip: it will take years to get up to a reasonable adoption point, even after the browser support is there.
When it comes to "what we should expect", I think understanding the core technologies behind the web and how to leverage them to build fast applications is a requirement for every single engineer. After all, speed is more than a feature, it's the most important feature. That's from the guy holding the purse strings, so it's worth taking to heart. If someone can't easily explain at least 3-5 performance best practices, to me that's equivalent to not being able to write a line of JavaScript. In other words, inexcusable if you work on the web as a developer.
Are There Enough Resources For Developers?
Yes. Perhaps we could do a better job about getting them in front of people early and often, but the[1] number[2] of[3] tools[4] and[5] resources[6] is[7] staggering[8] (I[9] could[10] do[11] this[12] all[13] day[14]). I'm obviously extremely biased, since I work on the performance team for one of the top technology companies on the web, and one that happens to care a lot about performance, but these resources are not hard to find. In addition, with the recent healthcare.gov fiasco, web performance is much more in the public eye, which should provide even more motivation for software engineers to get on the bandwagon.
How Do We Fix This?
If you have made it this far, hopefully you believe that there is a problem and that it should be fixed. The easy answer is to do more of what we are already doing - speaking, blogging, writing books, hosting meetups, and publishing case studies. This is all great, and we should do more of it, but it's clearly not working as well as we might like. I'd like to propose a couple of concrete things we could do differently that might help get the word out about performance:
First, The Data
Let's try to scope the problem. Using data from the HTTP Archive, we know that:
- Average PageSpeed score is still in the 70's
- Pages talk to 17 domains on average
- Only 44% of resources have proper caching headers
- 23% of resources are still uncompressed
Via Radware we know that pages are getting bigger and more complex, and that adoption of best practices is inconsistent and fairly weak. At this point people are quick to point to the Google study showing that the web is in fact getting faster, but this is primarily due to browser and network improvements, not due to website improvements. To quote the study, "it is still impressive given that the size of the web pages have increased by over 56% during this period". How much faster would the web be if we had browser, network, and content improvements?
I mentioned that I have had a few experiences recently that led me to write this post. First, I was recently speaking on a panel at a "Web Performance Day" for portfolio companies of a prominent VC firm in San Francisco. Steve Souders was giving the opening talk, and he opened with a scary comment. He mentioned that as he was putting his talk together, he surfed around some of the portfolio company websites so he could target his material to the audience members. He found that in the vast majority of cases, even the most basic optimizations were not being done. He was forced to alter his talk and give a "Performance 101" talk during which he dredged up slides from decks that he presented over 5 years ago. Yikes.
The second experience was during a recent episode of JavaScript Jabber. Alex MacCaw was talking about how he optimized monocle.io, and he mentioned Google's PageSpeed Insights tool. The tool was new to pretty much everyone on the show, and was a lot of "wow, this is so cool!". Remember, these are professional front-end web developers that are recording a podcast about JavaScript and front-end best practices in their free time. If they haven't heard of PageSpeed, and are getting surprised by some of the checks that it exposes, then we have a TON of work to do.
What Should We Expect?
Perhaps I am an idealist, but I think we should be able to get to 95%+ compliance with gzip. I don't expect every site to sprite all of their images (a best practice that SPDY/HTTP 2.0 will negate anyway), but I do expect every single site on the internet to figure out how to compress text resources. It's probably the easiest, most impactful, most well supported, and safest optimization that you can do.
This is just an example, but I think it is indicative of the problem, because we're only at 77% compliance with it. There are enormous benefits with literally zero downsides, and we still can't get a quarter of the sites on the internet to do it (and don't talk to me about CPU usage on shared hosting - if a host doesn't let you turn on gzip you should find another host).
The more concerning thing for me is that people expect new standards and browser improvements to come in and save us, like the aforementioned HTTP 2.0. While I'm extremely excited about HTTP 2.0, I worry that we will run into the same problem that we have today with gzip: it will take years to get up to a reasonable adoption point, even after the browser support is there.
When it comes to "what we should expect", I think understanding the core technologies behind the web and how to leverage them to build fast applications is a requirement for every single engineer. After all, speed is more than a feature, it's the most important feature. That's from the guy holding the purse strings, so it's worth taking to heart. If someone can't easily explain at least 3-5 performance best practices, to me that's equivalent to not being able to write a line of JavaScript. In other words, inexcusable if you work on the web as a developer.
Are There Enough Resources For Developers?
Yes. Perhaps we could do a better job about getting them in front of people early and often, but the[1] number[2] of[3] tools[4] and[5] resources[6] is[7] staggering[8] (I[9] could[10] do[11] this[12] all[13] day[14]). I'm obviously extremely biased, since I work on the performance team for one of the top technology companies on the web, and one that happens to care a lot about performance, but these resources are not hard to find. In addition, with the recent healthcare.gov fiasco, web performance is much more in the public eye, which should provide even more motivation for software engineers to get on the bandwagon.
How Do We Fix This?
If you have made it this far, hopefully you believe that there is a problem and that it should be fixed. The easy answer is to do more of what we are already doing - speaking, blogging, writing books, hosting meetups, and publishing case studies. This is all great, and we should do more of it, but it's clearly not working as well as we might like. I'd like to propose a couple of concrete things we could do differently that might help get the word out about performance:
- Every tech conference should have at least one talk that focuses on performance.
- Every company with an engineering blog should publish a post about performance (and ideally how it affects their bottom line).
- Every college with a CS department should offer a course that focuses on web performance (or at least part of a course). Kudos to Stanford for doing this.
- We should write more books with the "High Performance" prefix. Steve Souders has mentioned in the past that he would like to see this, and a few have come out recently (like Ilya's excellent book), but we should do even more. I'd love to see a "High Performance Ruby on Rails" book, as one example.
If you have the ability to influence any of the points above, please do so. With our mobile future rapidly approaching, performance is more important than ever. We will be stuck with 3G and 4G for decades, so networks aren't going to save us. There's a limit to what browsers can do given certain latency and bandwidth constraints, and when you look at how quickly page complexity is rising, it's not hard to imagine the web getting slower and slower over time. That's not a future that I want, so let's work together to build the tools, resources, and infrastructure that's necessary to make the web faster.
[1] Google Best Practices
[2] WebPagetest Forums
[3] Yahoo Performance Rules
[4] Web Performance Today Best Practices
[5] Perf Planet Advent Calendar
[6] High Performance Browser Networking
[7] High Performance JavaScript
[8] Velocity Conference
[9] HTTP Archive
[10] The Top 22 Web Performance Posts of 2013 (New Relic)
[11] Web Performance Today Podcasts
[12] Even Faster Websites
[13] YSlow
[14] Compuware Ajax Edition
[1] Google Best Practices
[2] WebPagetest Forums
[3] Yahoo Performance Rules
[4] Web Performance Today Best Practices
[5] Perf Planet Advent Calendar
[6] High Performance Browser Networking
[7] High Performance JavaScript
[8] Velocity Conference
[9] HTTP Archive
[10] The Top 22 Web Performance Posts of 2013 (New Relic)
[11] Web Performance Today Podcasts
[12] Even Faster Websites
[13] YSlow
[14] Compuware Ajax Edition
Comments
Post a Comment