網站技術分析報告之——開心網

來源:互聯網
上載者:User

  讀者投稿:一直在研究互連網技術,經常訪問這樣那樣的網站,突發奇想,為什麼我們不去看看這些網站的技術架構是怎麼樣的呢?研究一下原始碼?於是便有了這個系列,首先找誰呢?還是找山寨版的開心網開刀吧,這個開心網,不是那個開心網,呵呵。

  坦白說,我不太想註冊,也不想研究太多太多,一般來說,一個網站最重要的是首頁,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,否則視為侵權。



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。