JavaScript的执行速度取决于代码的编写方式，本文就主要介绍几种实现JavaScript提速的方法。

    1、管理作用域非常重要，因为存取非局部变量要比局部变量耗时更多。尽量避免使用会增长作用域链的结构，比如使用with语句和try-catch语句中的catch从句。如果非局部变量的使用超过一次，那么为了降低性能耗损，就应该将它存储到一个局部变量中。

    2、存储和读取数据的方式对脚本性能影响极大。字面量和局部变量总是最快的；存取数组元素和对象属性会引起性能损耗。如果数组元素或对象属性的使用超过一次，那么为了提高存取速度，就应该将它存储到一个局部变量中。

    显然，我们所讲的带宽是指数据的发送速度，比如我们的百兆网卡，便是指网卡的最大发送速度为100Mbps，也就是网卡在1秒钟最多可以发出100Mb的数据。那么，我们当然希望发送速度越快越好，究竟这个发送速度的大小和什么有关呢？简单地说，包括了一下几个因素。

    1、数据发送装置将二进制信号传送至线路的能力，也称信号传输频率，以及另一端的数据接收装置对二进制信号的接收能力，同时也包括线路对传输频率的支持程度。比如光纤一端的发射装置使用发光二极管（Light Emitting Diode,LED）或一束激光将光脉冲传送至光纤，光纤另一端的接收装置使用光敏元件检测脉冲，从而将脉冲中包含的二进制信息转换成数据。指的注意的是，信号的接收能力至关重要，如果接收能力跟不上，发送能力不可能提高，在星球火车系统的故事中，我们知道数据链路层对于数据帧传输控制机制完全是按照接收方的接收能力来确定发送速度的。

我们了解了互联网上两台主机之间数据发送和传输的整个过程，事实上，数据的响应时间不难得出：响应时间=发送时间+传播时间+处理时间。

    发送时间很容易计算，即“数据量/带宽”。比如要发送100Mbit的数据，而且发送速度为100Mbit/s，也就是带宽为100M，那么发送时间便为1s。值得注意的是，在两台主机之间往往存在多个交换节点，每次的数据转发，都需要花费发送时间，那么总的发送时间也包括这些转发时所花费的发送时间。

    传播时间主要依赖于传播距离，因为传播速度我们可以近似认为约等于2.0×108m/s，那么传播时间便等于传播距离除以传播速度。比如两个交换节点之间线路的长度为1000km，相当于北京道上海的直线距离，那么一个比特信号从线路的一端到另一端的传播时间为0.005s。

从反向代理缓存到负载均衡调度器，反向代理服务器不止一次出现在书中，而这一次，我们又将目光转向了它在文件复制领域的表现。

    事实上，反向代理机制本身就决定了它必须从后端服务器那里不断地复制内容到本地，而这种复制的触发条件，则是用户向反向代理服务器请求内容，我想这种方式也可以称为“动态同步”。

    那么，对于静态网页、图片等这些直接暴露给用户的内容来说，通过反向代理服务器实现远程复制，可能是一个更加简单有效的方式。而对于另一些无法由用户通过HTTP直接访问的文件，比如Web应用程序运行中需要的一些持续更新的配置文件，反向代理服务器对于它们的复制将无能为力，你仍然需要借助于前面介绍的复制方法。

Favicons是命名为favicon.ico的小图像，保存在网站根目录，可以显示在浏览器地址栏上，就在网络左面。

    这个页面组件经常被忽视，因为它很小，而且推测是可以被缓存的。但是缓存还没有像我们想象得那么普遍。对于任何组件都是这样，当然favicons也不例外。在所有页面中，只有9%使用它的favicon。

    对于favicon来说，有几点可以明显地提高性能：

    *确定建立了Favicon。因为不管怎么样，浏览器都会请求这个文件，没有什么理由返回一个404错误，尤其当你的404处理程序需要消耗数据连接或其他昂贵资源的时候。

AOL Pagetest和其Web版本WebPagetest都使用如下的最佳实践来分析网页：

    *启用浏览器缓存静态资源。
    *对所有的静态资源使用1个CDN。
    *合并静态CSS和JavaScript文件。
    *对所有适合的文本资源进行Gzip编码。
    *压缩图片。
    *使用持久连接。
    *正确使用Cookie。
    *精简JavaScript。
    *不采用ETag头。

优秀的Web开发者会尽全力让HTML、CSS和JavaScript变得尽可能精简，但是我们都会根据经验任由那些又长又重复的字符串存在，因为Gzip压缩会使它们基本上消失。因此，我们实际上没有在这上面做出足够的优化，当用户无法接收经过压缩的响应时，这种设想就毫无意义了。
这点貌似太明显而不值一提，但是实际上被强调的还不够：发送更小的响应会使页面加载速度更快。这也是为上面对于响应进行压缩是如此有效的技术，尽管这样做会在服务器端和客户端增加CPU的开销。优秀的Web开发者会尽全力让HTML、CSS和JavaScript变得尽可能精简，但是我们都会根据经验任由那些又长又重复的字符串存在，因为Gzip压缩会使它们基本上消失。因此，我们实际上没有在这上面做出足够的优化，当用户无法接收经过压缩的响应时，这种设想就毫无意义了。

当网站开始运营后，流量和用户会逐步增加，这是你需要在网站和用户之间建立长久和丰富的关系。

    在Web发展的早期，网站与用户关系的一个主要衡量指标是忠诚度，它表示用户经常返回该网站的频率。今日的用户可以通过很多社会化网络途径获取信息，比如RSS（Really Simple Syndication）源、邮件订阅、新闻组，所有这些方式都把信息直接推给用户，而不是他们主动请求。

因此，网站的访问数不再是那么重要。用户的忠诚度定义也需要为适应这种双向关系而适当地修改。它不仅仅是用户对站点的访问频率，同时也包括用户是否愿意让网站联系他们，并且他们有多大意愿接受站点的信息和服务。

任何组织在开始时都会被许多分报告弄得不堪重负，给相关人员公开获取整个系统数据可能会适得其反，因为如果没有特别的解释，他们将不会理解报告中的各种术语和内容。最好是为不同人员提供经过剪裁的报告，并定期发送。

    一旦分析系统上线并正常运行，就可以与那些需要分析结果的人共享这些数据。

    任何组织在开始时都会被许多分报告弄得不堪重负，给相关人员公开获取整个系统数据可能会适得其反，因为如果没有特别的解释，他们将不会理解报告中的各种术语和内容。最好是为不同人员提供经过剪裁的报告，并定期发送。例如：

对于静态化内容的更新策略，一般有以下两种：在数据更新时重新生成静态化内容；定时重新生成静态化内容。

    对于前者，在数据更新的时候重建静态化缓存，往往由用户的某些动作触发，比如新闻站点的网络编辑发表一篇新闻后，程序便创建一个新的静态化新闻页面，同时更新新闻列表页面。显然，这种方式在数据更新频繁时存在大量重建静态内容的开销，尤其是当一个动作引发大量静态内容需要更新时，比如大型新闻站点的CMS（内容管理系统）在工作高峰期间，所有编辑都修改新闻标题而引发大量的页面或局部页面频繁更新，同时伴随着频繁的数据库操作，这将导致CMS系统的服务响应大幅度降低，当然，这可能并不直接影响现存静态化页面的访问，但是不要忘了，这种更新机制也正是静态化缓存方案的一部分，所以它的性能也至关重要。另一方面，如果站点的静态化内容需要分发到更多的服务器，那么频繁的更新也会给文件的同步带来较大的压力。