网站建设高性能表现的网站发布者：本站     时间：2022-03-31 10:03:22

为什么要从前端开始着手有三个主要原因：

这里有提升和改进的潜力。如果能减少一半的体积，就能减少40%的响应时间
改进前端比改进后端需要的时间和资源更少。（改进后端要重新设计应用程序规划，代码，寻找优化代码的方法，添加或改变硬件配置，分布式数据库，等等）
前端的改进在我们的工作中已经被证实，我们在yahoo有五十个小组，在我们的最佳表现规则下，提高了他们的用户端响应时间达到25%或更高。
我们的黄金规则是：首先优化前端表现，这些东西耗费了用户端响应时间中的80%。

1.减少http请求数

图片，css，script，flash，等等这些都会增加http请求数，减少这些元素的数量能减少响应时间。

CSS Sprites技术能减少图片的请求数，把零散的小图片放到一起，运用background-position来改变背景图片的位置，前提是html元素事先定义好宽高，其实就像一个遮罩，移动背景就会看到不同的景象。

内嵌图像  用data:URL scheme的方式把图片内容代码直接嵌入html代码中，这样会增大html代码的体积，改进的方式是把内嵌图片嵌入到css中（css被缓存），这样就会更好的减少http请求数而且不增大html的体积。

很多用户都是在空缓存的情况下进入你的网站的，这样第一次的速度就会显得很重要。

第一条规则是最重要的一条规则。

2.运用cdn技术

见： //hi.baidu.com/axne/blog/item/258e23ade2d76f0a4b36d6d1.html

3.加一个长时间过期的头部

Expires: Thu, 15 Apr 2010 20:00:00 GMT
浏览器会用缓存来减少http请求数来加快页面加载的时间，如果页面头部加一个很长的过期时间，浏览器就会一直缓存页面里的元素。
不过这样会带来一个问题，就是如果页面里的东西变动的话就要改名字了，否则用户端不会主动刷新，在yahoo工作组用的是版本号，例如yahoo_2.0.6.js

4.Gzip压缩

Gzip是现在最流行和最有效的压缩方式，她是GNU开发的，RFC1952标准化。
（Gzip是在服务器端压缩图片，css，脚本等，传送到用户端的浏览器再解压，这样可以提高传输速度，不过对服务器的压力会增大，一般选择部分元素压缩比较合适。）

5.把样式表放到顶部

我们发现把css放到文档头部会让网页加载得更快。因为这样可以让页面逐渐加载。
把样式表放到接近底部的问题是它阻止了页面元素的逐渐显示。这样还会导致“flash of unstyled content” 即在样式表加载之前页面内容是以没有样式的形式显示出来的，待加载完样式后，页面重绘，内容一闪即改变了样式表现。

6.把脚本放到底部

把脚本放到尽可能底部的地方，一个原因是让页面逐渐渲染，另一个是实现更好的并行下载。

对于脚本，脚本以下的内容被阻止逐渐加载了，因为只有当下载完脚本以后才会下载下面的内容，第二个脚本引起的问题是阻止平行下载。 "http/1.1 specification"建议浏览器对一个域名， 同一时间下载数不超过2个（按：实际监测发现一般有超过2个），我曾经让ie并行下载100个图片。 当脚本正在下载的时候，浏览器不会开始下载任何东西。

7.避免css expressions

css expressions 是一个有力（和危险）的方式动态的改变css的属性。他们自ie5就开始被支持，举个例子，用css expression可以让背景色每个小时轮换一次。但是被非ie浏览器忽略的。

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

expressions的问题就在与它的计算频率绝对超出我们的想象，甚至当我们移动鼠标，都会引起页面的重绘！

下面是举例页面

减少css expressions计算次数的一个方法就是使用一次性的expressions。 当第一次expression计算出一个明确的值，就让样式等于这个值，不再变动。如果样式的属性一定要动态的改变，就用时间句柄吧！

8.让脚本和样式外延

Javascript和CSS应该是外部调用还是内嵌呢？
用外部调用文件的方式更快，因为他们是可以被缓存的，如果是内嵌在页面中他们就无法被缓存了！想想如果用户要在你的网站看很多很多的页面，如果都是使用同一个外部脚本和样式，那么他们一旦被缓存，就再也不需要下载了，这样会给你带来很大的潜在好处。

9.减少DNS查询

10.减小脚本体积

有两个比较流行的工具是用来减小脚本的体积的--JSMin和YUI Compressor
（按：这个压缩和Gzip压缩是不一样的，Gzip是传输压缩，这个是代码压缩）

11.避免重定向

重定向会减慢用户体验，它会延迟所有的东西直至到达新页面。一个最浪费的重定向经常会发生而我们的开发者又会经常忽略的就是比如//astrology.yahoo.com/astrology的结果是重定向到//astrology.yahoo.com/astrology/ 在Apache里用Alias 或者mod_rewrite或者DirectorySlash解决。
从一个旧网站跳转到新网站也是经常要用到重定向，还有就是连接一个网站中的不同部分和在某些情况下（比如不同浏览器，不同的用户帐号类型，等等）的用户导向。用重定向很简单，而且只需要一点额外的代码，虽然在这些情况下用重定向减少了开发者的复杂度，但它降低了用户的体验，变通的做法是用Alias和mod_rewrite如果两个部分是在同一主机上的话，如果是由域名变更引起的重定向，变通的做法是通过Alias或mod_rewrite创建一个CNAME（一个DNS记录，创建一个别名，从一个域名指向另一个域名）

12.去掉重复的脚本

（按：简单的说，同一个脚本如果被调用多次，浏览器并不会忽略后续的脚本，而总是覆盖加载，覆盖运行，这样会增加开销）

13.配置ETags

ETags（Entity tags）是服务器和浏览器的一个功能，它用来判断浏览器缓存里的元素是否和原来服务器上的一致。ETags比last-modified date更具有弹性，它用一个独一无二的字符串来标识一个元素的版本。
源服务器用响应头里的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到源服务器。如果符合的话，一个304状态的代码就会从源服务器返回到浏览器，这样源服务器就节省了传输具体数据的开销。
       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

用Etags的问题就在于它会标识那个特定的服务器，如果换了服务器，Etags也就失去了原有的功能，但是这种现在在网络上太常见了，因为我们经常用服务器集群。默认情况下，Apache和IIS会在Etag中内嵌数据，这样会动态减少验证成功的机会。

Apache1.3和2.x的ETag格式是inode-size-timestamp。虽然一个文件可能在不同服务器的同一个目录，同样的大小，安全级，时间戳等等，它的inode会随着服务器的不同而不同。

IIS5.0和6.0有同样类似Etags的东西，叫时间戳：ChangeNumber（更改号），更改号是一个用来追踪IIS配置变化的计数器，ChangeNumber在不同IIS服务器之间是不一样的。

它最终的问题就是，IIS和Apache产生的Etags会在不同服务器之间无法匹配，这样我们的浏览器就无法得到我们期待的304响应，而给我们的是一个普通的200响应，和正常的数据流。如果你的网站只有一个服务器还无所谓，如果是集群，而你用的是默认的ETag配置，你的用户就会获得更慢的页面，你的服务器也会有更高的负载，消耗更大的带宽资源，代理也无法高效缓存你的内容，甚至即使你有一个长时间过期的头部（按：见第三条规则），也不会阻止它重新载入内容。

如果你不想发挥Etags提供的这个弹性验证模型的优势，你最好关掉它。Apache中关掉它的方法是在Apache的配置文件中写这么一句：
FileETag none

14.让Ajax缓存

人们会问这些规则同样适用于web2.0吗？当然！这个规则是我在雅虎工作做web2.0后得出的第一条规则。

Ajax的一个好处是它会给你实时的回馈，因为它和后台的服务器是异步传输的，然而，用Ajax并不能保证你的用户不用无聊的拨弄手指头来等待这个回馈，在很多应用中，用户是否需要等待取决于Ajax是怎么用的，举例说，在一个基于网页的邮件客户端，用户会持续等待Ajax的回馈来搜索符合他的标准的邮件信息。记住“异步”并不意味着“实时”。让它缓存的方式同样是加一个过期头部。