HTTP/2 下是否不需要再合并 CSS 文件了？

1. 同一个域名和端口，没必要。另外需要客户端支持。目前客户端支持率应该在 80%-90%之间了吧。
2. 不懂前端，理论上应该没什么区别吧，会有依赖关系吗？

还是会有差异的。http2 只不过是复用了连接而已。如果你不合并，还是要读取若干小文件，也是有开销的。只不过可能性能差异不明显。能合并还是合并吧。

你算一下合并和不合并的 gzip 压缩率，可能会有些发现

@otakustay 这个角度真相了

@otakustay 真相，值得研究

@otakustay 但是如果用 brotli 的话会好一点

要优化到这种程度的话：
1. 上 CDN，源站给最高压缩率。CDN 会缓存压缩后的版本，还省掉压缩耗时。
2. 使用 gzip_static 和 br_static，发布时最高压缩率压缩到磁盘。1) 对于 gzip 这种，压缩文件和流式压缩的压缩率差不少的，br 这种预置字典的可能差别不大。2) 使用 gz_static br_static 模块，sendfile 功能是有效的，零拷贝，性能比即时压缩好很多。
3. 磁盘性能没关系，Linux 有 cache，内存足够都是从 cache 读的。



最后，你就会发现根本就是然并卵。

@otakustay 请教 gzip 压缩 10 个 10k css 和一个 100k css 压缩率有啥区别？（本以为文本内容相同的话压缩率是一样的）

4. 还有 TLS v1.3 0-RTT 少不了吧
5. HTTP2 Server Push 也必须给上

看文件内容是不是经常变了。粒度小的话缓存效果好，但也如楼上所说，压缩率可能会有牺牲

@nikoo
1. gzip 用字典压缩，内容更多通常字典能更高效。事实上 10K 和 100K 的文本内容有可能相同吗……
2. 字典本身占空间

前几天刚被面试过类似的问题。私以为 1*100kb 能比 10*10kb 节省几个数据报文…… emmm，当然，楼上也提到了 gzip 的压缩率的问题。

根据 nginx 和 Cloudflare 的建议，http2 下不要合并 css，合并只会降低速度。因为不合并在 http2 下是多个并发请求，合并后变成单个只能单请求