一秒幾十萬！網(wǎng)頁載入速度很重要

Amazon 的網(wǎng)頁載入時間每多一秒，該公司的年度營收就減少 16 億美元;Google 的搜索時間每多 0.4 秒，每天的搜尋次數(shù)就會減少 8 百萬。這些都告訴我們網(wǎng)頁的載入時間長短非常重要，而 i黑馬先前也寫過一篇“科技發(fā)展使人們開始失去耐心?”談影片的載入時間與使用者行為的關(guān)系，那么網(wǎng)頁的載入時間是不是也是這樣子呢?

　　Cucumbertown 用了許多不同的策略，以確保網(wǎng)頁可以在 2 秒內(nèi)載完，最多 3 秒。我們非常熱衷于改善這件事，甚至還設(shè)定了一些提醒機制以防載入時間超過 3 秒。

　　然而，就在 Chris Zacharias 寫了“Page Weight 很重要(Page Weight 只的不單是網(wǎng)頁檔案大小，還包括網(wǎng)頁自動執(zhí)行的動作多寡等)”(注一)這篇文章之前，一封 Google Analytics 寄來的信通知了我們，網(wǎng)頁的載入時間超過了 20 秒，我們立刻放下手邊的一切去找出究竟發(fā)生了什么事。

　　通常網(wǎng)頁載入的延遲發(fā)生之后，就會馬上被隨機測試或是我們的重度使用者給發(fā)現(xiàn)，但這次并沒有，提醒機制甚至隔了一天才啟動。這把你嚇壞了，一個你還沒有搞清楚的未知問題，比起一些大的臭蟲來說更加危險。

　　我們便開始進行探測，而結(jié)果就如下圖所看到的：

　　當然，Google Analytics 分析了平均載入時間，而這分析影響了結(jié)果。但將這與其他分析結(jié)果放在一起看，似乎還是可以得出一些結(jié)果。Cucumbertown 的連結(jié)被放在一個奈及利亞的美食頻道和一個泰國的知名博客上，導致大量的流量湧入。網(wǎng)頁載入速度在這些國家就如同你所看到的，可笑的慢。

　　我們的 Cucumbertown 是一個內(nèi)容很多的網(wǎng)站，即便利用 requireJS 延遲以及基于使用者需求來載入 JavaScript，與網(wǎng)頁腳本載入有關(guān)的成本還是相當顯著。即便載入文件物件模型(Document Object Models)都要花時間。

　　在美國地區(qū)的網(wǎng)頁載入時間為 2.5 秒證實了這件事，DSL 裝置的 43 毫秒載入時間普及全球(注二)，現(xiàn)在是時候開始考慮內(nèi)容傳遞網(wǎng)絡(luò)(Content Delivery Network)了。

　　我們在 Zynga 一開始是依賴 Akamai(編按：作者為前 Zynga 資深軟件工程師)，隨后換成 LimeLight 。但最近我們發(fā)現(xiàn) CloudFlare 在 Hacker News 上有一些活動，而且他們提供的功能也很吸引人去一探究竟，于是我就決定做個小小嘗試。

　　現(xiàn)在這個博客(gigpeppers)就是通過 CloudFlare 來提供的服務，并透過內(nèi)容傳遞網(wǎng)絡(luò)來傳遞內(nèi)容。當網(wǎng)站有大量的流量湧入的時候，這個模式帶來的體驗非常的棒，但如果沒有持續(xù)的請求時，這個模式反而會讓之后的網(wǎng)頁載入效率變差，但效率依然還是可以漸漸回到 1.5~2 秒之間。(編按：有點類似靜摩擦力的啟動阻力比動摩擦力還要大的概念。)

　　我依然認為內(nèi)容傳遞網(wǎng)絡(luò)是一種企業(yè)用的昂貴方式。但我們這樣一個新創(chuàng)公司現(xiàn)在就正在使用，并把服務提供給全世界，而且這似乎是一個很重要的解決方法。