构建高性能网站，针对前台工程师--总结篇
首先从一次完整的的请求说起：（以此为例get,www,baidu.com）
1，webbrower 发出request，
2，然后解析www.baidu.com为ip,找到ip的服务器，
3，服务器处理请求资源并返回请求的内容，
4，browser接受请求内容过程，（返回内容是按顺序读取的）
4.1遇到外联css，就会并发去读取css内容（），
4.2遇到图片时，回去并发读取图片，目前浏览器的并发数为2，
4.3遇到js时则会阻塞其他请求。
4.4加载完css后，browse开始渲染页面，
4.5直到加载完页面中的文本资源，这时dom的结构已经确定，会出发 document.ready方法
4.6 browse继续加载 图片和js，完成后。页面就全部加载完成，这时会出发 window.onload()方法
?
来分析一下里面具体的时间开销：
1，从1--4.4 用户才开始看到页面上有内容，在这以前页面就是空白的
2，解析域名也是有一定时间开销的，如果是大机房的可以通过路由配置 dns 缓存，依赖于外部机房环境，可控性比较小。 ?
3，这是服务器处理的时间，优化程序代码可以减少这里的时间
??4，
4.1浏览器在接收完css之前，一般是不去渲染dom的，以避免无所谓的刷新和闪烁。所以直到4.4用户才真正在页面上看到内容。
4.2 浏览器的单域名并发访问数?为2，多域名下并发数没限制，可以通过定义域名别名改善
4.3 浏览器加载js时会阻塞其他请求，直到加载完成。改善的话可以把js放到页面下面去加载。
?
从上面的流程可以分析出以下建议：
1，减少连接数（原因：并发限制，dns开销）
2，将css放到 head中。（1,首先这符合w3c规范，2,应为css加载完后，遇到dom对象时就会直接显示，可以更快的显示页面。）
3，将js放到页面底部，（加载js时会阻塞其他请求，这段时间页面没有反映，如果js中没有write的话应该放到底部，页面渲染完后再加载js）
4，减少下载内容（网络是有速度限制的，内容越少当然加载越快）
?
针对上面4条建议给出具体做法：
1，使用 css sprite将小图片合并，合并css、js。使用浏览器缓存： cache-control、expires。不使用etag
2、3不用说了，上面已经解释清楚了。
4，采用gzip压缩，可以使用 jsmin 将js精简，使用工具将css，html精简，尽可能缩减图片。
按照 性能黄金法则 说明： 文本内容只占所有时间的10%-20%, 这样做以后 至少能将时间缩小40%-50%。能明显改善用户体验。
?
这只是一些建议参考，具体的需要你针对自己的网站进行分析，分析工具可以使用firedebug,yslow，（这两个可以集成）
yslow会直接给出你建议。
?
?
24 楼 fch415 2011-05-26 这份总结和其后的回复看出，不是真正做过大网站前端优化的人（说明：我的领域跨过前后端）。（除前文外）再指出几个明显的问题吧：
1）几乎不会真的用Jsmin做压缩，因为它存在一个严重的缺陷，就是当存在直接量的正则表达式时，代码会压缩出问题。
一般都是用YUI Comprosser。
2）一般不采用gzip方案，因为浏览器decode会有性能开销，如果服务器端打开动态gzip的encode更是吃不消。
3）真正做多域名时，不会只准备两个域名，而是一组域名的。
比如：
static1.xxx.com
static2.xxx.com
.....
static10.xxx.com
动态页面（比如JSP）会在每个URL前随机生成一个域名（1-10的随机数）。
而且为了有效利用304缓存（以免相同的URL每次的域名不同，导致无法利用HTTP缓存机制），还需要对URL做hash后的伪随机算法。 25 楼 feiyan35488 2011-05-27 fch415 写道这份总结和其后的回复看出，不是真正做过大网站前端优化的人（说明：我的领域跨过前后端）。
（除前文外）再指出几个明显的问题吧：
1）几乎不会真的用Jsmin做压缩，因为它存在一个严重的缺陷，就是当存在直接量的正则表达式时，代码会压缩出问题。
一般都是用YUI Comprosser。
2）一般不采用gzip方案，因为浏览器decode会有性能开销，如果服务器端打开动态gzip的encode更是吃不消。
3）真正做多域名时，不会只准备两个域名，而是一组域名的。
比如：
static1.xxx.com
static2.xxx.com
.....
static10.xxx.com
动态页面（比如JSP）会在每个URL前随机生成一个域名（1-10的随机数）。
而且为了有效利用304缓存（以免相同的URL每次的域名不同，导致无法利用HTTP缓存机制），还需要对URL做hash后的伪随机算法。
你倒是做过，你烂在肚子里有什么用。我是后台开发的，看了看书，顺便总结一下。有本事你也总结一下啊 26 楼 macrotea 2011-05-27 feiyan35488 的分享精神还是值得赞同的
我支持你！
27 楼 feiyan35488 2011-05-27 macrotea 写道feiyan35488 的分享精神还是值得赞同的
我支持你！
谢谢，为了提高共同提高。最讨厌那些冒充高手到处喷粪的垃圾 28 楼 damoqiongqiu 2011-05-27 总结得非常好，学习了。 29 楼 int08h 2011-05-27 fch415 写道这份总结和其后的回复看出，不是真正做过大网站前端优化的人（说明：我的领域跨过前后端）。
（除前文外）再指出几个明显的问题吧：
1）几乎不会真的用Jsmin做压缩，因为它存在一个严重的缺陷，就是当存在直接量的正则表达式时，代码会压缩出问题。
一般都是用YUI Comprosser。
2）一般不采用gzip方案，因为浏览器decode会有性能开销，如果服务器端打开动态gzip的encode更是吃不消。
3）真正做多域名时，不会只准备两个域名，而是一组域名的。
比如：
static1.xxx.com
static2.xxx.com
.....
static10.xxx.com
动态页面（比如JSP）会在每个URL前随机生成一个域名（1-10的随机数）。
而且为了有效利用304缓存（以免相同的URL每次的域名不同，导致无法利用HTTP缓存机制），还需要对URL做hash后的伪随机算法。
那我也随便说说好了？
1、用什么压缩不是问题，现在google closure compiler也正在取代YUI，再过段时间也许你的YUI也一样是个“过时货”，压缩是个理念，何必纠结于JSMIN还是YUI？
2、decode的性能开销？你真有实测过用不用gzip浏览器的最终load差了多少？有的话给个数字吧？根据我们这边的实测，一个页面+3-5个gzip的资源（图片不会gzip），用不用gzip相关不到100毫秒来着。至于encode的开销，看服务器有多牛呗，不牛的就只对不变的静态资源开gzip，牛的就对动态页面也一起开了，顺便也要看看是你的服务器贵，还是你买的网络更贵，对吧？
3、多域名……我现在首先怀疑多域名的必要性，其次到底是2个还是多个，难道不是按照平均一个页面中的资源数量来决定的吗？难道一个页面只有6-7个资源，你也准备20个域名放着？ 30 楼 feiyan35488 2011-05-27 fch415 写道这份总结和其后的回复看出，不是真正做过大网站前端优化的人（说明：我的领域跨过前后端）。
（除前文外）再指出几个明显的问题吧：
1）几乎不会真的用Jsmin做压缩，因为它存在一个严重的缺陷，就是当存在直接量的正则表达式时，代码会压缩出问题。
一般都是用YUI Comprosser。
2）一般不采用gzip方案，因为浏览器decode会有性能开销，如果服务器端打开动态gzip的encode更是吃不消。
3）真正做多域名时，不会只准备两个域名，而是一组域名的。
比如：
static1.xxx.com
static2.xxx.com
.....
static10.xxx.com
动态页面（比如JSP）会在每个URL前随机生成一个域名（1-10的随机数）。
而且为了有效利用304缓存（以免相同的URL每次的域名不同，导致无法利用HTTP缓存机制），还需要对URL做hash后的伪随机算法。
写了几个html页面，写几行后台hello代码，就敢说 领域跨过前后端。可笑 31 楼 zhang8mss 2011-07-29 总结的不错，支持