Using CloudFlare to mix domain sharding and SPDY

blog.cloudflare.com

37 points·jgrahamc··10 comments

This reminds me that the domain wildcarding we do for thumbnails probably isn't necessary anymore thanks both to SPDY but mainly how many parallel connections browsers open these days...

We only do this on the imageboards though -- not the front page.

It's been good practice for years now to place static assets on a separate domain to reduce cookie traffic. In some cases, the website owner can't control which cookies are set on the root domain (e.g., Google Analytics sets cookies on the root, not on the subdomain the page is served from).

Doesn't sharing the root domain (jgc.org in this case) partially negate this advantage?

Yes, but SPDY does compression of headers and so the same cookie being sent should be compressed.

On non-SPDY connections, it won't be, correct? Seems like the best approach might be to simply serve different static asset URLs based on User-Agent sniffing.

Another example from 4chan: http://chrishateswriting.com/post/68794699432/small-things-a...

Can someone explain why one DNS lookup was enough?

One DNS lookup per domain name. And once you know the IP, there's little point looking it up again as it's not going to change in the milliseconds between HTTPS/SPDY requests.

from the article: "In Chrome there was only a single TCP connection and a single DNS lookup needed despite the presence of three domains."

See cloudflare's answer to my original question.

See: http://calendar.perfplanet.com/2013/spdy-domain-sharding/#co...

Interesting. Does this mean that Chrome actually issues those requests over that single SPDY connections on the assumption that it belongs there without first waiting for the confirmation from the DNS servers? (And then not using the corresponding responses until it gets the DNS confirmations?)

Reply on news.ycombinator.com