第二張小圖片花費(fèi)時(shí)間為：
Blocked：16.274s
Send：小于0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗時(shí)：16.790s
真正用于傳輸文件的花費(fèi)時(shí)間是Reveive時(shí)間，即0.397s，這的確要比剛才大文件的4.596s小很多。但是他的Blocked時(shí)間為16.274s，占總時(shí)間的97%。

如果這些數(shù)據(jù)還不夠說服你的話，讓我們看看下面這張圖。這里列出了某個(gè)網(wǎng)頁中所有圖片中的花費(fèi)時(shí)間示意圖。當(dāng)然，里面的圖片有大有小，規(guī)格不一。
其中藏青色的為傳輸文件花費(fèi)的Reveive時(shí)間，而前面白色的為檢索緩存和確認(rèn)鏈接是否有效的Blocked時(shí)間。鐵一樣的事實(shí)告訴我們：

• 大文件和小文件下載所需時(shí)間的確是不同的，差異的絕對值不大。而且下載所需時(shí)間占總耗費(fèi)時(shí)間比例很小。
• 大約80%以上的時(shí)間是用來檢索緩存和確定鏈接是否有效的Blocked時(shí)間。無論文件大小，這個(gè)時(shí)間的花費(fèi)大致是相同的。而且所占總耗費(fèi)時(shí)間的比例是極大的。
• 一個(gè)100k的大圖片總耗費(fèi)時(shí)間絕對大于4個(gè)25k的小圖片的總耗費(fèi)時(shí)間。而且主要差別就是4個(gè)小圖片的Blocked時(shí)間絕對大于1個(gè)大圖片的Blocked時(shí)間。

所以如果可能還是使用大圖片來替代過多的瑣碎的小圖片吧。這也是為什么翻轉(zhuǎn)門的效率要高于圖片替換實(shí)現(xiàn)的滑動(dòng)門的原因。
但是，請注意：也不能用太大的單張圖片，因?yàn)槟菢訒?huì)影響到用戶體驗(yàn)。例如個(gè)幾兆的背景圖片的使用絕對不是一個(gè)好主意。

2：合并你的css文件。

我以前犯了一個(gè)錯(cuò)誤，你在看我《樣式表的組織與規(guī)劃》的系列文章中會(huì)知道。當(dāng)時(shí)，我為了方便組織和規(guī)劃樣式表，將用于不同用途的樣式表文件分離開來，形成不同的css文件。然后在頁面中根據(jù)需要引用多個(gè)css文件。根據(jù)“盡可能的減少HTTP的Request請求數(shù)”準(zhǔn)則我們知道，那樣的確是不合理的，因?yàn)槟菢訒?huì)產(chǎn)生更多的HTTP的Request請求數(shù)。從而降低網(wǎng)頁的效率。所以，從提高網(wǎng)頁效率的角度上而言，我們還是應(yīng)該將所有的css寫在同一個(gè)css文件中。但是問題又來了。那么怎么來很好的組織和規(guī)劃樣式表呢？這的確是個(gè)矛盾。我現(xiàn)在的做法是采用兩套版本。編輯版和發(fā)布版。編輯版仍然使用多個(gè)css文件以便于規(guī)劃和組織。而等到發(fā)布的時(shí)候，再將多個(gè)css文件合并到一個(gè)文件中去，從而達(dá)到減少HTTPRequest請求數(shù)的目的。

3：合并你的javascript文件。

原因和處理方法同上，不再贅言。

 

第二條：Use a Content Delivery Network 使用CDN

這個(gè)看上去好像很深?yuàn)W的樣子，但是只要結(jié)合中國的網(wǎng)絡(luò)特色，這個(gè)便不難理解了?！氨狈椒?wù)器”、“南方服務(wù)器”、“電信服務(wù)器”、“網(wǎng)通服務(wù)器”……這些詞聽起來是那么熟悉和壓抑。如果，一個(gè)北京的電信用戶試圖從廣東的網(wǎng)通服務(wù)器上打開一個(gè)類似《壁紙合集》帖子的網(wǎng)頁時(shí)，你就能很深刻的理解。
鑒于這個(gè)不是我們開發(fā)人員力所能及的準(zhǔn)則，所以這里也就不多言了。

最新評論