目前几乎所有JavaScript应用都会采用一套构建流程。即使不是转换ES2015或TypeScript，对代码做合并与压缩已经是标准做法。这么做的原因是发起一个HTTP请求包含不少代价。请求少量体积较大的文件比大量小文件效率更高。随着下一版本的web基础协议 HTTP/2的引入，或许是时候重新思考最佳实践了。
HTTP/2基于 Google的 SPDY 协议，该协议为改进现有的HTTP 1.1标准的页面加载延迟和提升安全性而开发。新版协议开始于2012年，第一个开发版本是SPDY协议的直接副本。最终标准发布于2015年五月，同年五月，Google宣布在Chrome中不再支持SPDY协议。
HTTP/2跟之前的协议有什么不同？一个主要的区别是，HTTP/2是一个二进制协议，不是基于文本的。这使得它更简洁、解析更高效，也更少出错。该协议的一个优势是多路复用，也就是多个文件可以在单个连接中传输。另外一个被吹捧的特性是服务端推送，这允许服务器向客户端传送资源。
对新协议的支持情况还不错，包括所有主流浏览器。服务器端的 Apache2、 Nginx 和微软的 IIS 都支持它，以及Node.js 5.0及以上版本。大部分浏览器厂商声明他们只支持TLS连接上的HTTP/2，尽管有了Let's Encrypt提供免费的SSL整数，这是个容易满足的条件。据W3Techs今年六月份收集的数据，排名前1000万的网站中大约有8.4%支持新协议。如果你是Chrome用户，以可以通过HTTP/2 和 SPDY 指示器扩展程序得知你所访问的网站哪些在用HTTP/2。
采用HTTP/2对JavaScript开发者来说意味着什么？ 我们目前把多个文件打包的做法让浏览器很难高效地缓存代码：在一个模块里改动一行代码也需要重新下载整个打包后的文件。随着HTTP/2的多路复用让请求变得不那么昂贵，我们可以选择把代码分割到小模块里，以更好地利用缓存，确保我们的应用高效地利用用户的带宽。
但是如果请求是廉价的，我们真的可以放弃打包文件了？ 乍一看似乎很合理，但是HTTP请求的成本并不是唯一需要考虑的因素。Web 服务器在如何有效地处理大文件上也是有限制的。随着JavaScript社区正在朝更小的、更专一的模块方向发展，给客户端提供未打包的文件也不太理想。除此之外，把文件合并在一起可以更好地压缩，节省带宽。
那么，什么时候你该考虑切换到HTTP/2呢？答案是：看情况。尽管浏览器支持情况不错，但如果你的目标用户仍然在用老掉牙的IE，那你就没那么幸运了。所以要查下你的访客统计数据，看看这么做是否能惠及到大部分用户。我从这一切得到的信息是，对新协议的支持和采用任重道远，作为开发人员，这是我们不能忽略的趋势。
你采用的打包策略是什么？你会考虑切换到HTTP/2吗？或者已经切换了？请在评论里告诉我！
