讀者投稿：一直在研究互聯網技術，經常訪問這樣那樣的網站，突發奇想，為什么我們不去看看這些網站的技術架構是怎么樣的呢？研究一下源代碼？于是便有了這個系列，首先找誰呢？還是找山寨版的開心網開刀吧，這個開心網，不是那個開心網，呵呵。

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

　　本系列文章僅僅是個人研究發布，僅供參考。

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

　　開心網首頁是一個簡單的登陸頁，居然做到了385.2KB之大，像開心網這么大的流量，每多1kb就意味著每天N多的錢哪。我沒有找到官方的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，并將這些文件緩存起來

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

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

轉載于:https://www.cnblogs.com/ZhangHuaning/archive/2011/01/20/1940026.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。