I spent this past week at O’Reilly Velocity Conference, a three day conference which focuses on web performance and devops. I plan to write, with care, several articles this week on the key topics covered at the conference, but this is not one of those articles. This is just a rant.
At some point recently, I feel like I exited Plato's cave of slow web and realized how much faster the websites I was building could be. Since then I have put a lot of care into the performance in everything I build. Performance was always part of my concern, but for the web, I feel now more than ever like it is everything. People are not going to wait around for your slow website. It has been hard to shake the performance addiction, and I feel the need to evangelize on the topic.
Since exiting the proverbial cave, in addition to the focus on performance in my own web development, I have paid attention to the kinds of expectations people have about their websites’ speed and render performance, how they describe "good" performance. I have found that people talk in terms of seconds, especially when discussing poor network condistions. This is crazy to me. Our low bar is leaving people to wait around with a blank white screen when the content being delivered could probably be sent over the wire in a matter of milliseconds with the right engineering focus on eliminating latency bottlenecks. A lot of this is about third-party scripts like ads and split tests. Maybe some of these decisions are out of your control as a developer, and maybe you are too busy frantically bailing water from your flooding boat to care about the true potential performance of your website, but if you get the opportunity to spread the good word about performance, please do.
This site, dev.to, is far from perfect, but I have put a lot of care into its rendering performance, at least. I have written a bit about this in the past, and I will write about it more in the future, but right now I just want to do a side-by-side comparison between similar “content” sites. I may do a more scientific benchmark in the future, but for now I am just presenting filmstrip diagrams of a bunch of websites for your reading pleasure. They were all taken in the same conditions with cache disabled to simulate a fresh visit every time, all on article pages within the site. This is a biased-as-hell comparison meant, in part, to glorify my website, but content sites live and die by how quickly they render and some shaming is in order. If you're reading this on mobile, the graphics might be quite small, but you should still be able to get the gist.
Speaking of living and dying, if the web cannot get its shit together, Facebook Instant Articles and other powerful central bodies will eat up even more of it and soak up a lot of the profit in doing so. The web itself could be “instant” but in its current state, it is not. None of the websites I am demonstrating here are particularly bad offenders, but sites, the way we typically build them today, are slow as hell and they do not need to be.
CNN
Mic
ESPN
Yahoo
Fox News
BuzzFeed
TechCrunch
Medium
Dev.to
That was an eye-popping best-case example. The fact that the page can ever be readable in 13ms is incredible, but that does not happen every time. Here is another result:
Performance on this website is measured in milliseconds, and the expectation is that things should remain good under harsh network conditions. These results are achievable if you make it a priority.
In conclusion
The web is slow. It was not meant to be slow and it does not have to be slow, but it is. The things that make the web slow, like third-party scripts, are not the only way to advertise, the only way to split test, or the only way to track. If we start caring about the user experience and treat performance as a key part of that, we, the web will be a lot better, not to mention the fact that much of the web is basically unusable in many developing nations due to its bloat, but that is its own rant.
There is a lot of talk of HTTP/2, service workers, and other new innovations and standards. These are all well and good, but are not going to be the silver bullet. The only way to make the web faster is to make it a priority and raise our expectations about how fast the web could be.
Top comments (0)