讀者投稿：一直在研究互聯(lián)網(wǎng)技術(shù)，經(jīng)常訪問這樣那樣的網(wǎng)站，突發(fā)奇想，為什么我們不去看看這些網(wǎng)站的技術(shù)架構(gòu)是怎么樣的呢？研究一下源代碼？于是便有了這個(gè)系列，首先找誰呢？還是找山寨版的開心網(wǎng)開刀吧，這個(gè)開心網(wǎng)，不是那個(gè)開心網(wǎng)，呵呵。

　　坦白說，我不太想注冊，也不想研究太多太多，一般來說，一個(gè)網(wǎng)站最重要的是首頁，Ok，那我們就從首頁開始吧。

　　本系列文章僅僅是個(gè)人研究發(fā)布，僅供參考。

　　分析工具：各種瀏覽器，firebug（一個(gè)基于firefox的插件）

　　開心網(wǎng)首頁是一個(gè)簡單的登陸頁，居然做到了385.2KB之大，像開心網(wǎng)這么大的流量，每多1kb就意味著每天N多的錢哪。我沒有找到官方的pv 或獨(dú)立Ip的數(shù)據(jù)，根據(jù)alexa的數(shù)據(jù)參考一下吧，估計(jì)日均獨(dú)立IP為528，000，我們估計(jì)按每獨(dú)立IP訪問一次登陸吧，實(shí)際上可能少一些，因?yàn)楹芏嘤脩艨赡苤苯釉谑醉撋系顷懥?#xff08;alexa的數(shù)據(jù)也不是那么可靠，供參考吧）。

　　開心網(wǎng)的網(wǎng)頁每增加1k，我們需要多少帶寬？算一下，我們需要528，000/1024=515MB/天的帶寬，然后我們平均一下，按一天24小時(shí)用戶訪問很平均來計(jì)算（實(shí)際上不可能，一般峰值訪問會(huì)是平均值的一倍以上），每秒需要消耗帶寬是528000 / （24小時(shí) * 60分鐘 * 60秒）=6Kb，考慮到峰值，估計(jì)要到12k以上。

　　看官，像開心網(wǎng)這么簡單的登陸，完全可以控制在100k以內(nèi)的大小，為什么要這么多呢，一會(huì)兒看網(wǎng)頁的分析就可以知道了。這是什么概念？385-100=285k，再算出帶寬得出：285k * 12k / 1024 = 3.3M.乖乖，開心網(wǎng)每天需要添加3.3M的獨(dú)享帶寬。3.3M的帶寬會(huì)是多少錢呢？我們就以中檔的機(jī)房來舉例，北京中檔的3M獨(dú)立帶寬，怎么也得3-5萬塊吧，再加上CDN的帶寬，估計(jì)開心網(wǎng)每年需要為此增加5-8萬的費(fèi)用。

　　分析一下開心網(wǎng)存在的問題：

　　1. Javascript文件直接寫在了網(wǎng)頁當(dāng)中

　　開心網(wǎng)的登陸頁有大量的javascript的代碼，這樣的代碼一方面不利于維護(hù)，另一方面，也不利用用戶加載頁面。大致計(jì)算了一下，開心網(wǎng)登陸頁一個(gè)有180余行的javascript代碼，而總代碼僅在336行，也就是說代碼中的javascript代碼占了1/2 強(qiáng)。

　　2. 網(wǎng)頁沒有開啟gzip

　　根據(jù)文件頭返回的信息可以看到，開心網(wǎng)應(yīng)該在linux上搭建了nginx ，添加gzip應(yīng)該不會(huì)是很難的事吧？而且像html及靜態(tài)js/css這些文件，gzip后起碼可以減少50%的傳輸量，當(dāng)是這一項(xiàng)，就可以每年省下上百萬的費(fèi)用。

　　當(dāng)然有人會(huì)反對，認(rèn)為gzip會(huì)加重服務(wù)器的壓力，并且客戶端解壓的時(shí)間與減小文件大小帶來的傳輸速度不會(huì)有太多好處。但我認(rèn)為，對于靜態(tài)文件來說，可以放到獨(dú)立的服務(wù)器，這個(gè)服務(wù)器可以把文件壓縮后放到緩存中，這樣不用去讀IO，響應(yīng)速度會(huì)提高。同時(shí)，雖然現(xiàn)在用戶的帶寬都已經(jīng)是512k的 adsl以上了，但是為什么我不可以讓用戶更快的看到我們的網(wǎng)頁呢？退一萬步說，用戶真的在乎這個(gè)快幾秒的，那么我們?yōu)槭裁床豢梢詼p小帶寬的壓力以節(jié)省成本呢？如果把節(jié)省下的這些錢去獎(jiǎng)勵(lì)員工，沒準(zhǔn)他們可以給我?guī)砀嗟捏@喜呢。

　　3. Javascript沒有做任何處理

　　開心網(wǎng)的 javascript可真有意思，他們的開發(fā)人員代碼質(zhì)量還不錯(cuò)，起碼注釋寫得還不錯(cuò)，可是問題是，你需要把這些注釋都發(fā)到客戶端么，難道開心網(wǎng)想教我們怎么寫javascript代碼？這樣的代碼發(fā)到客戶端，既占帶寬又會(huì)泄密網(wǎng)站的代碼。

　　開心網(wǎng)的核心javascript文件xn.core.js有105k，這么大的其中注釋占了不少的代碼，我嘗試使用yahoo和google的壓縮工具進(jìn)行壓縮，但因?yàn)榇a中有錯(cuò)誤無法完成，所以只好放棄。但我估計(jì)這個(gè)js，最基本的壓縮去除空行和注釋，可以減少1/5左右的大小，如果進(jìn)行一些混淆的話，應(yīng)該可以在40k左右，如果再gzip的話，應(yīng)該就只有15k以內(nèi)了。

　　4. 圖片文件過大

　　登錄頁有一個(gè)157k的sys-bj2.jpeg文件，天啦，這么大的。我下載這張圖片一看，發(fā)現(xiàn)這個(gè)圖片實(shí)際是同幾張圖片組合的。他們的設(shè)計(jì)人員其實(shí)是想減少網(wǎng)頁對服務(wù)器的請求數(shù)，所以把幾個(gè)圖片合并到一塊。但是，他們這種做法是錯(cuò)誤的。

　　我們要減少請求數(shù)，一般是把小圖片，一般是幾k的36 px* 36px以下的小圖片合并，而不是把大圖片也合并。因?yàn)樾D片數(shù)量多，而大圖的合并，也會(huì)增加圖片的大小。我將這個(gè)圖片用ps再優(yōu)化一下，優(yōu)化到 66k，也沒發(fā)現(xiàn)明顯的失真。所以我認(rèn)為，就算是大圖，也可以優(yōu)化到80k以內(nèi)，而不是如此157k大小的圖片。

　　再多一句，這個(gè)圖片總量才5個(gè)合并是完全沒有必要的，并且圖片最大的有600px*255px，而最小的只有10px*10px以下，這種合并沒有任何益處，百害而無一益！

　　總結(jié)

　　開心網(wǎng)作為一個(gè)訪問量非常大的網(wǎng)站，網(wǎng)頁結(jié)構(gòu)也非常簡單，理應(yīng)做得更小，比如在100k以內(nèi)。從我的分析中可以看出，主要問題集中在 javascript，gzip和圖片上，代碼質(zhì)量總體還可以。當(dāng)然，我們不僅只是挑刺，也應(yīng)該看到一些好的地方，如下：

　　1. 首頁處理得比較到位，雖然javascript也沒有壓縮，但總大小只有108k

　　2. 文件請求數(shù)較少，這個(gè)和開心網(wǎng)本身有關(guān)，開心網(wǎng)本來就不是一個(gè)網(wǎng)頁結(jié)構(gòu)復(fù)雜的網(wǎng)站，所以文件數(shù)自然會(huì)比較少了

　　3. 靜態(tài)文件和網(wǎng)頁分開部署

　　4. Javascript注釋比較好，但不應(yīng)該發(fā)到客戶端

　　重要建議：

　　1. 開啟gzip壓縮

　　2. 壓縮javascript及css，并將這些文件緩存起來

　　最后，這次的分析就寫到這里了，就事論事而已，和任何網(wǎng)站及相關(guān)的人員沒有任何關(guān)系，呵呵。

　　來源：讀者Conis投稿，原文地址。版權(quán)聲明：本文授轉(zhuǎn)月光博客刊登，其他非授權(quán)網(wǎng)站媒體轉(zhuǎn)載，需要添加作者網(wǎng)站地址http://iove.net，否則視為侵權(quán)。

轉(zhuǎn)載于:https://www.cnblogs.com/ZhangHuaning/archive/2011/01/20/1940026.html

總結(jié)

以上是生活随笔為你收集整理的网站技术分析报告之——开心网_转载的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。