>
> They shouldn't have to invent their own protocols because there are
> already plenty of protocols optimized for small-grained messages. That
> doesn't mean HTTP, which is one of the few protocols which is optimized for
> large-grained messages (in order to trade efficiency for scalability), has
> to change to become one of them.
>
I believe that would be a shortsighted call to make. Besides, show me
another protocol available in the browser, which *is* the distribution
platform for all these apps? It's HTTP, plain and simple.. or build on your
own, on top of WebSockets.
Median size per GET: 2.36KB -
https://developers.google.com/speed/articles/web-metrics
Add ~800 bytes of request/response headers on top, and we're spending
25-30% on headers (that is, if you're lucky and can avoid adding cookies to
that as well). Also, there is no sign that we're going to stop putting
*more* stuff into the headers. User-agent and Cookies are the best known
offenders, but what about even things like upcoming CSP suport?
X-Content-Security-Policy: allow 'self'; img-src *; \
object-src media1.com media2.com *.cdn.com; \
script-src trustedscripts.example.com
And that's just the beginning.
In any case, my meta-point is simple: I believe Patrick's numbers may
well underestimate the prevalence of short requests/responses. We should
factor in the long-lived apps that stay open in the browser and rely on
small periodic pings (aka, any "ajax" app like gmail, docs, and so forth,
not to mention the billions of beacons for analytics and the like).
ig
Received on Thursday, 16 August 2012 23:00:37 UTC