5 ms·

If you're gzipping/deflating your HTTP connections, 100 304 response headers are not going to be your bandwidth bottleneck. Even if you are not, a 304 response

by mustpax 17y ago

If you're gzipping/deflating your HTTP connections, 100 304 response headers are not going to be your bandwidth bottleneck. Even if you are not, a 304 response has at most like 200 characters in it, 200 x 100, 20 kilobytes in headers responses, not exactly earth shattering. Since you brought up the caching issue, when you change any resource in the bundle, you are going to have to redownload the whole bundle. The bigger the bundle the more likely that one of the resources inside might need to be updated over time. With pipelining you only have to retransmit modified resources. This is not even considering the higher likelihood that larger objects have of getting thrown out of the cache. Also, most of the overhead in establishing a connection over a non-negligible latency internet connection is in the TCP handshake. Not in the time spent transmitting a few packets of headers.

mbrubeck 17y ago
Note that HTTP content-encoding does not compress headers, so gzip compression will have no effect on responses with status 304 (or on request headers). Your other points are good ones, which is why I said that bundling beats pipelining in some ways. Obviously you should measure your real-world use cases and performance before deciding.
sho 17y ago
The size of the headers response is not the issue. It's the latency of going and getting each one, and remember web browsers typically have a limited concurrency to any one domain. You're not going to be firing off a big batch of requests in parallel and getting the responses a second later, you're going to have three or so worker processes chewing through 30 requests each in serial. The situation becomes even worse with TLS, in which the handshake is even more of a time sink. Too many requests on an https page is absolute death for performance! This technique could really help that. Pipelining would certainly help, though, if and when it finally "arrives".

by mustpax 17y ago

mbrubeck 17y ago

Note that HTTP content-encoding does not compress headers, so gzip compression will have no effect on responses with status 304 (or on request headers). Your other points are good ones, which is why I said that bundling beats pipelining in some ways. Obviously you should measure your real-world use cases and performance before deciding.

sho 17y ago

The size of the headers response is not the issue. It's the latency of going and getting each one, and remember web browsers typically have a limited concurrency to any one domain. You're not going to be firing off a big batch of requests in parallel and getting the responses a second later, you're going to have three or so worker processes chewing through 30 requests each in serial. The situation becomes even worse with TLS, in which the handshake is even more of a time sink. Too many requests on an https page is absolute death for performance! This technique could really help that. Pipelining would certainly help, though, if and when it finally "arrives".