我们的网站正在考虑切换到http2。
我的理解是，http2会使文件连接等优化技术过时，因为使用http2的服务器只发送一个请求。
相反，我看到的建议是最好保持较小的文件大小，这样它们更有可能被浏览器缓存。
这可能取决于网站的大小，但如果网站使用http2并希望专注于缓存，那么它的文件应该有多小？
在我们的例子中，我们的许多单独的js和css文件都在1kb到180kb的范围内。Jquery和bootstrap可能更多。累积起来，我们网站上一个页面的新下载量通常小于900kb。
所以我有两个问题：
这些文件大小是否足够小，可以被浏览器缓存？
如果它们足够小，可以缓存，那么对于使用不支持http2的浏览器的用户来说，无论如何连接文件是不是很好。
在这种情况下，拥有更大的文件大小并使用HTTP2会有伤害吗？这样，运行这两种协议的用户都会受益，因为站点可以针对http和http2进行优化。
让我们澄清一些事情：
我的理解是http2会使文件连接等优化技术过时，因为使用http2的服务器只发送一个请求。
HTTP/2使优化技术(如文件串联)有些过时，因为HTTP/2允许在同一连接上并行下载许多文件。以前，在HTTP/1.1中，浏览器可以请求一个文件，然后必须等到该文件完全下载后才能请求下一个文件。这导致了一些变通方法，如文件串联(以减少所需的文件数量)和多个连接(允许并行下载的黑客攻击)。
然而，有一个相反的论点是，多个文件仍然存在开销，包括请求、缓存、从缓存中读取。。。等等。它在HTTP/2中大大减少了，但并没有完全消失。此外，对文本文件进行gzip封装比单独对许多较小的文件进行gzig封装更适用于较大的文件。然而，就我个人而言，我认为缺点大于这些担忧，并且我认为一旦HTTP/2无处不在，级联就会消亡。
相反，我看到的建议是，最好保持文件大小较小，这样它们更有可能被浏览器缓存。
这可能取决于网站的大小，但如果网站使用http2并希望专注于缓存，那么它的文件应该有多小？
文件大小与是否缓存无关(除非我们谈论的是比缓存本身大的真正巨大的文件)。将文件分割成更小的块更适合缓存的原因是，如果您进行了任何更改，那么任何未被触摸的文件都可以从缓存中使用。如果你把所有的javascript(例如)放在一个大的.js文件中，并且你更改了一行代码，那么整个文件就需要再次下载——即使它已经在缓存中了。
类似地，如果你有一个图像精灵图，那么这对于减少HTTP/1.1中的单独图像下载非常好，但如果你需要编辑整个精灵文件以添加一个额外的图像，则需要再次下载整个精灵文件。更不用说整个的东西都被下载了——即使是那些只使用其中一个图像精灵的页面。
然而，尽管如此，有一种观点认为，长期缓存的好处被夸大了。请参阅本文，特别是关于HTTP缓存的部分，它显示大多数人的浏览器缓存比您想象的要小，因此您的资源不太可能被缓存很长时间。这并不是说缓存不重要，而是说它对在会话中浏览而不是长期浏览很有用。因此，每次访问你的网站都可能会再次下载你的所有文件——除非他们是非常频繁的访问者，有很大的缓存，或者不经常上网。
对于使用不支持http2的浏览器的用户来说，无论如何连接文件都很好吗。
可能。然而，除了在Android上，HTTP/2浏览器支持实际上非常好，所以你的大多数访问者可能已经启用了HTTP/2。
也就是说，在HTTP/2下连接文件没有额外的缺点，而在HTTP/1.1下则没有。好吧，可以说，许多小文件可以通过HTTP/2并行下载，而一个较大的文件需要作为一个请求下载，但我不认为这会降低速度。没有证据表明这一点，但直觉表明数据仍然需要发送，所以你要么有带宽问题，要么没有。此外，尽管HTTP/2大大减少了请求许多资源的开销，但仍然存在。对于大多数用户和网站来说，延迟仍然是最大的问题，而不是带宽。除非你的资源真的很大，否则我怀疑你是否会注意到在I've go中下载1个大资源，或者在HTTP/2中将相同的数据拆分为10个并行下载的小文件(尽管你在HTTP/1.1中会这样做)之间的区别。更不用说上面讨论的gzip问题了。
所以，在我看来，继续串联一段时间也无妨。在某种程度上，你需要判断用户档案中的负面影响是否大于好处。
在这种情况下，拥有更大的文件大小并使用HTTP2会有伤害吗？这样，运行这两种协议的用户都会受益，因为站点可以针对http和http2进行优化。
绝对不会有任何伤害。如上所述，在HTTP/2下连接文件(基本上)没有额外的缺点，而在HTTP/1.1下则没有。在HTTP/2下，它不再那么必要了，而且有缺点(可能会减少缓存使用，需要构建步骤，由于部署的代码与源代码不同，调试变得更加困难……等等)
使用HTTP/2，你仍然会看到任何网站都有很大的好处——除了最简单的网站，这些网站可能没有改进，但也没有负面影响。而且，由于旧的浏览器可以坚持HTTP/1.1，所以它们没有缺点。何时或是否决定停止实现HTTP/1.1性能调整(如级联)是一个单独的决定。
事实上，不使用HTTP/2的唯一原因是，实现仍然相当前沿，所以您可能还不愿意在它上运行您的生产网站。
****编辑2016年8月***
这篇来自一个图片量大、带宽受限的网站的帖子最近引起了HTTP/2社区的一些兴趣，因为它是HTTP/2实际上比HTTP/1.1慢的第一个有记录的例子之一。这突出了一个事实，即HTTP/2技术和理解仍然是新的，需要对一些网站进行一些调整。似乎没有免费午餐这回事！值得一读，但值得记住的是，这是一个极端的例子，大多数网站在性能方面受到HTTP/1.1下的延迟问题和连接限制的影响要大得多，而不是带宽问题。