其中黑色部分，跟后端是慎密相连的，在我们的内容中都已经涉及到了，并且做了更深入的讨论。兰色部分，5，6，7是相关页面执行速度的，构建前端页面的人应该注意的。 11属于避免使用的体例。 红色部分我着重说一下：
gzip 我不推荐使用，因为有些早期IE支持的欠好，它的表示为直接用IE拜候没问题，用js嵌进去，就不克不及正常解压。这样的用户占比应该在2%左右。这个问题我跟踪了近一个月，差点抛却使用压缩。 后来发现我以前用deflate压缩的文件却能正常拜候。 改用deflate问题解决。apache 1.x使用mod_gzip ，到了 2.x 改用cmod_deflate，不知道是否跟这个原因有关。 别的对小文件压缩来讲，deflate 可比 gzip 省很多字节。
削减 DNS 查询： 这里也是有个取舍的，一般阅读器最多只为一个域名成立两个毗连通道。 如果我一个页面嵌了 image.xx 的很多图片，你就会发现，图片从上往下一张张显示出来这个过程。这造成了阅读器真个排队。 我们可以通过增加域名提高并发度，例如 image0.xx ，image1.xx ，image2.xx，image3.xx 这样并发度就提上去了，可是会造成很多cache失效，那很简单，假定我们对文件名相加，对4取mod，就可以包管，某个图片只能通过某个域名进行拜候。 不过，我也很否决一页面请求了数十个域名，很多域名下只有一到两个资源的做法，这样的时间开消是不划算的。
别的，我在这里再添一个第15条：错开资源请求时间，避免阅读器端排队。
随着ajax的普遍使用，动态刷新无处不在，体育直播里有个页面挪用了我一个域名下的6个文件，3个js，3个xml。 刷新频率年夜致是两个10秒的，两个30秒的，两个一次性载入的。不雅察发现正常响应时间都在7ms，可是每过一会就会呈现一次在100ms以上的，我就很奇怪，办事器负载很轻呢。meijun帮我把刷新时间错开，11秒的，9秒的，31秒的，这样响应在100ms以上的概率削减了好几倍，这就是所谓的细节决定成败吧。
1. 尽可能的削减 HTTP 的请求数 ［content］
2. 使用 CDN（Content Delivery Network） ［server］
3. 添加 Expires 头（或 Cache-control ） ［server］
4. Gzip 组件 ［server］
5. 将 CSS 样式放在页面的上方 ［css］
6. 将脚本移动到底部（包含内联的） ［javascript］
7. 避免使用 CSS 中的 expression_r_r_r_rs ［css］
8. 将 JavaScript 和 CSS 自力成外部文件 ［javascript］ ［css］
9. 削减 DNS 查询 ［content］
10. 压缩 JavaScript 和 CSS （包含内联的） ［javascript］ ［css］
11. 避免重定向 ［server］
12. 移除重复的脚本 ［javascript］
13. 配置实体标签（ETags） ［css］
14. 使 AJAX 缓存
六．上线了 !=Finished
奥运期间我按1500w~2000w connections在线，设计了一套备用系统，现在看来，如果用户真达到了这个数目我会很危险，因为有部分办事器引入了32bit的centos 5未经实际线上查验，而我那时简单的认为它应该和centos 4表示出一样的特性。所以现在未颠末完全测试的lib库和新版本，我都很谨慎的使用。没在真实情况中查验过，不克不及轻易下结论。
很多项目组好象不断的忙，做新项目，上线后又继续下个新项目，然后时不时的转过甚去修理以前的bug。如果一个项目上线后，用户量延续上升，就应该斟酌优化了，一小我拜候，和100w人拜候，微小的修改对后端影响是不克不及比较的，不该请求的资源就让它cache在用户的硬盘上，用户拜候块了，你也省资源。上线仅仅代表可以交差了罢了，对手艺人员来讲延续的对一个重要项目进行跟踪和优化是需要的。
七．提速度同时节俭本钱体例汇总
1，编写节俭的HTTP办事器 （高负载下速度明显提升，节俭5~10倍办事器）
对一些重要的办事器量身定做。或选用比较高效的开源软件进行优化。
2，不合办事同化使用 （节俭1~2倍办事器）
如果我们一台办事器只支持30w conn的话，那么剩余的75% cpu资源，95%的内存资源，和几近所有的磁盘资源都可以摆设动态池系统，我感觉DB对网卡中断的消耗仍是有限的，我也不消新买网卡了。
3，对纯数据部分启用新的域名（速度有提升，上行带宽节俭1倍以上）
比如我们别的采办了sinajs 来做数据办事，以避免cookie，节俭带宽。 Cookie不单会华侈办事器端措置能力，并且它要上行数据，而通常情况上行比下行慢。