Optimizing HTTP headers for ‘ajax’ webapps

http://blog.mibbit.com/?p=143

by ivanstojic • 18 years ago

58 20 18 years ago

blog.mibbit.com

tptacek• 18 years ago

Reminds me of:

http://cr.yp.to/sarcasm/modest-proposal.txt

jwilliams• 18 years ago

This is actually a good idea.

Google has already proposed a gzip content compression scheme that could operate over a number of pages.

It would also be feasible for them to come up with a header compression scheme - perhaps even in Chrome first.

axod7• 18 years ago

Agreed. I think a great option would be for the server to specify in a response header that it doesn't care about any headers for the rest of the keep-alive connection, unless they change.

X-Only-Send-Header-Changes: true

epi0Bauqu• 18 years ago

axod, I came across this the other day: http://axod.blogspot.com/

I've been getting into comet a bit more lately, and am wondering (if you don't mind telling of course) 1) what you are currently using on the backend and 2) if you ever checked out Meteor (which I was playing with today)?

jacobolus• 18 years ago

It would be much better still for them to implement WebSocket: this is a marginal optimization at best, while adopting WebSocket would be a fundamental improvement and would much more significantly reduce bandwidth, etc.

http://www.w3.org/html/wg/html5/#network

axod7• 18 years ago

Agreed. Not sure how long that will take though.

I'm not sure it's marginal though. Consider a site that has a gallery of 100 thumbnails, each one say 200 bytes in size.

With firefox3, the browser would have to send 49,500bytes of HTTP headers just to get those 100 thumbnails which are only 20,000bytes in size. That's a ridiculous overhead. Even if you're using deflate or gzip, that's only gzipping the 20k data, not the 49.5k of headers.

truebosko• 18 years ago

Nice trick and a quick read. Thanks

kwamenum862• 18 years ago

Interesting technique and could spur thought in optimization tangential js operations...but does 300 bytes really matter that much?

axod7• 18 years ago

as I say this will save mibbit 300GB/month So yes it does matter for me

kwamenum862• 18 years ago

Ah, good point. With computes 300 bytes, 300 milliseconds, and other seemingly minor values matter because they are multiplied by large numbers. Every bit counts all the time I guess if you have a high traffic web app.

patio11• 18 years ago

Sounds like premature optimization to me. You can't "save" bandwidth at the sub-packet level. It is like trying to "save" space used on files of less than a kilobyte in length -- you can do the math showing impressive theoretical gains, but other layers of your hardware/software stack process the data in chunks larger than that anyway, all your effort is for naught.

tlrobinson• 18 years ago

I don't think that's true. Bandwidth is typically the bottleneck, and AFAIK there's no minimum size (other than minimal headers) for HTTP, TCP, or IP protocols.

heyadayo• 18 years ago

@patio11: Actually, you can save bandwidth at the sub-packet level. Ethernet is a common link layer protocol that we can examine: It has a variable length frame, and because it uses time-delimited bit-level framing, the smaller your ethernet frame the quicker it can be sent. The only real caveat to axod's article is that you often can't save on performance of intermediary systems (routers) because they tend to pre-allocate blocks of memory for packets, so no memory is saved when some packets are smaller. But your ISP doesn't meter you at the link layer anyway (or often even the IP level), so the savings as reported by the article are absolutely real in terms of bandwidth costs. (as in money)

axod7• 18 years ago

Did you skip the bit where I said it would save mibbit 300GB/month transfer? That's worth doing.

I can see the confusion, but you can't compare files with network. Files are allocated in chunks. So shaving off a few bytes of a file does indeed not always save you disk space.

However, if you send half as many bytes in your HTTP headers, you save that bandwidth. If you handle 600 of those HTTP requests a second, shaving every byte off that you can, is important. That's not premature optimization.

est• 18 years ago

just use comet istead

axod7• 18 years ago

People seem to be terribly confused as to what Comet is.

This is Comet if you really want to use that word. Comet goes over HTTP.

e1ven2• 18 years ago

I suspect that his point is-

Using long-lifed connections, and sliding more data through as time goes on, avoids some of the overhead of additional HTTP headers that you see in opening new requests and replies.

Optimizing HTTP headers for ‘ajax’ webapps

Related Stories