沒事使用代理上了下facebook，注冊進入個人首頁后，習慣性的查看源代碼，發現了1個很有意思的現象，首頁內容不少，但源代碼中HTML的代碼卻很少，但去多出了很多段的javascript代碼，這些js代碼都是用于動態生成html的，facebook為什么需要這樣做了？出于職業習慣，研究研究：
一、html代碼。
先看看首頁查看的源代碼，因為源代碼比較大，所以把圖片壓縮了下，可能看不太清楚，只需要注意圖中紅色是html代碼，其余黑壓壓一片的就全部是JS代碼：
二、JS代碼
看到黑壓壓的JS代碼是不是被嚇一跳，下面就截取一段JS來分析(其余段的JS都是類似的)，facebook源代碼中充斥了類似于下面的JS代碼：
讓我們再看看big_pipe.onPageletArrive函數到底做了什么了？我們只關注參數中的id,js,css,content4個參數，可以看出js和css都是進行過編碼，下面是解碼后我們關注的代碼：
看到還原后的JS，你應該猜出onPageletArrive函數是干嘛的吧，其實onPageletArrive最主要實現就是把"content"中的html內容插入到對應id(上面的"pagelet_welcome_box")的html元素中,并下載對應的css和JS。
三、chunk、flush
看到上面的分析后，大家一定奇怪，facebook為什么要生成那么多段JS，再用js去動態插入html代碼，這不是脫了褲子放屁，多此一舉嗎？還不如直接生成html代碼了。facebook當然不會那么笨了，讓我們先監控下facebook的http請求，監控圖如下：
注意上圖中紅色部分，原來facebook使用了chunk對頁面進行分塊輸出。這就比較容易理解了，facebook首頁的js代碼段不是1次就全部輸出的，而是一段一段進行輸出的。
什么是chunk和如何使用chunk,請參考我的另1篇博文：flush讓頁面分塊,逐步呈現
總結
facebook使用chunk技術讓頁面分塊輸出成很多JS段，這樣做的好處就是服務器和客戶端可以并行進行處理，不用等服務器全部處理完畢，客戶端才進行處理。
舉個博客園首頁的列子，博客園首頁分為下面幾塊("推薦博客排行","首頁隨筆列表","最新新聞"...),
我們一般對該http請求處理如下：
1. 瀏覽器發送http請求
2. 服務器處理請求(從緩存讀取前50個推薦博客，從數據庫讀取"首頁隨筆列表",從數據庫讀取"最新新聞")，生成首頁的html代碼。
3. 服務器發送html代碼給客戶端
4、瀏覽器接收到響應，處理html(下載css,js,image,執行js等等)
可以看出傳統的http請求4個過程中，每個過程都必須等待前1個過程完成后才能執行，這樣就存在很大的資源浪費。
facebook的對該http請求的處理如下：
1. 瀏覽器發送http請求
2. 服務器處理請求(從緩存讀取前50個推薦博客,生成"推薦博客"的js代碼段，flush輸出該代碼段,
服務器繼續讀取"首頁隨筆列表"，并生成輸入js代碼段。
服務器繼續讀取"最新新聞"，并生成輸入js代碼段。
3. 瀏覽器接收到js代碼段，下載該代碼段所需的js和css。插入html代碼。
在這個處理流程中，最大的特點就是2,3是并行進行處理的，服務器處理完一部分數據就把已經處理好的數據交給瀏覽器進行呈現處理，自己再繼續處理其他的數據。
PS：文章看完了，有些同學可能會想，為什么不像博客園一樣，前臺全部用ajax來異步讀取"推薦博客" ,“最新新聞”的數據了，這樣做就不會出現因為要處理太多數據而讓客戶端等待太久的問題了。我覺得對于facebook這種并發量巨大的網站，使用這種方法無疑會產生太多的請求，比如facebook首頁用了14個chunk，如果使用ajax，則需要多14個request請求，這將增加不少服務器的壓力吧。
相關文章： 名站技術分析 — 淺談tudou.com首頁圖片延遲加載的效果