Adaptability: SPDY works well for both cases, rather than only picking one case and optimizing for that case alone. I see quite a bit of value in optimizing SPDY for a pile of short single-request connections to sites, as well as optimizing for numerous requests to the same site. Google's own site will serve numerous examples of both; see below.
> On a first request only. You visit some site and only check if exactly one resource? Not likely. In any case, the cost to transfer 100 bytes once is irrelevant in any grand scheme of things.
It costs nothing to initialize the compressor state differently, and saves 100+ bytes per initial request/response.
A quick search suggests that Google services several billion searches per day. Assume for the moment that a substantial fraction of those searches come from user agents that don't already have an open connection to Google. Starting the compressor out with a specific state based on a prefix dictionary costs nothing (just changing the initial state of the compressor), but saves 100+ bytes per initial request/response. So, just for Google alone that change could save on the order of 100GB of traffic per day, for something that costs browsers and servers nothing to do. Now multiply that out for every other site on the Internet.
And for a different approach, consider the total number of initial connections that take place on GSM/3G networks every day.
More importantly than bandwidth, saving 100 bytes provides a potentially substantial latency benefit for the initial response, making it that much more likely to fit into a single frame rather than fragmenting.
If SPDY can save 100 bytes for free, why not do it?
> http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf
Thanks for the reference!
That paper seems to compare their proposed dictionary to "SPDY’s current default initial dictionary", which as far as I can tell means the prefix dictionary from some iteration of SPDY, rather than zlib's default. I don't think the paper provides statistics on how much a prefix dictionary saves over not having one at all.
> The dictionary construction part is suspect though... take a look at how many times the same string length count (\0\0\0\4 for example) occurs in the prefix -- this can't be optimal.
I agree that the default dictionary could probably use work. That kind of work seems like the most likely reason for the several versions of prefix dictionaries that have appeared so far, which you complained about in a previous comment. :)