网站技术分析报告之——开心网（kaixin.com）

楔子

一直在研究互联网技术，经常访问这样那样的网站，突发奇想，为什么我们不去看看这些网站的技术架构是怎么样的呢？研究一下源代码？于是便有了这个系列，首先找谁呢？我想还是找山寨版的开心网开刀吧，这个开心网，不是那个开心网，呵呵。

坦白说，我不太想注册，也不想研究太多太多，一般来说，一个网站最重要的是首页，Ok，那我们就从首页开始吧。

本系列文章仅仅是个人研究发布，仅供参考，本人不承担任何责任，呵呵，谢绝跨省抓捕。对于开心网，因为是一个封闭系统的系统，我挑了一个注册的页面来分析。页面网址：http://reg.kaixin.com/kx7201.do?ss=10112&rt=26
分析工具：各种浏览器，firebug（一个基于firefox的插件）

导语：

我如果是陈一舟，我一定炒掉开心网的CTO，为什么呢，这么简单的一个登陆页，居然做到了385.2KB之大，像开心网这么大的流量，每多1kb就意味着每天N多的钱哪。呵呵，开玩笑啊，开心网的CTO别骂我，假如哪一天你真被炒了，别怪我啊，只能说是巧合。我没有找到官方的pv或独立Ip的数据，根据alexa的数据参考一下吧，估计日均独立IP为528,000，我们估计按每独立IP访问一次登陆吧，实际上可能少一些，因为很多用户可能直接在首页上登陆了（alexa的数据也不是那么可靠，供参考吧）。

开心网的网页每增加1k，我们需要多少带宽？算一下，我们需要528,000/1024=515MB/天的带宽，然后我们平均一下，按一天24小时用户访问很平均来计算（实际上不可能，一般峰值访问会是平均值的一倍以上），每秒需要消耗带宽是528000 / (24小时 * 60分钟 * 60秒)=6Kb，考虑到峰值，估计要到12k以上。

看官，我认为像开心网这么简单的登陆，完全可以控制在100k以内的大小，为什么我要这么多呢，一会儿看我对网页的分析就可以知道了。这是什么概念？385-100=285k，再算出带宽得出：285k * 12k / 1024 = 3.3M。乖乖，开心网每天需要添加3.3M的独享带宽。3.3M的带宽会是多少钱呢？像开心网这种网站，怎么也不可能放特别垃圾的机房吧，我们就以中档的机房来举例。北京中档的3M独立带宽，怎么也得3-5万块吧，我没有找到合适的数据，只是根据各网站估计一个值，有知道的朋友告诉一下。再加上CDN的带宽，我估计开心网每年需要为此增加5-8万的费用。

 

分析一下开心网存在的问题：

1. Javascript文件直接写在了网页当中

开心网的登陆页有大量的javascript的代码，这样的代码一方面不利于维护，另一方面，也不利用用户加载页面。大致计算了一下，开心网登陆页一个有180余行的javascript代码，而总代码仅在336行，也就是说代码中的javascript代码占了1/2 强。

2. 网页没有开启gzip

这是一个比较白痴的错误，根据文件头返回的信息可以看到，开心网应该在linux上搭建了nginx ，添加gzip应该不会是很难的事吧？而且像html及静态js/css这些文件，gzip后起码可以减少50%的传输量，当是这一项，就可以每年省下上百万的费用。

当然有人会反对，认为gzip会加重服务器的压力，并且客户端解压的时间与减小文件大小带来的传输速度不会有太多好处。但我认为，对于静态文件来说，可以放到独立的服务器，这个服务器可以把文件压缩后放到缓存中，这样不用去读IO，响应速度会提高。同时，虽然现在用户的带宽都已经是512k的 adsl以上了，但是为什么我不可以让用户更快的看到我们的网页呢？退一万步说，用户真的在乎这个快几秒的，那么我们为什么不可以减小带宽的压力以节省成本呢？如果把节省下的这些钱去奖励员工，没准他们可以给我带来更多的惊喜呢。

3. Javascript没有做任何处理

开心网的javascript可真有意思，他们的开发人员代码质量还不错，起码注释写得还不错，可是问题是，你需要把这些注释都发到客户端么，难道开心网想教我们怎么写javascript代码？这样的代码发到客户端，既占带宽又会泄密网站的代码。

开心网的核心javascript文件xn.core.js有105k，这么大的其中注释占了不少的代码，我尝试使用yahoo和google的压缩工具进行压缩，但因为代码中有错误无法完成，所以只好放弃。但我估计这个js，最基本的压缩去除空行和注释，可以减少1/5左右的大小，如果进行一些混淆的话，应该可以在40k左右，如果再gzip的话，应该就只有15k以内了。

4. 图片文件过大

登录页有一个157k的sys-bj2.jpeg文件，天啦，这么大的。我下载这张图片一看，发现这个图片实际是同几张图片组合的。他们的设计人员其实是想减少网页对服务器的请求数，所以把几个图片合并到一块。但是，他们这种做法是错误的。

我们要减少请求数，一般是把小图片，一般是几k的36 px* 36px以下的小图片合并，而不是把大图片也合并。因为小图片数量多，而大图的合并，也会增加图片的大小。我将这个图片用ps再优化一下，优化到66k，也没发现明显的失真。所以我认为，就算是大图，也可以优化到80k以内，而不是如此157k大小的图片。

再多一句，这个图片总量才5个合并是完全没有必要的，并且图片最大的有600px*255px，而最小的只有10px*10px以下，这种合并没有任何益处，百害而无一益！

总结:

开心网作为一个访问量非常大的网站，网页结构也非常简单，理应做得更小，比如在100k以内。从我的分析中可以看出，主要问题集中在javascript，gzip和图片上，代码质量总体还可以。当然，我们不仅只是挑刺，也应该看到一些好的地方，如下：
1. 首页处理得比较到位，虽然javascript也没有压缩，但总大小只有108k
2. 文件请求数较少，这个和开心网本身有关，开心网本来就不是一个网页结构复杂的网站，所以文件数自然会比较少了
3. 静态文件和网页分开部署
4. Javascript注释比较好，但不应该发到客户端

重要建议：

1. 开启gzip压缩
2. 压缩javascript及css，并将这些文件缓存起来

最后，这次的分析就写到这里了，就事论事而已，和任何网站及相关的人员没有任何关系，呵呵。

 

本文来自涂雅[http://iove.net/]，原文链接：http://iove.net/archives/1623.html，网站转载请注明来源于涂雅并保留原文链接，否则视为侵权。