前言

zdlive 是我大四实习的一家公司，当时在那边负责前端模块，写了蛮多的笔记，现在整理出来～=）

相比起后台的优化，前台的优化一般都会被忽视，但其实在用户发起一个页面请求，到页面最终展现给用户，前端所占的比重是非常大的。看了《高性能网站建设指南》，还有《构建高性能 Web 站点》的部分章节，针对 zdlive 的页面，可以做如下优化尝试。

优化的指导方针共有 13 条，结合 zdlive 讲。

减少 HTTP 请求

一般我们的网页会有如下三种，图片、css 文件、js 文件和 html 文件。当用户在输入输入网址的时候，浏览器会向服务端发起一个 http 请求。当这个 html 文件被下载到客户端之后，其他的组件才开始下载，我们以 zdlive.com 为例。

可以看到，所有的组件下载，都是等到第一个文件载入完毕后再发起的，而这里的每一项都是代表着一个 http 请求。

对于一个页面来说，多个 http 头并没有什么关系，但对于响应速度和稳定性要求高的，比如 zdlive 的首页，尤其是 gprs 这样坑爹的网络下，多个 http 头，意味着速度慢，请求失败的几率会很大，页面显示不完整等等问题。

那我们要做的就是减少 http 请求了。

方法有如下几种：

• 减少图片。目前比较常见的做法是把多张图片整合到一张图片里面，然后利用 css 的技术，比如 background 的定位来做到共享图片的目的，这种技术叫做 CSS Sprites。  坏处有 2，定位麻烦和单张图片的大小会很大，这样用户请求到完成的时间就会比单张小图片要久。

对于我们的首页来说，这种做法还需要实际测试下。

• 内联图片。对图片进行 base64 位的编码，这样图片就可以和 html 文档一起下载到客户端了。

坏处是 Base64 位压缩以后，图片的大小会变大。但结合服务端的 gzip 压缩，减少客户端的 8 个请求，还是可以尝试下的。

• 合并脚本和样式表。

对于一个文件来说，通常会有多个脚本文件和样式文件，分开是模块管理的需要，但有时候也可以结合在一起，合并下载。但这个单个文件大小，和多个 http 请求头之间的怎么去权衡，我还不是很清楚。 ## 使用内容分发网络 内容分发网络的意思是说，假设我们公司现在有多台服务器，一些专门用来跑应用支持，一些专门用来给用户下载文件的，比如 img 文件、mp3 文件等等。而这里，内容分发网络就是指这些用来下载的服务器了。只是，他们现在都在北京这个地方，如果这些被用户用来下载文件的服务器能部署在全国各地，那对于用户来说，更近的服务器，就意味着更短的相应时间和更快的下载速度。

拿 douban 的豆瓣 FM 来说，当我发起访问的时候，实际上我听的歌曲并不是在北京那边的服务器给过来的，倒是从广州这边的服务器下载的。

具体测试，可以用下抓包工具查看 ip 地址信息，海富推荐用 fiddler2。