3 ms·
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
by TobyGiacometti 9y ago
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-of-http-2/ https://blog.cloudflare.com/hpack-the-silent-killer-feature-...
- merb 9y agoI 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
- TobyGiacometti 9y ago> 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.