高性能网站建设指南

性能优化

减少HTTP请求次数

建立HTTP链接需要耗费较多的时间，如果建立了比较多的HTTP链接，整个网页的性能也会随之下降，譬如HTML文档当中有过多的图片等资源请求，要建立多个HTTP链接，性能损耗过大，那么，一种简单的方法就是 合并文件

1. 合并JS、CSS等静态文件，只发送一次HTTP请求
2. 合并图片，即使用sprites，雪碧图

使用CDN(content delivery network)

浏览器需要向服务器发送文件请求，但是由计网知识，我们是可以知道，发送请求过程中，需要建立起链接，如果请求的服务器只有一个，又很远，路由器转发路径长，那么延迟就会高，所需要的时间就多，用户体验就不好，所以从用户体验角度来说，使用CDN的原因如下

1. 用户能够更快地获取到请求的文件
2. 减少服务器的压力，如果全部请求都扔到同一个服务器上去进行处理，服务器数据处理压力大，性能不好，使用几台服务器进行服务，分担访问压力

使用缓存

缓存对于一个网站的性能提高非常的有效，对于一些静态资源，比如在某一段长时间内不会改变的CSS文件，亦或者一些图片资源，长期不改变，如logo等，都是可以把他们缓存下来，在下次访问网站的时候，就不需要再请求这些文件了，直接使用缓存的文件，响应速度快，而且，节省资源。

那么，该如何来使用缓存策略呢，具体分为以下两种

1. 强缓存： cache-control | expires
2. 弱缓存(即协商缓存)：Last-modified | Etag

具体的详细介绍，可以看看这篇文章所写的，浏览器缓存知识归纳，简单来说，我先说说以上集中缓存的方式的差异

1. cache-control和expires，都是在服务器进行相关的配置，即在响应头首部信息进行相关的配置，但是，expires所写的时间为绝对时间，并且是将客户端与服务端的时间进行比较，倘若客户端将时间修改相差很大之后，缓存实际上已经没有什么大的用处了，cache-control的话，是相对时间，而且都是相对于客户端自己的时间，故比较准确
2. last-modified的话，时间比较的是相对于服务器的时间，也不会有偏差，Etag的话，则是使用校验码的方式，会对资源做一次散列值计算，改变之后，散列值不能对应，保证资源的唯一性

使用Gzip

如前面所说的，大部分的时间都是消耗在等待文件传输完成，所以对于传输文件的大小的控制是很有必要的，故传输的文件在其传输之前都要进行相应的压缩，目前使用的比较多的就是 Gzip 压缩格式

##客户端设置
Accept-Encoding: gzip, deflate

##服务端设置
服务端在看到请求报文当中的accept-encoding字段的时候，会返回
Content-Encoding: gzip

将样式表放置在head标签当中

先加载好css文件，避免 无样式闪烁

js文件放置在body底部

具体原因，可以参考浏览器渲染过程，以及HTML文档加载顺序来进行相关的解释
HTML文档的加载顺序

避免使用CSS表达式

CSS表达式的计算非常消耗性能，虽然可以动态的进行计算，但是非常不建议用，因为不清楚再什么时候就会触发它，比如有时候修改的属性是根据鼠标的移动来进行改变的，这样会不断触发而导致修改，性能消耗严重，关于CSS选择器的优化，具体还可以看这篇 CSS选择器优化

减少DNS查询

浏览器访问一个URL的时候，第一步就要先进行DNS查询，但是，我们都知道的，DNS查询是需要时间的，如何能够节省这一部分时间，提高性能呢？我们可以考虑一下将DNS查询结果储存起来，即缓存DNS，这样，在之后的一些请求的时候，就不需要再进行DNS查询，而是直接使用DNS的缓存来获取服务器的IP地址

原理：DNS查询：访问网址(转换为IP)，时间至少20 ms；浏览器缓存：IE (30 ms)、FF (60 s)、Chrome (60 s)，缓存长可减少DNS重复查找、节省时间，缓存短可及时检测服务器的变化、保证正确性；

避免重定向

首先，建立HTTP请求是耗时的，如果建立完成，服务器也正确返回了，却返回了一个301或者302，告诉你文件放在了别的地方，又需要发送一次HTTP请求，那么，所消耗的时间将会是原来的两倍，并且在网络环境不好的情况下，重定向过程中，由于html文档未到来，那么浏览器将会是一段时间的空白，用户体验不好

配置Etag

具体的配置要求，可以看上方第三点的 缓存策略

分段发送

服务器构建HTML文档需要一定的时间，可以边构建，边发送，具体实现方法(查)

Ajax异步请求方式最好用 get

研究发现，在使用XMLHttpRequest的时候，请求方式为post的时候，需要建立两次TCP，第一次是发送头部信息，第二次才发送数据，所以在只需要请求数据的时候，使用GET，但是GET方法对传输文件大小的限制为2K，所以若要请求大文件，还是需要使用POST方法

Post-load Components

在浏览器渲染过程中，用户体验比较好的表现是能较快的将首屏页面展现给用户，因此，一些在首屏里面看不到的部件是可以后期再进行加载和解析的。譬如一些实现拖拽的实现，可以在页面加载完成后再导入，因为这一部分用户不会再第一时间就去触发。
实现的主要方式，可以用js来实现后置加载，即后面才需要用的部件，可以在onload事件里面才将需要用到的插入到DOM当中

Pre-load Components

前置加载和后置加载可谓目的相同，都是为了能更快地将页面反馈给用户，前置的话，就是按照用户的可能点击路线，提前加载一些需要用到的文件，而不用等到真正点击的时候才进行加载、解析和执行。主要有以下几种方式

1. 在onload事件当中，就将子页面当中要用到的外部文件先加载
2. 根据用户的操作，来估计下一个可能需要用到的外部文件，譬如，用户在搜索框中输入某个东西，那么下一个页面肯定是搜索结果页面，可以在用户在input当中输入的时候，就先加载搜索结果页面可能需要用到的文件了

配置几个不同的域

由于浏览器同域数目的限制，一般是2-6个，如果整个网站都使用同一域的资源，由于浏览器最大并发数的限制，如果所需要文件多，那么等待时间无疑很长，所以在条件允许的情况下，可以配备几个域放置资源，譬如可以将图片放到某台服务器上，而其他放在另外一台，这样可以增加并发数。但是也不要设置太多服务器，因为DNS查询是耗时的

那么如何解决由于配置不同的域所带来的额外的DNS查询呢?
可以使用DNS预解析,即 
<meta http-equiv="x-dns-prefetch-control" content="on" />
<link rel="dns-prefetch" href="http://bdimg.share.baidu.com" />
........

Not 404

很多时候，我们都会遇到404 not found的提示，但是，通常网站的处理都会是说找不到，然后返回这个结果给你，友好一点的网站，应该是返回类似的搜索结果(即 猜！)，因为不管怎么样，如果没有搜索到，总要进行一次搜索，也会进行一次文件的传输，那为什么不利用这一次机会，直接返回类似结果，而不用等待用户再次输入后，进行查询、返回

Use Cookie-free Domains for Components

并不是所有的请求都要带上cookies，因为cookies通常用来进行身份的识别以及记录登陆情况，但是，在请求文件的时候，没有必要每一个请求头都带上cookies信息，譬如在请求图片资源的时候，cookie信息是没有任何用处的，带上cookie反而会增大请求头的大小，可浪费资源。
解决的办法，通常可以将静态资源放在另外一个子域当中，譬如正常的请求域是 www.example.com，那么可以将静态资源放在 static.example.com，在向static.example.com发送请求时，就不会带上cookie信息。倘若cookie信息是放在顶级域当中，那么解决办法是开多一个新的顶级域来实现。