Web performance is a complex topic with many contributors to poor latency. Of all the bottlenecks to site speed, HTTP traffic interests me the most. We know that both Google and Twitter run their primary domains on SPDY for performance reasons. But does this approach make sense for other sites? Here is my observation from the data collected for a very small set of domains – SPDY makes most sense for domains that meet two criteria – those that serve a large proportion of resources on a page, and those that consequently make the browser put requests in the “blocked” state for the longest time. For other domains it may not matter, which most likely explains Guy Podjarny‘s observations in Not as SPDY as You Thought earlier this week. SPDY’s multiplexing can help minimize blocked times.
See the charts below for some popular sites. Each chart shows two bars for the top five domains for the resources in a page (including the page’s domain itself) that meet the above criteria. The blue bar shows the number of resources per domain, and the red bar shows the average number of milliseconds that a request to each resource was in the “blocked” state. For a given resource, the difference between the time a connection is made to the time a request is made is the “blocked” time. You can find blocked times in HAR files. You can use a simple visualization tool I wrote to draw these charts for your HAR files.
Though a large blocked time does not necessarily mean that the user perceived latency is poor, it can be a contributor to latency particularly when the network is bad – like the time I captured this data. I captured the data for these sites when I was on a Hotel wifi network – I got lucky a couple of days ago as the hotel I stayed at had very low download speeds, and I could not get any other work done.
Here are my observations from these charts:
- In most cases, domains serving large number of static resources contribute to most of the blocked time. This is prominent on sites that change the content frequently or for each request (such as search, news etc.) due to their low cacheability.
- In most cases, such domains are hosted on homegrown or commercial CDNs, and so enabling SPDY on those domains will be a key contributor to SPDY adoption.
- Serving root domains of such sites over SPDY may not help, but serving those resource intensive domains over SPDY might.
- Undoing some or all of the domain sharding via SPDY capable domains will be necessary to take advantage of SPDY. This is because SPDY requires one connection per domain, and domain sharding may force the browser into making multiple connections to the same host.
Note that my tests are not scientific and my sample size is tiny. Caveat emptor!