打造亞秒級頁面加載速度網店實踐經驗

美國的創智贏家（Shark Tank），英國的龍穴之創業投資（Dragons’ Den），以及德國的“Die H?hle der L?wen (DHDL)”等電視節目為年輕的初創公司提供了一個在海量觀眾面前向商業巨頭展現自己產品的機會。然而這些初創公司的主要收益通常并不在于評委提供的戰略性投資?，? 畢竟只有很少數交易最終能夠完成 ，而在于通過電視節目獲得的關注：電視上出現幾分鐘的畫面通常就可以為網站吸引成百上千的新訪客，借此可以有效提升每周、每月，甚至更長時間內的網站流量。然而前提是，網站必須要能承受一開始的負載尖峰不能掉鏈子……

1，僅可用性還不夠—延遲更關鍵！

網店們通常會發現自己處于一種非常尷尬的境地，因為他們不僅僅是一些消遣性的項目（例如博客），而是通常需要由創始人背負大量投資，并且必須想方設法盈利。對企業來說，最糟糕的情況莫過于服務器超載導致無法處理用戶請求，甚至整個網站徹底崩潰。這種情況其實比你想象得更常見：當季DHDL節目中露臉的所有網店中，約有半數因為上電視后不堪重負而崩潰。而能繼續保持在線也只是走完了萬里長征一半的路程，因為 用戶滿意度直接決定了轉化率 ，也就是說，用戶滿意度直接決定了最終能獲得的銷售額。

針對網頁加載時間對客戶滿意度和轉化率的影響已經有太多 研究 ，這足以證明這些因素的重要性。例如Aberdeen Group發現延遲每增加1秒會導致頁面訪問量減少11%，轉化率降低7%。就算你去問 谷歌 或者 亞馬遜 ，他們的結論也是相同的。

2，如何給網站提速

在給初創公司 Thinks 開發網店（該公司參加了9月6日的DHDL節目）的過程中，我們遇到了一個挑戰：要求所開發的網站能在順利迎接成千上萬訪客的同時實現不超過1秒的加載速度，這對我們而言是一個巨大的挑戰。從這個項目的實施，以及在數據庫和Web性能領域多年的研究成果中，我們獲得了很多寶貴的經驗。

影響Web應用程序頁面加載速度最主要的因素有三個，如下圖所示。

1. 后端處理（Backend） ：網站服務器需要花時間從數據庫載入數據并生成網頁。
2. 網絡延遲（Network latency） ：每個請求需要花時間從客戶端抵達服務器并再次返回客戶端（請求延遲）。考慮到完整加載一個網站平均需要發出超過 100個請求 ，延遲問題變得更嚴峻了。
3. 前端處理（Frontend） ：前端設備渲染網頁也需要時間。

為了給網店提速，需要逐個消除這些性能瓶頸。

3，前端性能

影響前端性能最重要的因素在于關鍵呈現路徑。這個概念描述了瀏覽器將網頁呈現給用戶的5個必要步驟，如下圖所示。

關鍵呈現路徑所涉及的步驟

• DOM ：瀏覽器在解析HTML時，會以遞增的方式為HTML標記生成一種名為文檔對象模型（DOM）的樹狀模型，該模型描述了網頁中包含的內容。
• CSSOM ：瀏覽器收到所有CSS后，會對其中包含的標記和和類生成一種名為CSS對象模型的樹狀模型，并將樣式信息附加在樹的節點上。這個樹描述了網頁中所包含內容需要應用的樣式。
• 呈現樹（Render Tree） ：通過將DOM與CSSOM結合在一起，瀏覽器可以構造出呈現樹，其中包含了頁面內容以及所要應用的樣式信息。
• 布局（Layout） ：布局這一步中需要計算網頁內容在屏幕上的實際位置和大小。
• 繪制（Paint） ：最后一步將使用布局信息在屏幕上繪制像素。

上述每個步驟單獨看都相當簡單，但是不同步驟之間的依賴性使得事情變得復雜，并會對性能產生影響。DOM和CSSOM的構造通常會對性能產生最大影響。

下圖展示了一個關鍵呈現路徑，箭頭所指內容為需要花時間等待的依賴項。

關鍵呈現路徑中重要的依賴項

在加載CSS并構造完整CSSOM之前，客戶端上什么都不會顯示。因此CSS也被稱之為 “呈現”的攔路虎 。

JavaScript（JS）的情況更糟，因為無論DOM或CSSOM都可被JavaScript所訪問并更改。這意味著一旦在HTML中發現Script標記，DOM的構造過程將暫停，等待從服務器請求腳本。在腳本加載完之后，還需要等待取回所有CSS并完成CSSOM的構造，隨后才能繼續執行。例如在下面的例子中，當CSSOM構造完成并且JS執行完畢后，終于可以訪問并修改DOM和CSSOM了。DOM的構造過程直到此時才能繼續處理，并將網頁顯示在客戶端上。因此JavaScript也被叫做“解析”的攔路虎。

Example of JavaScript accessing CSSOM and changing 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文件）。通過對渲染無需滾動情況下網頁上所呈現內容（也叫做 首屏（Above the fold） ）需要的CSS和JS進行 內聯引用（Inlining） ，可大幅減少此類資源的數量。其余JS和CSS可異步加載。無法異步加載的文件可以 合并（Concatenated） 為一個文件。
2. 字節數最小化 ：通過對CSS、JS以及圖片進行 Minifying（縮減） 和 Compressing（壓縮） ，可大幅縮減首屏內容所需加載的字節數。
3. 縮短CRP長度 ：CRP長度是指為了獲取所有關鍵資源，需要與服務器進行連續不斷 往返（Roundtrip） 的次數最大值。為了縮短該長度，可減少關鍵資源的數量，并將其大小減至最低（大文件的獲取需要多次往返）。為了進一步縮短，還可在HTML中 將CSS“置頂” ，并將 JS“置底” ，因為JS的執行會阻止CSS的獲取，并影響到CSSOM和DOM的構建。

此外 瀏覽器緩存 是一種始終值得考慮使用的非常有效的做法。這種方法適合用于上述三種類型內容的優化，因為在將資源緩存后，就無需像第一次訪問那樣從服務器加載。

CRP優化是一個非常復雜的話題，尤其是內聯、合并，以及異步加載等措施會徹底毀掉代碼的可讀性。好在目前有很多實用的工具可以幫助我們進行優化，可以考慮將其集成到自己的構建和部署流程中。下面這幾個工具絕對值得一試…

• 剖析 ： GTmetrix 可衡量網頁加載速度， Webpagetest 可對資源進行剖析，谷歌的 PageSpeed Insights 可提供建議告訴你如何針對自己的網站優化CRP。
• 內聯和優化 ： Critical 可自動對首屏CSS進行內聯，并讓其余內容實現異步加載， processhtml 可對資源進行合并， PostCSS 可對CSS進一步優化。
• 縮減和壓縮 ：我們可以使用 tiny png 進行圖像壓縮，使用 UglifyJs 和 cssmin 進行縮減，并使用 Google Closure 進行JS優化。

在這些工具的幫助下，只須少量工作即可打造出前端性能更出色的網站。訪客首次訪問Thinks網店的頁面加載速度測試結果如下：

Google PageSpeed對thinks.com網站的評測結果

有趣的是，PageSpeed Insights中檢測到唯一存在問題的地方竟在于Google Analytics腳本的緩存壽命過短。所以谷歌基本上就是在抱怨自家的問題咯。

從加拿大（GTmetrix）訪問位于法蘭克福的服務器時的首次頁面加載速度

4，網絡性能

網絡延遲是網頁加載速度最大的影響因素，同時也是最難優化的。但在實際進行優化前先來看看瀏覽器首次請求分解后的步驟：

在瀏覽器中輸入 https://www.thinks.com/ 并按下回車后，瀏覽器首先通過 DNS查詢 解析該域名對應的IP地址。訪問每個域名都需要進行這樣的查詢。

在獲得IP地址后，瀏覽器發起一個到服務器的 TCP連接 。TCP握手需要2次往返（1次可使用 TCP Fast Open ）。對于安全的 SSL連接 ，TLS握手需要額外的2次往返（1次可使用 TLS False Start 或 Session Resumption ）。

初始連接完成后，瀏覽器發出實際請求并等待返回的數據。 獲得首個字節所需的時間 主要取決于客戶端和服務器之間的距離，其中還包含服務器呈現網頁（包括會話查詢、數據庫查詢、模板呈現等環節）所需的時間。

最后一步需要 下載資源 （本例中為HTML）這一過程需要多次往返。尤其是新連接通常需要更多往返，因為初始擁塞窗口通常很小。這意味著TCP并不能在一開始就全面使用所有可用帶寬，而是會隨著時間流逝逐漸增加帶寬用量。具體速度受制于啟動速度緩慢的算法，這種情況下會讓每個往返的擁塞窗口內片段數量翻倍，直到數據包真正開始丟失。在移動和Wifi網絡中，因為這種情況導致的數據包丟失會對性能產生極大影響。

另外還要注意：在使用HTTP/1.1的情況下，最多只能創建 6個并發連接 （如果瀏覽器依然沿襲了最初的標準，則最多只能創建2個連接）。因此最多只能并行請求6個資源。

為了更直觀地了解網絡性能會對頁面加載速度產生多大影響， httparchive 提供了大量統計數據。例如平均來說，每個網站需要用超過100個請求才能加載大約2.5MB的數據。

也就是說，網站需要用大量小請求加載數量眾多的資源，但網絡帶寬不是總在增加嗎？最終可以通過寬帶提速等措施解決這一問題對吧？未必…

實際上 帶寬 超過5Mbps后將無法繼續對網頁加載速度產生任何改善。但是降低每個請求的 延遲 可以大幅加快網頁加載速度。這意味著帶寬翻倍后加載時間依然不會有變化，但延遲減半可以讓網頁加載速度提高一倍。

既然延遲是網絡性能的決定性因素，我們能做些什么？

• 持久連接 是必須的。如果服務器每次完成一個請求之后就關閉連接，瀏覽器必須周而復始地重新握手并再次建立TCP連接，沒什么比這更糟糕的了。
• 盡可能 避免重定向 ，重定向會大幅降低頁面初始加載速度。例如請盡量鏈接至完成URL（例如鏈接至www.thinks.com而非thinks.com）。
• 可行的情況下使用 HTTP/2 。該標準可通過 服務器推送 通過一個請求傳輸多個資源，并可通過 頁頭壓縮 降低請求和回應的數據大小，同時可通過 管道化（Pipelining） 和 多路復用（Multiplexing） 借助一個連接發送任意數量的并行請求。例如在使用服務器推送的情況下，服務器可以在發送HTML的同時，無需等待實際發出請求，直接將網頁所需的CSS和JS發送給客戶端。
• 為靜態資源（CSS、JS、徽標等圖片）設置明確的 緩存標頭 。借此可以告訴瀏覽器將這些資源緩存多久，何時重新驗證。緩存機制可大幅減少往返次數以及需要下載的字節數。如果未設置明確的標頭，瀏覽器將會進行 啟發式（Heuristic）緩存 ，雖然算是權宜之計，但這總歸并非最優化的做法。
• 使用 內容交付網絡 （CDN）緩存圖片、CSS、JS和HTML。這種分布式緩存網絡可以大幅拉近用戶與資源之間的距離，實現更快速的資源交付。同時這種技術也可以加快初始連接速度，因為此時將會與距離最近的CDN節點進行TCP和TLS握手，同時這些節點會與網站后端建立快速持久的連接。
• 考慮構建 單頁應用 ，其中只包含小體積的初始頁面，并通過異步方式加載其余內容。為此可以使用可緩存的HTML模板，通過小請求加載動態數據，并只在導航過程中對頁面中的部分區域進行更新。

簡而言之，網絡延遲方面有一些必做，以及絕對不能做的事，但總的來說，主要局限因素依然在于往返的次數以及物理網絡的延遲。破解這一局限唯一有效的方式是拉近數據和客戶的距離。先進的Web緩存技術就是用來做這種事的，但這種技術只能用于靜態資源。

對于Thinks，我們完全遵照上述原則使用了 Fastly CDN以及更激進的瀏覽器緩存機制，甚至動態數據也使用了一種新穎的 Bloom Filter算法 確保緩存數據的一致性。

重復對www.thinks.com進行加載測試可了解瀏覽器緩存的覆蓋率

反復進行頁面加載測試的過程中，唯一未能從瀏覽器緩存完成的請求（見上圖）是兩個對谷歌分析API進行的異步調用，初始HTML的請求則是從CDN獲取的。因此在反復進行的測試中，頁面加載速度有了顯著提高。

5，后端性能

在后端性能方面，我們需要同時考慮延遲和吞吐率。為了實現低延遲，我們需要將服務器的處理工作所需時間降至最低。為了實現更高吞吐率并應對負載尖峰，我們需要采取一種可以 橫向縮放 的架構。雖然不準備深入介紹太多細節，但設計方面對性能產生的影響是極為巨大的，需要重點關注的組件和屬性包括：

可縮放后端棧包含的組件：負載均衡器、無狀態應用程序服務器、分布式數據庫

首先需要 負載均衡 （例如Amazon ELB或DNS負載均衡），借此將傳入的請求分配至多臺應用程序服務器中的一臺。此外還可以實施 自動縮放 以便在需要時添加額外的應用程序服務器，并通過 故障轉移 機制替換故障服務器，將請求重新路由至正常運轉的服務器。

為將協調的次數降至最低， 應用程序服務器 應當維持 最小化的共享狀態 ，并可使用 無狀態會話處理 機制實現更自由的負載均衡。此外服務器的代碼和IO應盡可能 高效 ，借此即可將服務器處理時間降至最低。

數據庫也需要能應對尖峰期的負載，并盡量將處理工作所需的時間降至最低。與此同時，數據庫需要具備建模和數據查詢需求所需的能力。市面上有大量可縮放的數據庫（尤其是NoSQL數據庫），每種產品都各有利弊。

Thinks的網店基于 Baqend 構建，使用了下列后端棧：

Baqend的后端棧：MongoDB充當的主數據庫、無狀態應用程序服務器、HTTP緩存體系，以及適用于Web前端的REST和JS SDK

Thinks使用 MongoDB 作為主數據庫。為了實現會在短時間內過期的Bloom篩選器（用于瀏覽器緩存），我們出于更高寫入吞吐率的考慮使用了 Redis 。無狀態應用程序服務器（ Orestes Servers ）提供了用于訪問后端功能（文件托管、數據存儲、實時查詢、推送通知、訪問控制等）的接口，并由該服務器負責處理動態數據的緩存連貫性。這些服務器可通過充當負載均衡器的 CDN 發起請求。網站前端使用了一種基于 REST API 的 JS SDK 訪問后端，后端可自動利用完整的 HTTP緩存體系 對請求進行加速，并確保緩存數據處于最新狀態。

6，負載測試

為了對Thinks網店面對高負載情況的表現進行測試，我們使用位于法蘭克福的兩個t2.medium AWS實例作為應用程序服務器進行了負載測試。MongoDB運行在兩個t2.large實例上。我們的負載測試使用20臺 IBM SoftLayer 計算機運行 JMeter ，借此模擬 200000用戶 在 15分鐘 內訪問該網站的負載。其中20%的用戶（40000個）被配置為額外執行支付操作。

該網店的負載測試環境

測試發現支付系統方面存在幾個瓶頸，例如我們必須從原本對庫存進行樂觀更新（通過 findAndModify 實現）的做法改為使用MongoDB的部分更新操作（ inc ）。但在這之后服務器面對負載表現非常出色，實現了平均5ms的請求延遲。

JMeter負載測試結果：12分鐘內680萬個請求，平均延遲5ms

所有負載測試總共生成了大約 1千萬個請求 并傳輸了 460GB數據 ，CDN的 緩存命中率高達99.8% 。

負載測試之后的儀表盤概述信息

7，總結

簡而言之，良好的用戶體驗需要從三方面來實現：前端、網絡，以及后端性能。

前端性能在我們看來是最容易實現的，因為市面上已經有很多現成的工具以及各種最佳實踐，照做很容易就能搞定。但依然有很多網站沒有參照這些最佳實踐，甚至完全沒有對前端進行任何優化。

網絡性能是頁面加載速度的最大影響因素，同時也是最難優化的。緩存和CDN是最有效的優化方法，但需要注意到，這些機制只能對靜態內容進行優化。

后端性能主要取決于單臺服務器的性能以及分布式環境的規模。橫向擴展非常難以實現，因此從一開始就要妥善考慮。很多項目將縮放能力和性能放在最后考慮，隨著業務的增長最終將遇到非常棘手的問題。

8，推薦的資料和工具

圍繞Web性能和可縮放系統的設計，目前有很多不錯的圖書。Ilya Grigorik撰寫的《 High Performance Browser Networking 》一書幾乎涉及了有關網絡和瀏覽器性能的方方面面，此外本書還提供了一個持續更新，可免費在線閱讀的版本！Martin Kleppmann撰寫的《 Designing Data-Intensive Applications 》雖然目前尚處于早期發布階段，但已經成為該領域最棒的圖書。其中談及了大量可縮放后端系統內部的技術基本知識，并包含很多細節介紹。Lara Callender Hogan撰寫的《 Designing for Performance 》談到了如何構建速度快，可提供出色用戶體驗的網站，并提供了大量最佳實踐。

此外還有大量在線指南、教程和工具可供借鑒。從面向新手的Udacity課程 網站性能優化 到谷歌的 開發者性能指南 ，再到諸如 Google PageSpeed Insights 、 GTmetrix 以及 WebPageTest 等分析工具，都能為我們提供巨大的幫助。

9，Web性能領域的最新進展

9.1，移動頁面加速

谷歌正在通過 PageSpeed Insights 、 開發者指南 等有關Web性能的項目幫助大家提高對Web性能的重視，甚至將網頁加載速度作為該公司 頁面排名 的一個重要依據。

谷歌搜索在改善頁面加載速度和用戶體驗方面的最新項目名為 移動頁面加速（ AMP ） 。該項目意在讓新聞文章、產品頁面，以及其他搜索內容能通過谷歌搜索結果立刻呈現。為此必須以AMP的方式構建這些頁面。

AMP頁面范例

AMP主要做了兩件事：

1. 使用AMP方式構建的網站使用了一種精簡（Stripped-down）版本的HTML，并使用JS loader實現快速呈現，盡可能以異步方式加載更多的資源。
2. 谷歌會將這些網站緩存在Google CDN中，并通過HTTP/2交付。

第一件事最為關鍵，AMP會通過某種方式對HTML、JS和CSS內容進行限制，使得通過這種方式構建的頁面可以獲得最優化的關鍵呈現路徑，并能被谷歌爬蟲更輕松地爬網檢索。AMP會強制實施 多種限制 ，例如所有CSS必須是內聯的，所有JS必須是異步的，頁面上包含的一切內容必須為固定大小（這是為了避免“重繪”）。雖然就算無需這些限制，按照上文提到的Web性能最佳實踐也可以實現相同結果，但AMP也許是一種更好的做法，就算一些很簡單的網站也可以使用。

第二件事意味著谷歌會在對你的網站進行爬網檢索的同時將內容緩存在Google CDN中，借此實現更快速的交付。當爬網程序再次索引你的網站時，緩存的網站內容會被更新。該CDN還會遵守服務器設置的靜態TTL，但與此同時至少會進行 微緩存（Micro-caching） ：認為資源在至少一分鐘之內是新鮮的，并在收到用戶請求后在后臺對資源進行更新。這樣的做法使得AMP最適合網站以靜態內容為主的用例，例如以人工方式進行內容編輯的新聞網站或其他用于出版發布用途的網站。

9.2，Progressive Web Apps

另一種方法（同樣由谷歌提出）是 Progressive Web Apps （ PWA ）。該方式意在瀏覽器中使用 服務工作進程（Service worker） 對網站中的靜態部分創建緩存。通過這種方式，重新查看網頁時就可以立即加載緩存的內容，并可脫機使用。但網站上的動態內容依然需要從服務器加載。

應用外殼（App shell）（單頁應用程序的邏輯）可在后臺重新驗證。如果發現應用外殼有更新，會通過一則消息要求用戶更新頁面。例如 Gmail的Inbox 就是這樣做的。

然而服務工作進程的代碼會對每個網站的靜態資源進行緩存并進行重新驗證，這會產生不小的開銷。此外目前僅Chrome和Firefox對服務工作進程提供了完善的支持。

9.3，動態內容的緩存

所有緩存方法都會遇到一個問題：無法處理動態內容。這主要是由于HTTP緩存的工作原理導致的。緩存主要有兩種類型： 基于失效（Invalidation-based） 的緩存（例如轉發代理緩存和CDN），以及 基于過期（Expiration-based） 的緩存（例如ISP緩存、企業代理以及 瀏覽器緩存 ）。基于失效的緩存可由服務器主動指定為失效，基于過期的緩存只能由客戶端進行重新驗證。

在使用基于失效的緩存時，最棘手的問題在于，首次將數據從服務器交付給客戶端時，必須指定緩存的壽命（TTL）。隨后對于已經緩存的數據就完全喪失了控制能力。在TTL過期前，瀏覽器將始終是用當時緩存的內容。對于靜態內容來說，這個問題并不是很麻煩，因為通常這類內容只在部署新版本Web應用程序之后才會有改動。因此可以使用諸如 gulp-rev-all 和 grunt-filerev 等實用工具對這些資產創建哈希。

但對于會在應用程序運行過程中加載和改動的各類數據又該怎么辦？更改用戶資料，更新已發布的內容，或發布新的評論，這些操作涉及的內容似乎無法與瀏覽器緩存很好地結合在一起，因為我們無法預計此類更新會發生在未來的什么時候。此時只能禁用緩存，或使用非常短的TTL。

被其他客戶端更新后，緩存的動態數據變為陳舊狀態的范例

9.4，Baqend的緩存描述（Cache-Sketch）法

Baqend 研究并開發了一種在客戶端實際獲取之前檢查URL陳舊度的方法。在啟動每個用戶會話后，我們首先會獲取一個非常小的數據結構，該結構名為Bloom篩選器，是一種高度壓縮的內容，其中描述了所有陳舊的資源。通過查詢Bloom篩選器，客戶端可以知道每個資源是否陳舊（包含在Bloom篩選器中）或確定其為新鮮狀態。對于有可能陳舊的資源，我們會繞過瀏覽器緩存從CDN獲取相應的內容。在其他任何情況下，我們會直接通過瀏覽器緩存提供內容。使用瀏覽器緩存可以減少網絡通信并節約帶寬，同時速度相當快。

此外通過在資源變得陳舊后立刻進行清理，確保了CDN（以及其他基于失效的緩存，例如Varnish）始終包含最新數據。

Baqend保障被緩存動態數據新鮮度的范例

Bloom篩選器 是一種基于概率的數據結構，并使用了可調整的假陽性率（False positive rate），這意味著該數據集可能會對從未加入過的對象進行限制，但絕對不會漏掉任何一個需要限制的對象。換句話說，我們可能偶爾會對新鮮資源進行重新驗證，但 絕對不會交付陳舊的數據 。另外值得注意的是，假陽性率非常低，借此才可以讓整個數據集的規模盡可能小。例如我們只需要11K字節的數據集就可以存儲20000個不同的更新。

服務器端會進行大量流處理（查詢匹配檢測）、機器學習（優化TTL的估算），以及分布式協調（可縮放Bloom篩選器的維護）。

9.5，性能收益

諸多努力就是為了改善性能。

Baqend的緩存基礎架構可以通過哪些方面改善網頁加載速度？

為了展示Baqend技術對性能的改進，我們通過后端即服務（BaaS）領域每個主要競爭對手的平臺構建了一個非常簡單的新聞應用程序，并測試了從全球不同位置加載頁面所需的時間。如下圖所示，Baqend技術的頁面加載速度始終不超過1秒，平均來說是競爭對手速度的6.8倍。就算所有客戶端均與服務器位于同一個位置，由于瀏覽器緩存技術的使用，Baqend的速度也快了150%。

通過一個簡單的新聞應用程序對平均加載時間進行的比較

為了對BaaS競爭對手的服務進行比較，我們還構建了一個 可供大家實際操作進行比較的Web應用 。

實際操作比較 結果的屏幕截圖

當然，這只是一個測試場景，并非有真實用戶的Web應用程序。我們重新回到Thinks網店這個例子，看看真實環境中的表現到底如何吧。

9.6，Thinks網店?—實際表現

當DHDL（德國版的“創智贏家”電視節目）在9月6日首播并吸引了270萬觀眾時，我們正坐在電視機前密切關注著Google Analytics的統計信息，同時還在為Thinks創始人所介紹的產品而感到激動。

從他們介紹自家產品開始，網店的并發用戶數在短時間內增加了大約10000人，但真正的尖峰發生在節目插播廣告的時候，突然之間超過45000個并發用戶涌入網店打算購買Towell+：

從插播廣告前一刻開始的Google Analytics統計結果

在Thinks上電視的30分鐘內，我們收到了 340萬 請求， 300000 個訪客，高達 50000 個并發訪客，以及每秒最高20000個請求?—?所有這一切都在CDN層面實現了 98.5%的緩存命中率 以及平均 3%的服務器CPU負載 。

總的來說，全時段內 低于1秒 的 頁面加載時間 最終產生了 高達7.%的轉化率 ，這個結果讓人很滿意。

如果再看看同一期DHDL節目中介紹的其他商家，我們會發現其中有四家 徹底宕機 ，其余幾個商家僅使用了微不足道的性能優化技術。

9月6日播出的DHDL節目中推薦的商家的整體可用性和谷歌頁面加載速度評分

10，總結

在設計快速可縮放網站過程中，我們解決了很多性能瓶頸：我們全面掌握了 關鍵呈現路徑 ，充分理解了網絡方面的限制和 緩存 的重要性，并設計出一套可 橫向縮放 的后端系統。

我們發現有很多實用工具很適合用來解決某些具體的問題，此外還可以通過移動頁面加速（ AMP ）和Progressive Web Apps（ PWA ）實現更全面的優化。但 動態數據的緩存 這個問題依然存在。

Baqend采取的方法是盡量減少前端Web開發的工作量，通過JS SDK從全面托管的Baqend云服務獲得所需后端功能，包括數據和文件的存儲、（實時）查詢、推送通知、用戶管理、OAuth，以及訪問控制。通過使用完整的HTTP緩存體系，該平臺可以自動加速所有請求，同時可用性與可縮放性也更有保障。

 

 

來自：http://www.infoq.com/cn/articles/practice-of-create-a-sub-page-loading-speed-shop