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!
{ 8 comments… read them below or add one }
More on SPDY. Subbu @sallamar sheds some light on the kind of Websites/Domains for which SPDY is most beneficial. http://t.co/0Qcs635j
good stuff about how to speed up things on the web by @sallamar http://t.co/ofU4NokT ; #HTTP #SPDY #REST
Subbu, great writeup, and very interesting results!
For your comment about “undoing the domain sharding”, there is actually a proposal for SPDY v4 to allow cross-origin connection sharing (to “undo the damage” done by the sharding): https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/Lu8XpKhl2h8
Thanks for the pointer. Looks very promising.
Not as SPDY as You Thought http://t.co/U9MgucT2 And Subbu’s related post http://t.co/v8x2LS9a
“Want SPDY?” http://t.co/UId64R5P
Want SPDY?: submitted by bread_the_bread [link] [comment] http://t.co/IiPMG953
Excellent article: RT @sallamar: IME, those 3rd party domains are the likely bottlenecks http://t.co/lmnF166S http://t.co/5la4S1Gc