4 ms·

Ehh, I just got 10.91s load time in Chrome 53 from Colorado, USA. Image of Chrome Dev Tools: https://reportcards.scdn3.secure.raxcdn.com/assets/uploads/files/c

Ehh, I just got 10.91s load time in Chrome 53 from Colorado, USA. Image of Chrome Dev Tools: https://reportcards.scdn3.secure.raxcdn.com/assets/uploads/files/company/452e0fdee5904b10046de11c0f7bfccb.png https://reportcards.scdn3.secure.raxcdn.com/assets/uploads/f... As an aside, does HTTP/2 provide any benefit for a single HTML file with no external assets?

niftich 10y ago
Nope. If you're done in one HTTP round-trip, your HPACK state has to push brand-new headers, you benefit nothing from server-side push (if it's even enabled), there's nothing to pipeline, so don't benefit from multiplexing and head-of-line blocking is a non-issue.
PunchTornado 10y ago
nope, it doesn't
toast0 10y ago
http/2 implies ALPN (but you can also do ALPN with http 1.x), which many browsers use as a flag to enable TLS Fast Start, and save one round trip.
mrb 10y ago
HTTP/2 header compression is one benefit that helps even it you have just 1 request.
- niftich 10y ago
  I want to benchmark this, because intuitively I disagree. The HPACK spec is a pretty easy read [1]. There is a static, hardcoded table that contains most of the HTTP header names, and even some common predefined KV pairs. You save some bytes on the wire if your header's name or value is one of these entries; the header name will essentially always will be in the static table. But for names and values that aren't in the static table, you have to put them into the dynamic table and encode them using either the integer packing or the huffman code. The client has to decompress these, of course. On future requests, you have some leftover state in your dynamic table so future 'duplicate' headers are packed, and take up very little space. But for the first (ever) HTTP request-response pair, you have to trade ALL the headers in "full". So the true benefits of the dynamic table don't kick in. [1] https://http2.github.io/http2-spec/compression.html#header.encoding https://http2.github.io/http2-spec/compression.html#header.e...

niftich 10y ago

Nope. If you're done in one HTTP round-trip, your HPACK state has to push brand-new headers, you benefit nothing from server-side push (if it's even enabled), there's nothing to pipeline, so don't benefit from multiplexing and head-of-line blocking is a non-issue.

PunchTornado 10y ago

nope, it doesn't

toast0 10y ago

http/2 implies ALPN (but you can also do ALPN with http 1.x), which many browsers use as a flag to enable TLS Fast Start, and save one round trip.

mrb 10y ago

HTTP/2 header compression is one benefit that helps even it you have just 1 request.

niftich 10y ago
I want to benchmark this, because intuitively I disagree. The HPACK spec is a pretty easy read [1]. There is a static, hardcoded table that contains most of the HTTP header names, and even some common predefined KV pairs. You save some bytes on the wire if your header's name or value is one of these entries; the header name will essentially always will be in the static table. But for names and values that aren't in the static table, you have to put them into the dynamic table and encode them using either the integer packing or the huffman code. The client has to decompress these, of course. On future requests, you have some leftover state in your dynamic table so future 'duplicate' headers are packed, and take up very little space. But for the first (ever) HTTP request-response pair, you have to trade ALL the headers in "full". So the true benefits of the dynamic table don't kick in. [1] https://http2.github.io/http2-spec/compression.html#header.encoding https://http2.github.io/http2-spec/compression.html#header.e...