文档介绍：让 javascript 跑得更快
作者：Cal Henderson
下一代 web 应用让 javascript 和 css 得堪大用。我们会告诉你怎样使这些应用又快又灵。
建立了号称“Web ”的应用，也实现了富内容（rich content）和交互，我们期待着 css 和 javascript
扮演更加重要的角色。为使应用干净利落，我们需要完善那些渲染页面的文件，优化其大小和形态，以确
保提供最好的用户体验——在实践中，这就意味着一种结合：使内容尽可能小、下载尽可能快，同时避免
对未改动资源不必要的重新获取。
由于 css 和 js 文件的形态，情况有点复杂。跟图片相比，其源代码很有可能频繁改动。而一旦改动，就需
要客户端重新下载，使本地缓存无效（保存在其他缓存里的版本也是如此）。在这篇文章里，我们将着重
探讨怎样使用户体验最快：包括初始页面的下载，随后页面的下载，以及随着应用渐进、内容变化而进行
的资源下载。
我始终坚信这一点：对开发者来说，应该尽可能让事情变得简单。所以我们青睐于那些能让系统自动处理
优化难题的方法。只需少许工作量，我们就能建立一举多得的环境：它使开发变得简单，有极佳的终端性
能，也不会改变现有的工作方式。
好大一沱
老的思路是，为优化性能，可以把多个 css 和 js 文件合并成极少数大文件。跟十个 5k 的 js 文件相比，合
并成一个 50k 的文件更好。虽然代码总字节数没变，却避免了多个 HTTP 请求造成的开销。每个请求都会在
客户端和服务器两边有个建立和消除的过程，导致请求和响应 header 带来开销，还有服务器端更多的进程
和线程资源消耗（可能还有为压缩内容耗费的 cpu 时间）。
（除了HTTP请求，）并发问题也很重要。默认情况下，在使用持久连接（persistent connections）时，
ie和firefox在同一域名内只会同时下载两个资源（在HTTP 规格书中第节的建议）（htmlor注：
可以通过修改注册表等方法改变这一默认配置）。这就意味着，在我们等待下载 2 个js文件的同时，将无
法下载图片资源。也就是说，这段时间内用户在页面上看不到图片。
（虽然合并文件能解决以上两个问题，）可是，这个方法有两个缺点。第一，把所有资源一起打包，将强
制用户一次下载完所有资源。如果（不这么做，而是）把大块内容变成多个文件，下载开销就分散到了多
个页面，同时缓解了会话中的速度压力（或完全避免了某些开销，这取决于用户选择的路径）。如果为了
随后页面下载得更快而让初始页面下载得很慢，我们将发现更多用户根本不会傻等着再去打开下一个页面。
第二（这个影响更大，一直以来却没怎么被考虑过），在一个文件改动很频繁的环境里，如果采用单文件
系统，那么每次改动文件都需要客户端把所有 css 和 js 重新下载一遍。假如我们的应用有个 100k 的合成
的 js 大文件，任何微小的改动都将强制客户端把这 100k 再消化一遍。
分解之道
（看来合并成大文件不太合适。）替代方案是个折中的办法：把 css 和 js 资源分散成多个子文件，按功能
划分、保持文件个数尽可能少。这个方案也是有代价的，虽说开发时代码分散成逻辑块（logical chunks）
1
能提高效率，可在下载时为提高性能还得合并文件。不过，只要给 build 系统（把开发代码变成产品代码
的工具集，是为部署准备的）加点东西，就没什么问题了。
对于有着不同开发和产品环境的应用