[轉載] 全方位提高網站打開速度：前端、後端、新的技術

時間 2019-11-17

原文原文鏈接

原文地址：Building a Shop with Sub-Second Page Loads: Lessons Learned

原文做者：Erik Witt

譯文出自：掘金翻譯計劃

譯者：luoyaqifei

校對者：Romeo0906，L9m

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

這裏是咱們充分利用對於網絡緩存和 NoSQL 系統的研究，作出一個能夠容納幾十萬經過電視宣傳慕名而來的訪問者的網上商城的故事，以及咱們從中學到的一切。php

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

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

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

Source前端

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

怎樣讓網站加速

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

在現有的 web 應用技術中有三個影響頁面加載時間的主要緣由，展現以下：github

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

爲了讓咱們的網店加速，讓咱們一一解決這三個瓶頸。web

前端性能

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

關鍵呈現路徑的步驟：sql

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 緩存層次結構自動加速全部請求，並確保可用性和可擴展性。