文档介绍：让 javascript 跑得更快下一代 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 ) 能提高效率,可在下载时为提高性能还得合并文件。不过,只要给 build 系统(把开发代码变成产品代码的工具集,是为部署准备的)加点东西,就没什么问题了。对于有着不同开发和产品环境的应用来说,用些简单的技术可以让代码更好管理。在开发环境下,为使条理清晰,代码可以分散为多个逻辑部分( ponents )。可以在 Smarty (一种 php 模板语言)里建立一个简单的函数来管理 javascript 的下载: <?php SMARTY :{ insert_js files = ",," } PHP : function smarty_insert_js ( $args ){ foreach ( explode (‘,‘, $args [‘ files ‘]) as $file ){ echo "<script type=\"text/javascript\" SOURCE=\"/javascript/$file\"></script>\n" ; }} OUTPUT :< script type = "text/javascript" SOURCE = "/javascript/" ></ script > < script type = "text/javascript" SOURCE = "/javascript/" ></ script > < script type = "text/javascript" SOURCE = "/javascr