YUI前端优化之Server篇

2、网站Server 篇：使用内容分发网络为文件头指定Expires或Cache-ControlGzip压缩文件内容配置ETag尽早刷新输出缓冲使用GET来完成AJAX请求

十一、使用内容分发网络

      用户与你网站服务器的接近程度会影响响应时间的长短。把你的网站内容分散到多个、处于不一样地域位置的服务器上能够加快下载速度。可是首先咱们应该作些什么呢？

      按地域布置网站内容的第一步并非要尝试从新架构你的网站让他们在分发服务器上正常运行。根据应用的需求来改变网站结构，这可能会包括一些比较复杂的任 务，如在服务器间同步Session状态和合并数据库更新等。要想缩短用户和内容服务器的距离，这些架构步骤多是不可避免的。

      要记住，在终端用户的响应时间中有80%到90%的响应时间用于下载图像、样式表、脚本、Flash等页面内容。这就是网站性能黄金守则。和从新设计你的 应用程序架构这样比较困难的任务相比，首先来分布静态内容会更好一点。这不只会缩短响应时间，并且对于内容分发网络来讲它更容易实现。

      内容分发网络（Content Delivery Network，CDN）是由一系列分散到各个不一样地理位置上的Web服务器组成的，它提升了网站内容的传输速度。用于向用户传输内容的服务器主要是根据 和用户在网络上的靠近程度来指定的。例如，拥有最少网络跳数（network hops）和响应速度最快的服务器会被选定。

      一些大型的网络公司拥有本身的CDN，可是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks这 样的CDN服务成本却很是高。对于刚刚起步的企业和我的网站来讲，可能没有使用CDN的成本预算，可是随着目标用户群的不断扩大和更加全球化，CDN就是 实现快速响应所必需的了。以Yahoo来讲，他们转移到CDN上的网站程序静态内容节省了终端用户20%以上的响应时间。使用CDN是一个只须要相对简单 地修改代码实现显著改善网站访问速度的方法。 

十二、为文件头指定Expires或Cache-Control 

      这条守则包括两方面的内容：

对于静态内容：设置文件头过时时间Expires的值为“Never expire”（永不过时）

对于动态内容：使用恰当的Cache-Control文件头来帮助浏览器进行有条件的请求

      网页内容设计如今愈来愈丰富，这就意味着页面中要包含更多的脚本、样式表、图片和Flash。第一次访问你页面的用户就意味着进行屡次的HTTP请求，但 是经过使用Expires文件头就可使这样内容具备缓存性。它避免了接下来的页面访问中没必要要的HTTP请求。Expires文件头常常用于图像文件， 可是应该在全部的内容都使用他，包括脚本、样式表和Flash等。

      浏览器（和代理）使用缓存来减小HTTP请求的大小和次数以加快页面访问速度。Web服务器在HTTP响应中使用Expires文件头来告诉客户端内容需 要缓存多长时间。下面这个例子是一个较长时间的Expires文件头，它告诉浏览器这个响应直到2010年4月15日才过时。

      Expires: Thu, 15 Apr 2010 20:00:00 GMT 

      若是你使用的是Apache服务器，可使用ExpiresDefault来设定相对当前日期的过时时间。下面这个例子是使用ExpiresDefault来设定请求时间后10年过时的文件头：

      ExpiresDefault "access plus 10 years" 

      要切记，若是使用了Expires文件头，当页面内容改变时就必须改变内容的文件名。依Yahoo!来讲咱们常用这样的步骤：在内容的文件名中加上版本号，如yahoo_2.0.6.js。

      使用Expires文件头只有会在用户已经访问过你的网站后才会起做用。当用户首次访问你的网站时这对减小HTTP请求次数来讲是无效的，由于浏览器的缓 存是空的。所以这种方法对于你网站性能的改进状况要依据他们“预缓存”存在时对你页面的点击频率（“预缓存”中已经包含了页面中的全部内容）。Yahoo!创建了一套测量方法，咱们发现全部的页面浏览量中有75~85%都有“预缓存”。经过使用Expires文件头，增长了缓存在浏览器中内容的数量，而且能够在用户接下来的请求中再次使用这些内容，这甚至都不须要经过用户发送一个字节的请求。 

1三、Gzip压缩文件内容

      网络传输中的HTTP请求和应答时间能够经过前端机制获得显著改善。的确，终端用户的带宽、互联网提供者、与对等交换点的靠近程度等都不是网站开发者所能决定的。可是还有其余因素影响着响应时间。经过减少HTTP响应的大小能够节省HTTP响应时间。

      从HTTP/1.1开始，web客户端都默认支持HTTP请求中有Accept-Encoding文件头的压缩格式：   

      Accept-Encoding: gzip, deflate 

      若是web服务器在请求的文件头中检测到上面的代码，就会以客户端列出的方式压缩响应内容。Web服务器把压缩方式经过响应文件头中的Content-Encoding来返回给浏览器。

      Content-Encoding: gzip 

      Gzip是目前最流行也是最有效的压缩方式。这是由GNU项目开发并经过RFC 1952来标准化的。另外仅有的一个压缩格式是deflate，可是它的使用范围有限效果也稍稍逊色。

      Gzip大概能够减小70%的响应规模。目前大约有90%经过浏览器传输的互联网交换支持gzip格式。若是你使用的是Apache，gzip模块配置和你的版本有关：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。

      浏览器和代理都会存在这样的问题：浏览器指望收到的和实际接收到的内容会存在不匹配的现象。幸亏，这种特殊状况随着旧式浏览器使用量的减小在减小。Apache模块会经过自动添加适当的Vary响应文件头来避免这种情况的出现。

      服务器根据文件类型来选择须要进行gzip压缩的文件，可是这过于限制了可压缩的文件。大多数web服务器会压缩HTML文档。对脚本和样式表进行压缩同 样也是值得作的事情，可是不少web服务器都没有这个功能。实际上，压缩任何一个文本类型的响应，包括XML和JSON，都值得的。图像和PDF文件因为 已经压缩过了因此不能再进行gzip压缩。若是试图gizp压缩这些文件的话不但会浪费CPU资源还会增长文件的大小。 

      Gzip压缩全部可能的文件类型是减小文件体积增长用户体验的简单方法。 

1四、配置ETag 

      Entity tags（ETags）（实体标签）是web服务器和浏览器用于判断浏览器缓存中的内容和服务器中的原始内容是否匹配的一种机制（“实体”就是所说的“内 容”，包括图片、脚本、样式表等）。增长ETag为实体的验证提供了一个比使用“last-modified date（上次编辑时间）”更加灵活的机制。Etag是一个识别内容版本号的惟一字符串。惟一的格式限制就是它必须包含在双引号内。原始服务器经过含有 ETag文件头的响应指定页面内容的ETag。 

      HTTP/1.1 200 OK

      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT

      ETag: "10c24bc-4ab-457e1c1f"

      Content-Length: 12195

      稍后，若是浏览器要验证一个文件，它会使用If-None-Match文件头来把ETag传回给原始服务器。在这个例子中，若是ETag匹配，就会返回一 个304状态码，这就节省了12195字节的响应。      GET /i/yahoo.gif HTTP/1.1

      Host: us.yimg.com

      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT

      If-None-Match: "10c24bc-4ab-457e1c1f"

      HTTP/1.1 304 Not Modified

      ETag的问题在于，它是根据能够辨别网站所在的服务器的具备惟一性的属性来生成的。当浏览器从一台服务器上得到页面内容后到另一台服务器上进行验证时 ETag就会不匹配，这种状况对于使用服务器组和处理请求的网站来讲是很是常见的。默认状况下，Apache和IIS都会把数据嵌入ETag中，这会显著 减小多服务器间的文件验证冲突。

      Apache 1.3和2.x中的ETag格式为inode-size-timestamp。即便某个文件在不一样的服务器上会处于相同的目录下，文件大小、权限、时间戳等都彻底相同，可是在不一样服务器上他们的内码也是不一样的。 

      IIS 5.0和IIS 6.0处理ETag的机制类似。IIS中的ETag格式为Filetimestamp:ChangeNumber。用ChangeNumber来跟踪 IIS配置的改变。网站所用的不一样IIS服务器间ChangeNumber也不相同。 不一样的服务器上的Apache和IIS即便对于彻底相同的内容产生的ETag在也不相同，用户并不会接收到一个小而快的304响应；相反他们会接收一个正 常的200响应并下载所有内容。若是你的网站只放在一台服务器上，就不会存在这个问题。可是若是你的网站是架设在多个服务器上，而且使用Apache和 IIS产生默认的ETag配置，你的用户得到页面就会相对慢一点，服务器会传输更多的内容，占用更多的带宽，代理也不会有效地缓存你的网站内容。即便你的 内容拥有Expires文件头，不管用户何时点击“刷新”或者“重载”按钮都会发送相应的GET请求。

      若是你没有使用ETag提供的灵活的验证模式，那么干脆把全部的ETag都去掉会更好。Last-Modified文件头验证是基于内容的时间戳的。去掉ETag文件头会减小响应和下次请求中文件的大小。微软的这篇支持文稿讲述了如何去掉ETag。在Apache中，只须要在配置文件中简单添加下面一行代码就能够了：

      FileETag none 

1五、尽早刷新输出缓冲

      当用户请求一个页面时，不管如何都会花费200到500毫秒用于后台组织HTML文件。在这期间，浏览器会一直空闲等待数据返回。在PHP中，你可使用 flush()方法，它容许你把已经编译的好的部分HTML响应文件先发送给浏览器，这时浏览器就会能够下载文件中的内容（脚本等）然后台同时处理剩余的 HTML页面。这样作的效果会在后台烦恼或者前台较空闲时更加明显。

      输出缓冲应用最好的一个地方就是紧跟在<head />以后，由于HTML的头部分容易生成并且头部每每包含CSS和JavaScript文件，这样浏览器就能够在后台编译剩余HTML的同时并行下载它们。 例子： 

      ... <!-- css, js -->

    </head>

    <?php flush(); ?>

    <body>

      ... <!-- content -->

为了证实使用这项技术的好处，，Yahoo!搜索率先研究并完成了用户测试。 

1六、使用GET来完成AJAX请求

        Yahoo!Mail团 队发现，当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，而后才发送数据。所以使用GET最为恰 当，由于它只需发送一个TCP包（除非你有不少cookie）。IE中URL的最大长度为2K，所以若是你要发送一个超过2K的数据时就不能使用GET 了。

      一个有趣的不一样就是POST并不像GET那样实际发送数据。根据HTTP规范，GET意味着“获取”数据，所以当你仅仅获取数据时使用GET更加有意义（从语意上讲也是如此），相反，发送并在服务端保存数据时使用POST。