全方位提升網站開啟速度：前端、後端、新的技術

這裡是 我們 充分利用對於網路快取和 NoSQL 系統的研究，做出一個可以容納幾十萬通過電視宣傳慕名而來的訪問者的 網上商城 的故事，以及我們從中學到的一切。

"Shark Tank"（美國），"Dragons’ Den"（英國）或" Die Höhle der Löwen（DHDL）"（德國）等電視節目為年輕初創公司供了一次在眾多觀眾前向商業大亨推銷自己產品的機會。然而，主要的好處往往不在於評審團提供的戰略投資——只有少數交易會完成——而是在電視節目播放期間引發的關注：即使是幾分鐘的直播也能給網站帶來幾十萬的新使用者，同時能夠提高几周、幾個月甚至永久性的網站基本活躍水平。也就是說，如果網站可以抓住初始負載尖峰，並且不拒絕使用者請求……

僅僅可用是不夠的——延遲是關鍵！

網上商城的盈利壓力特別大，因為他們不只是消遣專案（諸如部落格），但通常由於創始人本身有大量投資支援，必須轉化為利潤。很明顯，對於商業業務來說，最壞的情況是網站過載，在此期間伺服器不得不丟掉部分使用者請求甚至可能完全崩潰。這並不像你想象的那樣罕見：在 DHDL 的這一季，大約有一半的網上商店在直播現場就無法連線了。並且，保持線上只有一半的租金，因為使用者滿意度是強制連線到轉化率，從而直接轉化為產生的收入的。

關於頁面載入時間對客戶滿意度和轉換率的影響，有很多 研究 支援這種說法。例如，Aberdeen Group 發現，額外延遲的 1 秒會導致頁面瀏覽量減少 11％，轉化次數損失 7％。 但你也可以詢問

怎樣讓網站加速

為初創公司 Thinks 搭建的網上商城參與了 DHDL，並在 9 月 6 日播出。我們面臨著一個挑戰，搭建一個能夠承受數十萬訪客量的網上商店，並且載入時間穩定在 1 秒以內。以下都是我們在這個過程中以及從近些年對資料庫和網路的效能研究中學到的。

在現有的 web 應用技術中有三個影響頁面載入時間的主要原因，展示如下：

1. 後端處理：web 伺服器需要時間從資料庫載入資料和整合網站。
2. 網路延遲：每個請求需要時間從客戶端傳輸到伺服器，並返回（請求延遲）。當考慮到平均每個網站需要發出超過 100 個請求 才能完全載入時，這變得更加重要。
3. 前端處理：前端裝置需要時間來渲染頁面。

為了讓我們的網店加速，讓我們一一解決這三個瓶頸。

前端效能

影響前端效能最重要的因素是關鍵呈現路徑（CRP），它描述了在瀏覽器中向用戶顯示頁面所需的 5 個必要步驟，如下所示。

關鍵呈現路徑的步驟：

• DOM：當瀏覽器解析HTML時，它會增量式地生成一個 HTML 標籤的樹模型，稱為 文件物件模型（DOM），該模型描述了頁面內容。
• CSSOM：一旦瀏覽器接收到所有的 CSS，它會生成一個 CSS 中包含的標籤和類的樹模型，稱為 CSS 物件模型，在樹節點上還附有樣式資訊。這棵樹描述了頁面內容是如何設定樣式的。
• 渲染樹：通過組合 DOM 和 CSSOM，瀏覽器構造一個渲染樹，它包含頁面內容以及要應用的樣式資訊。
• 佈局：佈局這一步計算螢幕上頁面內容的實際位置和大小。
• 繪製：最後一步使用佈局資訊將實際畫素繪製到螢幕上。

單個步驟是相當簡單的，使事情變得困難並限制性能的是這些步驟之間的依賴。DOM 和 CSSOM 的構造通常具有最大的效能影響。

這個圖表顯示了關鍵呈現路徑的步驟，裡面包括等待依賴，如箭頭所示。

關係呈現路徑中重要的依賴

在載入 CSS 和構造完整的 CSSOM 之前，什麼都不能顯示給客戶端。因此 CSS 被稱為是阻塞渲染的。

JavaScript（JS）更糟糕，因為它可以訪問和更改 DOM 和 CSSOM。 這意味著一旦發現 HTML 中的指令碼標記，DOM 構造就會被暫停，並從伺服器請求指令碼。一旦指令碼被載入，只有在所有 CSS 被提取和 CSSOM 被構造以後，它才能被執行。在 CSSOM 構建之後 JS 被執行，在下面的例子中，它可以訪問和改變 DOM 以及 CSSOM。只有這樣之後，DOM的構造才能進行，並且頁面才能顯示給客戶端。因此 JavaScript 被稱為是阻塞解析的。

JavaScript 訪問 CSSOM 和更改 DOM 的示例：

<script>
   ...
   var old = elem.style.width;
   elem.style.width = "50px";
   document.write("alter DOM");
   ...
</script>

JS 甚至會影響更惡劣。例如 jQuery 外掛 訪問計算後的 HTML 元素的佈局資訊，然後開始一次又一次地改變 CSSOM，直到實現了所需的佈局。因此，在使用者將看到白色螢幕以外的任何東西之前，瀏覽器必須一次又一次地重複地執行 JS、構造渲染樹和佈局。

有三個優化 CRP 的 基本概念：

1. 減少關鍵資源： 關鍵資源是頁面最初渲染時所需的資源（HTML，CSS，JS 檔案）。通過將渲染不滾動時可見的網站部分（稱為首屏）所需要的 CSS 和 JS 內聯可以大大減少關鍵資源。接下來的 JS 和 CSS 應該被非同步載入。無法被非同步載入的檔案可以拼接到一個檔案中。
2. 最小化位元組： 通過最小化和壓縮 CSS，JS 和影象，可以大大減少 CRP 中載入的位元組數。
3. 縮短 CRP 長度： CRP 長度是獲取所有關鍵資源所需的與伺服器之間的最大連續往返數。它可以通過減少關鍵資源和最小化它們的大小（大檔案需要多個往返來獲取）來縮短。將 CSS 放在 HTML 頂部，以及 JS 放在 HTML 底部，可以進一步地縮短它的長度，因為 JS 執行總是會阻塞對 CSS 的抓取、對 CSSOM 和 DOM 的構造。

此外，瀏覽器快取 是非常有效的，應該在所有的專案中加以使用。它對於這三個優化項都很合適，因為快取的資源不必先從伺服器載入。

CRP 優化的整個主題是相當複雜的，特別是內聯、級聯和非同步載入，它們可能會破壞程式碼的可重用性。幸運的是，有很多強大的工具，可以為你做好這些優化，這些工具可以被整合到你的構建和部署鏈裡。你的確應該地看看下面的工具……

有了這些工具只需很小的工作量，你就可以打造一個前端效能極好的網站。這裡是 Thinks 商城第一次訪問時的頁面速度測試：

thinks.com 的 Google 網頁速度分數

有趣的是，PageSpeed Insights 內部唯一的抱怨是，Google 分析的指令碼快取生命週期太短。所以 Google 基本上在抱怨它自己。

來自加拿大（GTmetrix）的第一次頁面載入，伺服器託管在法蘭克福（Frankfurt）

網路效能

網路延遲是頁面載入時間最重要的因素，它也是最難優化的。但在我們進行優化之前，讓我們看一下對初始的瀏覽器請求的劃分：

當我們在瀏覽器中輸入 https://www.thinks.com/ 並按下回車鍵時，瀏覽器開始使用 DNS 查詢來識別與域相關聯的 IP 地址，這種查詢必須對每個單獨的域進行。

使用接收到的 IP 地址，瀏覽器初始化與伺服器的 TCP 連線。TCP 握手需要 2 次往返（1 次是 TCP 快速開啟）。使用安全的 SSL 連線，TLS 握手需要額外的 2 次往返（1 次是 TLS False Start 或 Session Resumption）。

在初始連線之後，瀏覽器傳送實際請求並等待資料進入。第一個位元組到達的時間主要取決於客戶端和伺服器之間的距離，包括伺服器渲染頁面所需的時間（包括會話查詢、資料庫查詢和模板渲染等）。

最後一步是在可能的多次往返中下載資源（在這種情況下指的是 HTML ）。新連線尤其通常需要很多往返，因為初始擁塞視窗很小。這意味著 TCP 不是從一開始就使用全頻寬，而是隨著時間的推移而增加頻寬（參見 TCP擁塞控制。下載速度受到慢啟動演算法的支配，該演算法在每次往返的擁塞視窗中將報文段數量加倍，直到丟包發生。在行動網路和 Wifi 網路上丟失資料包因此具有很大的效能影響。

另一件要記住的事是：使用 HTTP/1.1，你只能得到 6 個並行連線（如果瀏覽器仍然遵循原始標準，則連線數為 2）。因此，你最多隻能請求 6 個資源並行。

為了對網路效能對於頁面速度的重要性有一個直觀的認識，你可以檢視 httparchive ，上面有很多統計資料。例如，網站平均在 100 多個請求中載入大約 2.5 MB的資料。

來源

所以網站發出了很多小的請求來載入很多資源，但網路頻寬一直在增加。物理網路的演進將拯救我們，對吧？嗯，其實並不是……

事實證明，將頻寬增加到 5 Mbps 以上並不真的影響頁面載入時間。但減少單個請求的延遲會降低網頁載入時間。這意味著頻寬加倍帶來的是相同的載入時間，而減少一半的延遲將給你一半的載入時間。

因此，如果延遲是網路效能的決定因素，我們可以在這上面做些什麼呢？

• 持久連線是必須有的。沒有什麼比當你的伺服器在每個請求後關閉連線，並且瀏覽器必須一次又一次地執行握手操作和 TCP 慢啟動更糟糕的事情了。
• 儘可能地避免重定向，因為它們會大大減慢你的初始網頁載入速度。永遠連結完整的網址（例如使用 www.thinks.com 而不是 thinks.com）。
• 如果可以的話，請使用 HTTP/2。它附帶伺服器推送，能為單個請求傳輸多個資源；頭壓縮來減小請求和響應的大小；並請求流水線和多路複用通過單個連線傳送任意並行請求。使用伺服器推送，你的伺服器可以傳送你的 html ，緊接著推送網站所需的 CSS 和 JS，而無需等待實際請求。

• 為你的靜態資源（CSS，JS，靜態影象如 logo）設定顯式的快取頭。這樣，你可以告訴瀏覽器需要將這些資源快取多長時間以及何時重新驗證。快取可以節省大量的往返和需要下載的位元組。如果沒有設定明確的快取頭，瀏覽器會做 啟發式快取，這比不快取好，但遠不是最佳。

• 使用內容分發網路（CDN）來快取影象、CSS、JS 和 HTML。這些分散式快取網路可以顯著地減少與使用者的距離，從而更快地提供資源。它們還加速了你的初始連線，因為你與附近的 CDN 節點進行 TCP 和 TLS 握手，而這些節點會依次建立熱的和持久的後端連線。

• 建議你使用一個小的初始頁來建立單頁應用程式，這個初始網頁會非同步地載入其它元件。這樣，你可以使用可快取的 HTML 模板，在小請求中載入動態資料，並在導航（navigation）期間只更新頁面的各個部分。

總而言之，當涉及到網路效能時，有一些要做的（do） 和不要做的（don't），但限制因素總是往返次數與物理網路延遲的結合。克服這種限制的唯一有效方法是使資料更接近客戶端。最先進的網路快取狀態的確如此，但這僅適用於靜態資源。

對於 Thinks，我們遵循上述準則，使用 Fastly CDN 和主動的瀏覽器快取，甚至對動態資料使用一種新的 布隆過濾器演算法（Bloom Filter algorithm） 來使得快取資料保持一致。

對於重複網頁載入的請求，瀏覽器快取沒有提供的內容（參見上圖）包括：對 Google 分析的 API 的兩個非同步呼叫，以及從 CDN 處獲取的初始 HTML 請求。因此，對於重複的網頁載入，頁面能夠做到立即載入。

後端效能

對於後端效能，我們需要同時考慮延遲和吞吐量。為了實現低延遲，我們需要將伺服器的處理時間最小化。為了保持高吞吐量和應對負載尖峰，我們需要採用一種水平可擴充套件的架構。我們不會談到太多細節，因為設計決策對效能的影響空間是巨大的，這些是需要去尋找的最重要的元件和屬性：

可擴充套件的後端技術棧元件：負載均衡器，無狀態應用伺服器，分散式資料庫

首先，你需要負載均衡（例如 Amazon ELB 或 DNS 負載均衡）將傳入的請求分配給你的一個應用伺服器。它還應該實現自動調節功能，在需要時生成其他應用伺服器，以及故障轉移功能，以替換損壞的伺服器並將請求重新路由到正常伺服器。

應用伺服器應將共享狀態最小化，從而保持協調最少，並使用無狀態會話處理來啟用自由的負載均衡。此外，伺服器應該有高效的程式碼和 IO，使得伺服器處理時間最小。

資料庫需要承受負載尖峰，並儘可能減少處理時間。同時，它們需要具有足夠的表達性，以根據需要建模和查詢資料。有大量的可擴充套件資料庫（尤其是 NoSQL），每個都有自己的 trade-off。詳細資訊請參考我們關於該主題的調查和決策指南：

Thinks 網上商城搭建在 Baqend 上，使用瞭如下的後端技術棧：

Baqend的後端技術棧：MongoDB 作為主資料庫，無狀態應用伺服器，HTTP 快取層次結構，REST 和 web 前端的 JS SDK

用於 Thinks 的主資料庫是 MongoDB。為了維護我們將要到期的布隆過濾器（用於瀏覽器快取），我們使用 Redis ，因為它的高寫入吞吐量。無狀態應用程伺服器（Orestes Servers）為後端功能提供介面（檔案託管，資料儲存，實時查詢，推送通知，訪問控制等），並處理動態資料的快取一致性。它們從 CDN 拿到請求，CDN 也充當負載均衡器。網站前端使用基於 REST API 的 JS SDK 來訪問後端，後端自動利用完整的 HTTP 快取層次結構來讓請求加速並保持快取資料時刻最新。

負載測試

為了在高負載下測試 Thinks 網上商城，我們在法蘭克福的 t2.medium AWS 例項上使用 2 個應用伺服器來進行負載測試。MongoDB 在兩個 t2.large 例項上執行。使用 JMeter 構建負載測試並在 IBM soft layer 上的 20 個機器上執行，以模擬在 15分鐘內，200,000 個使用者同時訪問和瀏覽網站。20％ 的使用者（40,000）被配置為執行額外的付款流程。

網上商城的負載測試設定

我們在支付實現中發現了一些瓶頸，例如，我們必須從庫存的積極更新（使用 findAndModify實現）切換到 MongoDB 的部分更新操作（inc）。但是在這之後，伺服器處理的負載只是精細地達到了平均請求延遲 5 ms。

JMeter 在負載測試期間輸出：在 12 分鐘內有 680 萬個請求，平均延遲 5 ms

所有的負載測試組合生成了大約 1000 萬個請求，傳輸了 460 GB的資料，伴隨著 99.8％ 的 CDN 快取命中率。

負載測試後的儀表板概述

總結

總之，良好的使用者體驗取決於三個支柱：前端，網路和後端的效能。

前端效能是我們認為最容易實現的，因為已經有很多工具和一些容易遵循的最佳實踐。但仍然有很多網站不遵循這些最佳實踐，完全沒有優化過它們的前端。

網路效能對於頁面載入時間來說，是最重要的因素，也是最難優化的。快取和 CDN 是最有效的優化方法，但即使對於靜態內容也要付出相當大的努力。

後端效能取決於單伺服器效能和跨機器去分發工作的能力。水平可擴充套件性特別難以實現，必須從一開始就考慮。許多專案將可擴充套件性和效能作為事後處理，然而在它們的業務增長時會陷入大麻煩。

文獻和工具建議

有很多關於 web 效能和可擴充套件系統設計的書：由 Ilya Grigorik 所寫的 高效能瀏覽器網路 包含了幾乎所有你需要了解的網路和瀏覽器效能知識，並且目前不斷更新的版本可以免費線上閱讀哦！Martin Kleppmann 寫的 設計資料密集型應用 仍處於前期釋出狀態，但已經是其領域最好的書之一，它涵蓋了可擴充套件後端系統背後的大部分基礎知識，並擁有相當多的細節。設計效能 由Lara Callender Hogan 寫成，圍繞著構建快速的、具有良好的使用者體驗的網站，涵蓋了很多最佳實踐。

最新的 Web 效能開發

移動頁面加速

Google 正在通過諸如 PageSpeed Insights、開發人員指南 等網站效能專案來提高大家對於網站效能的意識，並將網頁速度作為其 網頁排名 的主要因素。

在 Google 搜尋中用來提高網頁速度、增強使用者體驗的最新概念是 移動網頁加速（AMP）。其目的是讓新聞文章、產品頁面和其它搜尋內容立即從 Google 搜尋載入。為此，這些頁面必須構建為 AMP。

一個 AMP 頁面的示例

AMP 主要做兩件事：

1. 構建為 AMP 的網站使用精簡版本的 HTML，並使用 JS 載入器來快速渲染，並非同步載入儘可能多的資源。

2. Google 將網站快取在 Google CDN 中，並通過 HTTP/2 分發。

第一件事從本質上意味著 AMP 以一種方式限制了你的 HTML、JS 和 CSS，這種方式構建的網頁有一個優化的關鍵呈現路徑，可以很容易地被 Google 爬取。 AMP 強制 幾個限制，例如所有 CSS 必須內聯，所有 JS 必須是非同步的，頁面上的所有內容必須具有靜態大小（以防止重繪）。 雖然你可以通過堅持之前的 web 效能最佳實踐，在沒有這些限制的情況下，實現相同的結果，但 AMP 可能是很好的 trade-off ，能夠為非常簡單的網站提供幫助。

第二件事意味著，Google 抓取你的網站，然後將其快取在 Google CDN 中，以便快速分發。網站內容會在爬蟲重新索引你的網站後更新。CDN 還遵循伺服器設定的靜態 TTL，但至少執行 微快取：資源至少在一分鐘內被視為最新的，並在使用者請求進入時在後臺更新。因此 AMP 最適用於內容大多是靜態的使用者案例。這種適用於人為編輯修改的新聞網站或者其他出版物的情況。

漸進式 web 應用（Progressive Web Apps）

Google 的另一種做法是 漸進式 web 應用（PWA）。其想法是在瀏覽器中使用 服務工作者（service worker） 來快取網站的靜態部分。因此，這些部分對於重複檢視會立即載入，並可離線使用。動態部分仍從伺服器端載入。

app shell（單頁應用程式邏輯）可以在後臺重新驗證。如果標識了對應用 shell 的更新，則會提示使用者，要求他更新頁面。例如，Gmail 收件箱 就實現了這個。

但是，寫出快取靜態資源並進行重新驗證的服務工作者（service worker）程式碼，對於每個網站來說，都需要付出相當大的努力。此外，只有 Chrome 和 Firefox 充分地支援了服務工作者（service worker）。

快取動態內容

所有快取方法遇到的問題是它們不能處理動態內容。這只是由於 HTTP 快取的工作機制導致的。有兩種型別的快取：基於失效的快取（如轉發代理快取和 CDN）和基於到期的快取（如 ISP 快取、機構代理和瀏覽器快取）。基於失效的快取可以從伺服器端主動失效，基於到期的快取記憶體只能從客戶端重新驗證。

使用基於到期的快取時，棘手的事情是，你必須在首次從伺服器拿到資料時指定快取生命週期（TTL）。之後，你沒有任何機會將快取資料刪除。它將由瀏覽器快取提供到 TTL 到期的時刻。對於靜態資源，這不是一件複雜的事情，因為它們通常只會在你部署 web 應用程式的新版本時發生變化。因此，你可以使用 gulp-rev-all 和 grunt-filerev 等很酷的工具）對 assets 進行雜湊。

但是，但是你該如何處理執行時的應用資料載入和修改呢？更改使用者個人資料、更新帖子或新增新評論似乎不可能與瀏覽器快取結合使用，因為你無法預估此類更新將來何時會發生。因此，快取只能被禁用或使用非常小的 TTL。

由另一個客戶端更新時，快取動態資料如何過時的示例

Baqend 的 Cache-Sketch 方法

在 Baqend，我們已經研究並開發了一種方法，在實際獲取之前，檢查客戶端中 URL 的陳舊度。在每個使用者會話開始時，我們獲取一個非常小的資料結構，稱為布隆過濾器（Bloom Filter），它是所有過時資源集合的高度壓縮表示。通過檢視布隆過濾器，客戶端可以檢查資源是否過時（包含在布隆過濾器中）或者是否是全新的。對於潛在的過時資源，我們繞過瀏覽器快取並從 CDN 獲取內容。在其他的所有情況下，我們直接用瀏覽器快取提供內容。使用瀏覽器快取可以節省網路流量和頻寬，並且是很快的。

此外，我們確保 CDN（以及其它基於失效的快取，如 Varnish）始終包含最新的資料，只要它們過時就立即清除資源。

Baqend 如何確保快取動態資料的新鮮度示例

布隆過濾器（Bloom filter） 是具有可調誤報率的概率資料結構，這意味著集合可以用來表示對從未新增的物件的遏制，但永遠不會刪除實際條目。換句話說，我們可能偶爾會重新驗證新資源，但是我們永遠不會提供過期資料。注意，誤報率非常低，這使得我們能夠讓集合非常小。例如，我們只需要 11 Kbyte 來儲存 20,000 個不同的更新。

Baqend 在伺服器端有很多流處理（查詢匹配檢測）、機器學習（最佳 TTL 估計）和分散式協調（可擴充套件的布隆過濾器維護）的工作。如果你對這些細節感興趣，看看這篇 文章 或 這些幻燈片 來深入研究。

效能收益

這一切都歸結為這一點。

使用 Baqend 的快取基礎設施可以使哪種頁面速度得到提高？

為了展示使用 Baqend 的好處，我們在後端即服務（BaaS）領域中的每個領先競爭對手上構建了一個非常簡單的新聞應用，並觀測了來自世界各地不同位置的頁面載入時間。如下所示，Baqend 持續載入低於 1 秒，比平均速度快 6.8 倍。即使當所有客戶端來自伺服器所在的同一位置時，由於有瀏覽器快取，Baqend 也是 150％ 倍速度。

簡單新聞應用的平均載入時間比較

我們將此比較作為一個 動手的 web 應用 來比較 BaaS 競爭。

動手比較 的截圖

但這當然是一個測試場景，而不是一個具有真正使用者的 web 應用。 所以讓我們回到 Thinks 網上商城來看一個真實世界的例子。

Thinks 網上商城——所有的事實

當 DHDL（"Shark Tank"的德國版）在 9 月 6 日播出時，有 270 萬觀眾，我們坐在電視和我們的 Google 分析螢幕前，為 Thinks 創始人提出他們的產品而激動。

從他們開始演示起，網上商的併發使用者數量迅速增加到大約 10,000，但真正的巔峰發生在廣告休息時，當時突然有超過45,000 的併發使用者來參觀該店購買 Towell+：

Google 分析觀測在商業廣告時間之前開始。

Thinks 在電視播放的 30 分鐘裡，我們得到了 340 萬的請求，300,000 位遊客，高達 50,000 位的併發訪問遊客和高達每秒 20,000 個請求，所有這一切實現了在 CDN 級別的 98.5％ 的快取命中率，和平均為 3％ 的伺服器 CPU 負載

因此，頁面載入時間為低於 1 秒，整個時間實現了 7.8％ 的極大的轉化率。

如果我們看看在同一集 DHDL 中展示的其他商城，我們會看到其中四個 完全崩潰了，剩下的商城只利用了極少的效能優化。

可用性概述和商城的 Google 頁面速度得分，在 DHDL 上，於 9 月 6 日展示。

總結

我們已經看到了在設計快速和可擴充套件的網站時需要克服的瓶頸：我們必須掌握關鍵呈現路徑，理解網路限制、快取的重要性和具有水平可擴充套件性的後端設計。

我們已經看到了很多用來解決單個問題的工具，以及移動加速頁面（AMP）和漸進式 web 應用（PWA），這些採取了更全面的做法。但是，快取動態資料的問題仍然存在。

Baqend 的做法是減少 web 開發，將構建主要放在前端，通過 JS SDK 使用 Baqend 完全託管的雲服務上的後端功能，包括資料和檔案儲存、（實時）查詢、推送通知、使用者管理和 OAuth 以及訪問控制。該平臺通過使用完整的 HTTP 快取層次結構自動加速所有請求，並確保可用性和可擴充套件性。

我們對於 Baqend 的願景是一個不需要載入時間的網站，並且我們想要給你到達這個目標的工具。

不想錯過我們關於網路效能的下一篇文章？通過加入我們的 newsletter 方便地將其傳送到你的收件箱。