特別說一下了，這些方案并非適合所有的網(wǎng)站，很多部分有的網(wǎng)站還是不要做反而會更好。如果你還有更多的想法，可以到這里討論或者評論，我只是歸檔成為方便閱讀的，對了論壇和群討論的另一些結果如果有價值我也會補充進來。

如何快速的呈現(xiàn)我們的網(wǎng)頁?

一.我們需達解決的麻煩
減少HTTP請求數(shù). 減少HTTP請求數(shù)有什么好處
降低服務器跟客戶端的建立和消除HTTP請求和響應Header的開銷
減少服務器為HTTP連接的進程和線程的開銷,如果可能,還會包括GZIP壓縮的CPU開銷.
減小被請求文件大小, 減少請求數(shù)據(jù)占用的網(wǎng)絡帶寬.
讓用戶更快的看到想要的結果.
提高客戶端渲染速度.
讓瀏覽器同時能請求更多的數(shù)據(jù).
提高服務器相應速度.
通過版本化控制客戶端Cache.

二.如何解決我們的麻煩

A.如何減少HTTP請求數(shù)
合并JS文件跟CSS文件。
合并框架圖片以及相對變動較少的圖片成一張，通過CSS背景切割來完成渲染，比如：加速圖片顯示。
合理使用本地Cache來緩存JS/CSS/IMAGE。
合理使用UserData緩存JS文件,對于FF用戶可以單獨請求服務器,這樣能解決80%用戶的問題.代碼可以蓉兒(meizz)的js framework1。
把JS跟CSS合并成一個文件

B.減小被請求文件大小,減少請求數(shù)據(jù)占用的網(wǎng)絡帶寬
壓縮JS體積：刪除JS中空白換行,注釋,混淆把長變量換成短變量；
壓縮CSS體積：刪除CSS注釋、寫法盡量用簡寫；
使用(X)HTML+CSS方式搭建網(wǎng)站結構,提高CSS重用性,來減少(X)HTML文件大??；
使用服務器端GZIP壓縮JS/ CSS文件,縮小傳輸文件大小。附注:Apache1跟Apache2的GZIP的效率跟方式不一樣的，根據(jù)需要自行選擇。
嗷嗷補充說明：壓縮、合并JS和CSS都由程序處理。而不是自己手動去縮刪，不然不利于后期維護。

C.讓用戶更快的看到想要的結果
用戶對于一個站點的白頁的忍受時間根據(jù)統(tǒng)計是8-12秒。白頁的產(chǎn)生可能由于各種原因引起,我們能做的就是怎么讓用戶能變的稍微能等待更久。

方案1.多做一個引導頁,讓用戶體會其中的變化
案例:mail.aol.com中的loading引導頁
方案2.優(yōu)先載入頁面結構以及結構圖片,后一步載入當前頁面數(shù)據(jù),再后一步載入Iframe,Flash等數(shù)據(jù).讓用戶盡早的看到被打開頁面的希望.
D.提高客戶端渲染速度
這個問題就比較泛泛了,影響客戶端的渲染速度有多方面的,主要目的都是提高程序方面的效率.

對于大索引的結構,盡可能的少用索引訪問,能用訪問兄弟節(jié)點的方式盡可能用訪問兄弟節(jié)點的方式.
字符串拼接盡可能用數(shù)組方式
大規(guī)模添加節(jié)點數(shù)據(jù),請不要使用appendChild方式,盡量使用類似innerHTML的insertAdjacentHTML方式,FF下需修正2
E.讓瀏覽器同時能請求更多的數(shù)據(jù).
瀏覽器默認只是支持單域名同時有兩個HTTP請求,使用多域名將能把請求數(shù)提高,在網(wǎng)絡條件優(yōu)良的情況下,能更快的下載數(shù)據(jù),呈現(xiàn)結果.

F.提高服務器相應速度
對于需快速響應的文件,把其放入快速響應的服務器,應該是不錯的方案,優(yōu)化方案請系統(tǒng)儲備組提供.

G.通過版本化控制客戶端Cache.
通常js/css這類文件改動比較頻繁,但是為了加載速度變快,我們有可能需要設定這類文件的過期時間為幾天后,這樣我們碰到的問題就是,如何及時更新這些在cache的文件?
通過一個簡單的配置,通過修改JS的版本來及時告訴瀏覽器,這些文件必須重新請求了,不要繼續(xù)使用瀏覽器cache中的數(shù)據(jù). 方案有好幾個:

手動改這些js的文件名
手動改這些js的路徑
通過URL Rewrite方式來改重定位js路徑
通過一個在高響應服務器上的一個js配置告知頁面,這個頁面該鏈接哪些JS文件
大版本不變,小版本不斷追加,等一定時間后,統(tǒng)一更新,高效利用cache