well the article is not 100% right, cause I still need to send a header for every file. so if I concat 100 files it and send it, I only need to send one header. while if I send 100 files I have 100 headers, while it probably is not much (especially not in HTTP/2) it's still an overhead, so your mobile users will not be happier with many small files.
HTTP/2 uses compressed headers (this was often considered a problem with HTTP/2 by detractors because the headers are a compressed binary block that need to be decompressed and decoded to be read) and the benefits of smarter item caching still mostly outweigh concatenation in HTTP/2.
This same also applies to the author's own Caveat section (that large concatenated files compress better than a collection small files) because the entire stream is compressed roughly in the same single compression stream, which while not as well optimized as the case where the compression has access to optimize a single full file, should adapt better to give better performance with lots of individual files in the stream than compressing them all directly as individual files.
Thank you for your feedback! I tried to keep the article as simple as possible, so I have left out some details on purpose. Like WorldMaker pointed out, headers in HTTP/2 are compressed using HPACK which negates the issue you mention. More information: https://blog.cloudflare.com/hpack-the-silent-killer-feature-...
I know that, that's why I wrote better in HTTP/2, but you still need to transfer more data. no matter how it's compressed you still have data. while on the other side you have not. actually in your cloudflare blog post you also see that they save up to 15%. well meaning the more files you send the better it gets, but you never can eliminate it. keep also in mind that for every "SETTINGS_MAX_CONCURRENT_STREAMS" size the HPACK compression might be equal.
also many small files means that you not just send more header frames, also the whole chatty http/2 protocol sends more data. http/2 is chatty and stateful, that's something people should know about. so the best possible outcome is probably do concat, but don't be so aggressive than on http/1 do concat more when you have more mobile users since http/2 does not fix their mean latency and their bad bandwidth
> headers in HTTP/2 are compressed using HPACK which negates the issue you mention
You are right, my statement is not correct. It certainly does not completely negate the overhead of additional headers. It does greatly reduce it though. So far, I have only heard of compression inefficiency being a real problem when not concatenating. Do you have some examples of header overhead actually being a real issue? Would be happy to update the post.
6 comments
[ 2.7 ms ] story [ 23.3 ms ] threadThis same also applies to the author's own Caveat section (that large concatenated files compress better than a collection small files) because the entire stream is compressed roughly in the same single compression stream, which while not as well optimized as the case where the compression has access to optimize a single full file, should adapt better to give better performance with lots of individual files in the stream than compressing them all directly as individual files.
also many small files means that you not just send more header frames, also the whole chatty http/2 protocol sends more data. http/2 is chatty and stateful, that's something people should know about. so the best possible outcome is probably do concat, but don't be so aggressive than on http/1 do concat more when you have more mobile users since http/2 does not fix their mean latency and their bad bandwidth
You are right, my statement is not correct. It certainly does not completely negate the overhead of additional headers. It does greatly reduce it though. So far, I have only heard of compression inefficiency being a real problem when not concatenating. Do you have some examples of header overhead actually being a real issue? Would be happy to update the post.