原文地址：Building a Shop with Sub-Second Page Loads: Lessons Learned
原文作者：Erik Witt
譯文出自：掘金翻譯計劃
譯者：luoyaqifei
校對者：Romeo0906，L9m

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

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

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

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

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

Source

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

怎樣讓網站加速

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

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

后端處理：web 服務器需要時間從數據庫加載數據和整合網站。
網絡延遲：每個請求需要時間從客戶端傳輸到服務器，并返回（請求延遲）。當考慮到平均每個網站需要發出超過?100 個請求?才能完全加載時，這變得更加重要。
前端處理：前端設備需要時間來渲染頁面。

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

前端性能

影響前端性能最重要的因素是關鍵呈現路徑（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 的?基本概念：

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

此外，瀏覽器緩存?是非常有效的，應該在所有的項目中加以使用。它對于這三個優化項都很合適，因為緩存的資源不必先從服務器加載。

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

分析：?GTmetrix?用來衡量網頁速度，webpagetest?用來分析你的資源，以及 Google 的PageSpeed Insights，為你的網站生成有關如何優化 CRP 的提示。
內聯和優化：[Critical]（(https://github.com/addyosmani/critical) 非常適合自動將你的明顯位置的 CSS 內聯并且異步加載其余 CSS，processhtml?連接你的資源和?PostCSS?進一步優化 CSS。
最小化和壓縮：?我們使用?tiny png?來進行圖像壓縮，UglifyJs?和?cssmin?來進行最小化，Google Closure?來進行 JS 優化。

有了這些工具只需很小的工作量，你就可以打造一個前端性能極好的網站。這里是?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的數據。

來源

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

來自?High Performance Browser Networking，作者為 Ilya?Grigorik

事實證明，將帶寬增加到 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）?來使得緩存數據保持一致。

www.thinks.com?重復加載，來顯示瀏覽器緩存覆蓋率

對于重復網頁加載的請求，瀏覽器緩存沒有提供的內容（參見上圖）包括：對 Google 分析的 API 的兩個異步調用，以及從 CDN 處獲取的初始 HTML 請求。因此，對于重復的網頁加載，頁面能夠做到立即加載。

后端性能

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

可擴展的后端技術棧組件：負載均衡器，無狀態應用服務器，分布式數據庫

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

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

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

NoSQL 數據庫：一份調查和決策指南
與我們在漢堡大學的同事一起，我們是：Felix Gessert, Wolfram Wingerath, Steffen…medium.baqend.com

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 寫成，圍繞著構建快速的、具有良好的用戶體驗的網站，涵蓋了很多最佳實踐。

還有一些很棒的在線指南、教程和工具可以考慮：從初學者友好的 Udacity 課程?網站性能優化、Google 的?開發者性能指南?到類似于?Google PageSpeed Insights、GTmetrix?和?WebPageTest?這樣的優化工具。

緩存動態內容

所有緩存方法遇到的問題是它們不能處理動態內容。這只是由于 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 緩存層次結構自動加速所有請求，并確保可用性和可擴展性。