For me, web browsing is still too slow. Despite a decade of intensive technology innovation and developer education and network infrastructure build out, it's frequently still way too slow. A cache-cleared visit to ESPN's home page today using a FIOS connection took Chrome 6.5 seconds to reach document complete. For a little perspective, what if it took your TV that long to change channels? Thanks to the impressive toolset at webpagetest.org we can see exactly what was visible at each second:
What was happening in that little eternity anyway? As you can see in this bandwidth utilization curve, my superfast FIOS connection is mostly idle:
Why isn't this 2 MB worth of ESPN content being transferred in 2 MB / 20 Mbps = 800 milliseconds? Why am I using only 12% of my available bandwidth? Can we fix this already?
Turns out many of us have collectively been trying to fix this for years. By now the tricks and tweaks to optimize page load time for a web developer are well established and widely available in books and blogs and how-to videos. There are services and products and tools and consultants to help you figure out how to use them. There's even a conference largely devoted to the many aspects of building a faster web that has been going strong since 2008. Making the web faster has become an industry unto itself, reflected in the diverse sponsorship of the web performance test site webpagetest.org:
Google in particular seems to uniquely grasp the tight connection between page load performance and the bottom line. In the last decade or so, Google replaced or enhanced all aspects of the page load performance stack: the browser with Chrome, the web server via PageSpeed, DNS through Google DNS, the transport through TCP protocol enhancements and promising next-gen efforts like QUIC, the security layer via new TLS features, and then the HTTP protocol itself via the development of SPDY and the adoption of its core features in HTTP/2 due out this year.
But this has been an industry-wide effort. Innovation in faster web over the last decade has occurred in a collaborative and open way, despite competitive tensions. This is reflected in the fact that most web browsers today are either completely open source or built on core open source components like Webkit. The result of all this hard work and idea sharing is that all web browsers are now widely perceived to be equally very fast. From the same recent NYTimes post:
"The more I used the new Firefox, the more I began to wonder if desktop web browsers had hit a kind of innovation plateau. [...] They’re now ferociously fast."
But then how to explain the dreadfully slow load time of our ESPN page? Or, let's try another site. How about Yahoo, which created the web performance analysis tool YSlow and so would presumably know how to create a very fast web site leveraging the latest browser features and best practices?
At the 4.5 second point, the leading image is just coming into view. I hope we don't have to plateau here. Overall Chrome downloaded the 1.5 MB of sports.yahoo.com content in about 5 seconds, which like ESPN is only using about 12% of my FIOS connection. Of course you'll say it's latency and chattiness and the laws of physics. This is understood. But can't we improve the protocol or the technology to better mitigate the impact of distance delay?
No doubt when the browser's cache comes into play and it can use preconnects, DNS prefetching, prerendering and other tricks, pages load pretty quickly. But even then, are they ferociously fast? Even TV fast? Either I'm an impatient guy or I drink too much coffee or just maybe because I understand too well the underlying dynamics, but I'm pretty sure I won't be satisfied with web page snappiness over fat pipes like FIOS until it feels essentially instant. And judging from the current user experience we've still got a long way to go.
This post is the first in a series on how I believe we can dramatically improve page load time. Next time I'll talk about the single biggest contributor to page load time for very high bandwidth networks. Hint: it's not latency.