让我们澄清一些事情:
我的理解是http2使文件串联等优化技术有点过时了，因为使用http2的服务器只发送一个请求。
HTTP/2使得像文件串联这样的优化技术有点过时了，因为HTTP/2允许多个文件通过同一连接并行下载。在HTTP/1.1中，浏览器可以请求一个文件，然后必须等待该文件完全下载才能请求下一个文件。这导致出现了解决方法，如文件合并（减少所需文件数）和多个连接（允许并行下载的hack）。
但是还有一个反方面的论据，即仍然存在多个文件的开销，包括请求它们，缓存它们，从缓存中读取它们等等。HTTP/2中大大减少了这些问题，但并未完全消除。此外，对于较大的文件，用gzip压缩文本文件比单独压缩大量小文件更有效。然而，我个人认为这些问题的弊端超过了好处，一旦HTTP/2普及，我认为串联将会消失。
相反，我看到的建议是把文件大小保持较小，以便浏览器更容易缓存。
这可能取决于网站的大小，但是如果使用http2并想专注于缓存，网站的文件应该有多小？
文件大小不影响是否能被缓存（除非我们谈论真正大于缓存本身的巨大文件）。将文件分成较小的块更好地用于缓存，这样如果您进行任何更改，则仍未触及的任何文件仍可以从缓存中使用。如果您的所有JavaScript（例如）都在一个大的.js文件中，并且您更改了一行代码，则整个文件都需要重新下载-即使它已经在缓存中。
同样地，如果您有一个图片精灵图，则可降低在 HTTP/1.1 中单独下载图像的数量，但如果您需要编辑它以添加一张额外的图片，则需要重新下载整个精灵文件。更不用说这个整个文件会被下载 - 即使对于仅使用其中一个图片精灵的页面也是如此。
然而，虽然这样说，但有一种思路认为，长期缓存的益处被夸大了。请参阅本文，特别是关于HTTP缓存的部分，它表明大多数人的浏览器缓存比你想象的要小，因此你的资源不太可能被缓存太久。这并不是说缓存不重要 - 而是更有用于在该会话中浏览网站，而不是长期使用。因此，每次访问您的网站都可能会再次下载所有文件 - 除非他们是非常频繁的访客，拥有非常大的缓存，或者不经常浏览网站。
对于那些不支持http2的浏览器用户，连接文件是否仍然有好处？
可能。然而，除了 Android 之外，HTTP/2 浏览器支持实际上非常好，因此大多数访问者已经启用了 HTTP/2。
说到这里，在HTTP/1.1下已经存在的合并文件的额外缺点在HTTP/2下并不存在。也许可以争论一些小文件可以在HTTP/2上并行下载，而较大的文件需要作为一个请求来下载，但我不认为这会显著减慢下载速度。虽然没有证据支持这一点，但直觉告诉我们数据仍然需要发送，所以无论如何都会有带宽问题，或者没有带宽问题。此外，尽管在HTTP/2中大大降低了请求多个资源的开销，但仍然存在。对于大多数用户和站点来说，延迟仍然是最大的问题，而不是带宽。除非您的资源真的非常庞大，否则我怀疑您是否能注意到在HTTP/2中将1个大资源分割为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技术和理解仍然很新，并且需要对某些网站进行一些调整。似乎没有免费的午餐！这篇文章值得一读，但请记住，这是一个极端的例子，大多数网站在性能方面受到延迟问题和连接限制的影响远大于带宽问题。
