你可能感兴趣的内容：
楔子
一直在研究互联网技术，经常访问这样那样的网站，突发奇想，为什么我们不去看看这些网站的技术架构是怎么样的呢？研究一下源代码？于是便有了这个系列，首先找谁呢？我想还是找山寨版的开心网开刀吧，这个开心网，不是那个开心网，呵呵。
坦白说，我不太想注册，也不想研究太多太多，一般来说，一个网站最重要的是首页，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，网站转载请注明来源于涂雅并保留原文链接，否则视为侵权。
嗯，或者你也可以收听我的微博，腾讯微博(主要用这个，其他的看我的个人介绍)
我写博客常常出现错别字，常常错得还很离谱，有时候我自己看了第二遍都骂我自个儿，但我又不习惯重复审查，纠结啊...各位看到啥错别字或者不明白的地方，请给我留言指出来，感谢感谢。
gmail.com
23个评论在 "网站技术分析报告之——开心网（kaixin.com）"
2010-4-26 09:06
你好，贵站的版权链接已经加上了，实在不好意思，因为此篇文章并不是在这里转载的，并不知道源地址，所以请谅解。 现在已经加上了，友情链接也已经加上。
2010-4-26 09:22
呵呵，感谢阁下尊重版权
2010-4-22 10:05
其实分析还仅限于表面，已经发现不少问题，需要说明的是这个山寨kaixin网的架构也是静态资源分离的，css和js都是单独服务器s.xnimg.cn，而且使用了cdn, 可以有效的减轻带宽压力。
但是分离不彻底，比如首页的大图片就没有cdn
2010-4-22 12:18
呵呵，在没有看到架构及代码的情况下，只能是通过表面进行分析，但所谓管中窥豹，可见一斑，又曰：透过现象看本质，还是多多少秒可以看到一个问题的，细节上的处理，更容易看出一个公司的水平
2010-4-21 21:23
学习了~
2010-4-21 15:47
楼主分析比较到位，不过提醒一下：
js混淆是不推荐做的，混淆的执行容易导致客户端cpu彪高，如果客户的浏览器/windows因此而crash了，你想他下次还来么？
另一个比较尴尬的地方就是之前遇到部分国产娱乐类杀毒工具，如金xx霸，瑞xx会把packer过的代码当成病毒。
所以综合考量起来还是只作minify+gzip不做混淆的好。
图片可以用smash.it或者具体对应的工具去优化一下，比ps应该不惶多让，合并小图片的说法是对的。
css/js部分可以选择性合并以及minify，这要看你代码结构的整站重用性规划，合并过度反而浪费带宽。
2010-4-21 16:14
呵呵，任何事情都不能过度，就开心网这个网站来说，那几个图片的合并是没有必要的。对于js的混淆，你的看法很对，不过，js的压缩有三个级别，第一个是去掉注释和空行，第二个是缩短代码变量，第三个才是混淆。一般来说，做到第二个级别的js代码体积已经很小了，混淆后的代码，压缩级别不会超过10%（根据经验估计，不精确）。
对于css代码，去注释空行以及精减写法也是有必要的。
关于合并一事，当然不能一根而论都去合并，你说得没错，要选择性合并，把同质性的代码进行合并，因为用户下载一次浏览器就有缓存了，以后就可以不用下载了，这样肯定是加快浏览速度和降低服务器请求速的，从而达到速度优化的目的。
2010-4-21 12:33
能不能也分析下人人网，我总觉得人人网的代码超烂，像一群实习生搞出来的
2010-4-21 12:42
呵呵，人人网应该会在分析报告中，现在还没有时间，下一步将分析去哪儿
因为开心网和人人网实际上是一家主，所以暂时不分析
敬请期待
2010-4-20 19:07
玩开心网没有一点真实感！！！！！！！！！！！！！
2010-4-20 12:53
页面是用gzip压缩了的，如果使用firebug的话，需要先ctrl+F5查看返回状态为200，如果是304的显然没有gzip字段。
2010-4-20 12:57
你说得没错，在我写这个文章的时候，没有检测到gzip压缩，不过现在已经看到了gzip了。
呵呵，当时没有截图是一个错误，不过也不排除是我看错了
2010-4-20 12:21
关键是在中国这些省下的费用永远不可能奖励给开发人员….
2010-4-20 12:52
呵呵，要善待员工，特别是程序员，一个bug就可以让公司损失比他工资还高。
2010-4-20 12:09
高性能网站建设指南 一本书 全部搞定，
具体到服务器环境配置 CDN配置 7788 8877的东西会麻烦一点 但是不是什么问题。
技术上基本上不是什么问题，一般是体制问题。。。
2010-4-20 12:53
其实是很简单的改变，就可以解决大问题，没那么高深的技术。gzip只是一个开关，压缩也很容易，都是些简单，但确容易忽视的东西。
2010-4-20 11:01
加友情链接 志凡’S BLOG http://www.coderhome.net/zifa/
贵站已加
2010-4-20 11:16
呵呵，友链已加
2010-4-20 10:40
完全同意！很多人没读过这篇文章，可能他们不在乎这点带宽吧，有钱烧的:
Best Practices for Speeding Up Your Web Site
http://developer.yahoo.com/performance/rules.html
2010-4-20 11:08
嗯，其实对于大浏览网站来说，每省下1k，都能节省很多的费用，把这些费用奖励给开发人员，就会带来良性的循环
其实除了google之外，yahoo在open api，程序员开发这方面也下了很多功夫，可惜都是英文的
我觉得这方面，google和yahoo做得比ms好
2010-4-20 10:36
我也看了一下，目前你说的大部分问题，似乎都没有存在啊，，首页也才164.8K
2010-4-20 10:40
不是首页，是登陆注册页，呵呵。网址是：http://reg.kaixin.com/kx7201.do?ss=10112&rt=26。请看我文中的说明
2010-4-20 10:22
人家根本没把重心放在这个山寨开心上
再说有SOFTBANK在后支撑，烧点钱有啥么