當前位置：首頁 > 前端技术 > HTML >内容正文

HTML

[转载] 全方位提升网站打开速度：前端、后端、新的技术

發(fā)布時間：2023/12/18 HTML 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 [转载] 全方位提升网站打开速度：前端、后端、新的技术小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

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

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

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

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

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

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

Source

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

怎樣讓網(wǎng)站加速

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

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

后端處理：web 服務器需要時間從數(shù)據(jù)庫加載數(shù)據(jù)和整合網(wǎng)站。

網(wǎng)絡延遲：每個請求需要時間從客戶端傳輸?shù)椒掌?#xff0c;并返回（請求延遲）。當考慮到平均每個網(wǎng)站需要發(fā)出超過?100 個請求?才能完全加載時，這變得更加重要。

前端處理：前端設備需要時間來渲染頁面。

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

前端性能

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

關鍵呈現(xiàn)路徑的步驟：

DOM：當瀏覽器解析HTML時，它會增量式地生成一個 HTML 標簽的樹模型，稱為?文檔對象模型（DOM），該模型描述了頁面內(nèi)容。
CSSOM：一旦瀏覽器接收到所有的 CSS，它會生成一個 CSS 中包含的標簽和類的樹模型，稱為?CSS 對象模型，在樹節(jié)點上還附有樣式信息。這棵樹描述了頁面內(nèi)容是如何設置樣式的。
渲染樹：通過組合 DOM 和 CSSOM，瀏覽器構造一個渲染樹，它包含頁面內(nèi)容以及要應用的樣式信息。
布局：布局這一步計算屏幕上頁面內(nèi)容的實際位置和大小。
繪制：最后一步使用布局信息將實際像素繪制到屏幕上。

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

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

關系呈現(xiàn)路徑中重要的依賴

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

JavaScript（JS）更糟糕，因為它可以訪問和更改 DOM 和 CSSOM。這意味著一旦發(fā)現(xiàn) HTML 中的腳本標記，DOM 構造就會被暫停，并從服務器請求腳本。一旦腳本被加載，只有在所有 CSS 被提取和 CSSOM 被構造以后，它才能被執(zhí)行。在 CSSOM 構建之后 JS 被執(zhí)行，在下面的例子中，它可以訪問和改變 DOM 以及 CSSOM。只有這樣之后，DOM的構造才能進行，并且頁面才能顯示給客戶端。因此 JavaScript 被稱為是阻塞解析的。

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

JS 甚至會影響更惡劣。例如?jQuery 插件?訪問計算后的 HTML 元素的布局信息，然后開始一次又一次地改變 CSSOM，直到實現(xiàn)了所需的布局。因此，在用戶將看到白色屏幕以外的任何東西之前，瀏覽器必須一次又一次地重復地執(zhí)行 JS、構造渲染樹和布局。

有三個優(yōu)化 CRP 的?基本概念：

減少關鍵資源：?關鍵資源是頁面最初渲染時所需的資源（HTML，CSS，JS 文件）。通過將渲染不滾動時可見的網(wǎng)站部分（稱為首屏）所需要的 CSS 和 JS?內(nèi)聯(lián)可以大大減少關鍵資源。接下來的 JS 和 CSS 應該被異步加載。無法被異步加載的文件可以拼接到一個文件中。

最小化字節(jié)：?通過最小化和壓縮?CSS，JS 和圖像，可以大大減少 CRP 中加載的字節(jié)數(shù)。

縮短 CRP 長度：?CRP 長度是獲取所有關鍵資源所需的與服務器之間的最大連續(xù)往返數(shù)。它可以通過減少關鍵資源和最小化它們的大小（大文件需要多個往返來獲取）來縮短。將?CSS 放在 HTML 頂部，以及?JS 放在 HTML 底部，可以進一步地縮短它的長度，因為 JS 執(zhí)行總是會阻塞對 CSS 的抓取、對 CSSOM 和 DOM 的構造。

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

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

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

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

thinks.com 的 Google 網(wǎng)頁速度分數(shù)

有趣的是，PageSpeed Insights 內(nèi)部唯一的抱怨是，Google 分析的腳本緩存生命周期太短。所以 Google 基本上在抱怨它自己。

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

網(wǎng)絡性能

網(wǎng)絡延遲是頁面加載時間最重要的因素，它也是最難優(yōu)化的。但在我們進行優(yōu)化之前，讓我們看一下對初始的瀏覽器請求的劃分：

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

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

在初始連接之后，瀏覽器發(fā)送實際請求并等待數(shù)據(jù)進入。第一個字節(jié)到達的時間主要取決于客戶端和服務器之間的距離，包括服務器渲染頁面所需的時間（包括會話查找、數(shù)據(jù)庫查詢和模板渲染等）。

最后一步是在可能的多次往返中下載資源（在這種情況下指的是 HTML ）。新連接尤其通常需要很多往返，因為初始擁塞窗口很小。這意味著 TCP 不是從一開始就使用全帶寬，而是隨著時間的推移而增加帶寬（參見?TCP擁塞控制。下載速度受到慢啟動算法的支配，該算法在每次往返的擁塞窗口中將報文段數(shù)量加倍，直到丟包發(fā)生。在移動網(wǎng)絡和 Wifi 網(wǎng)絡上丟失數(shù)據(jù)包因此具有很大的性能影響。

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

為了對網(wǎng)絡性能對于頁面速度的重要性有一個直觀的認識，你可以查看?httparchive?，上面有很多統(tǒng)計數(shù)據(jù)。例如，網(wǎng)站平均在 100 多個請求中加載大約 2.5 MB的數(shù)據(jù)。

來源

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

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

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

因此，如果延遲是網(wǎng)絡性能的決定因素，我們可以在這上面做些什么呢？

持久連接是必須有的。沒有什么比當你的服務器在每個請求后關閉連接，并且瀏覽器必須一次又一次地執(zhí)行握手操作和 TCP 慢啟動更糟糕的事情了。
盡可能地避免重定向，因為它們會大大減慢你的初始網(wǎng)頁加載速度。永遠鏈接完整的網(wǎng)址（例如使用?www.thinks.com?而不是 thinks.com）。
如果可以的話，請使用?HTTP/2。它附帶服務器推送，能為單個請求傳輸多個資源；頭壓縮來減小請求和響應的大小；并請求流水線和多路復用通過單個連接發(fā)送任意并行請求。使用服務器推送，你的服務器可以發(fā)送你的 html ，緊接著推送網(wǎng)站所需的 CSS 和 JS，而無需等待實際請求。
為你的靜態(tài)資源（CSS，JS，靜態(tài)圖像如 logo）設置顯式的緩存頭。這樣，你可以告訴瀏覽器需要將這些資源緩存多長時間以及何時重新驗證。緩存可以節(jié)省大量的往返和需要下載的字節(jié)。如果沒有設置明確的緩存頭，瀏覽器會做?啟發(fā)式緩存，這比不緩存好，但遠不是最佳。
使用內(nèi)容分發(fā)網(wǎng)絡（CDN）來緩存圖像、CSS、JS 和 HTML。這些分布式緩存網(wǎng)絡可以顯著地減少與用戶的距離，從而更快地提供資源。它們還加速了你的初始連接，因為你與附近的 CDN 節(jié)點進行 TCP 和 TLS 握手，而這些節(jié)點會依次建立熱的和持久的后端連接。
建議你使用一個小的初始頁來創(chuàng)建單頁應用程序，這個初始網(wǎng)頁會異步地加載其它組件。這樣，你可以使用可緩存的 HTML 模板，在小請求中加載動態(tài)數(shù)據(jù)，并在導航（navigation）期間只更新頁面的各個部分。

總而言之，當涉及到網(wǎng)絡性能時，有一些要做的（do）和不要做的（don't），但限制因素總是往返次數(shù)與物理網(wǎng)絡延遲的結合。克服這種限制的唯一有效方法是使數(shù)據(jù)更接近客戶端。最先進的網(wǎng)絡緩存狀態(tài)的確如此，但這僅適用于靜態(tài)資源。

對于?Thinks，我們遵循上述準則，使用?Fastly?CDN 和主動的瀏覽器緩存，甚至對動態(tài)數(shù)據(jù)使用一種新的?布隆過濾器算法（Bloom Filter algorithm）?來使得緩存數(shù)據(jù)保持一致。

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

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

后端性能

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

可擴展的后端技術棧組件：負載均衡器，無狀態(tài)應用服務器，分布式數(shù)據(jù)庫

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

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

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

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

Thinks?網(wǎng)上商城搭建在?Baqend?上，使用了如下的后端技術棧：

Baqend的后端技術棧：MongoDB 作為主數(shù)據(jù)庫，無狀態(tài)應用服務器，HTTP 緩存層次結構，REST 和 web 前端的 JS SDK

用于?Thinks?的主數(shù)據(jù)庫是?MongoDB。為了維護我們將要到期的布隆過濾器（用于瀏覽器緩存），我們使用?Redis?，因為它的高寫入吞吐量。無狀態(tài)應用程服務器（Orestes Servers）為后端功能提供接口（文件托管，數(shù)據(jù)存儲，實時查詢，推送通知，訪問控制等），并處理動態(tài)數(shù)據(jù)的緩存一致性。它們從?CDN?拿到請求，CDN 也充當負載均衡器。網(wǎng)站前端使用基于?REST API?的?JS SDK?來訪問后端，后端自動利用完整的?HTTP 緩存層次結構來讓請求加速并保持緩存數(shù)據(jù)時刻最新。

負載測試

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

網(wǎng)上商城的負載測試設置

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

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

所有的負載測試組合生成了大約?1000 萬個請求，傳輸了?460 GB的數(shù)據(jù)，伴隨著?99.8％?的 CDN?緩存命中率。

負載測試后的儀表板概述

總結

總之，良好的用戶體驗取決于三個支柱：前端，網(wǎng)絡和后端的性能。

前端性能是我們認為最容易實現(xiàn)的，因為已經(jīng)有很多工具和一些容易遵循的最佳實踐。但仍然有很多網(wǎng)站不遵循這些最佳實踐，完全沒有優(yōu)化過它們的前端。

網(wǎng)絡性能對于頁面加載時間來說，是最重要的因素，也是最難優(yōu)化的。緩存和 CDN 是最有效的優(yōu)化方法，但即使對于靜態(tài)內(nèi)容也要付出相當大的努力。

后端性能取決于單服務器性能和跨機器去分發(fā)工作的能力。水平可擴展性特別難以實現(xiàn)，必須從一開始就考慮。許多項目將可擴展性和性能作為事后處理，然而在它們的業(yè)務增長時會陷入大麻煩。

文獻和工具建議

有很多關于 web 性能和可擴展系統(tǒng)設計的書：由 Ilya Grigorik 所寫的?高性能瀏覽器網(wǎng)絡?包含了幾乎所有你需要了解的網(wǎng)絡和瀏覽器性能知識，并且目前不斷更新的版本可以免費在線閱讀哦！Martin Kleppmann 寫的?設計數(shù)據(jù)密集型應用?仍處于前期發(fā)布狀態(tài)，但已經(jīng)是其領域最好的書之一，它涵蓋了可擴展后端系統(tǒng)背后的大部分基礎知識，并擁有相當多的細節(jié)。設計性能?由Lara Callender Hogan 寫成，圍繞著構建快速的、具有良好的用戶體驗的網(wǎng)站，涵蓋了很多最佳實踐。

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

緩存動態(tài)內(nèi)容

所有緩存方法遇到的問題是它們不能處理動態(tài)內(nèi)容。這只是由于 HTTP 緩存的工作機制導致的。有兩種類型的緩存：基于失效的緩存（如轉(zhuǎn)發(fā)代理緩存和 CDN）和基于到期的緩存（如 ISP 緩存、機構代理和瀏覽器緩存）。基于失效的緩存可以從服務器端主動失效，基于到期的高速緩存只能從客戶端重新驗證。

使用基于到期的緩存時，棘手的事情是，你必須在首次從服務器拿到數(shù)據(jù)時指定緩存生命周期（TTL）。之后，你沒有任何機會將緩存數(shù)據(jù)刪除。它將由瀏覽器緩存提供到 TTL 到期的時刻。對于靜態(tài)資源，這不是一件復雜的事情，因為它們通常只會在你部署 web 應用程序的新版本時發(fā)生變化。因此，你可以使用?gulp-rev-all?和?grunt-filerev?等很酷的工具）對 assets 進行散列。

但是，但是你該如何處理運行時的應用數(shù)據(jù)加載和修改呢？更改用戶個人資料、更新帖子或添加新評論似乎不可能與瀏覽器緩存結合使用，因為你無法預估此類更新將來何時會發(fā)生。因此，緩存只能被禁用或使用非常小的 TTL。

由另一個客戶端更新時，緩存動態(tài)數(shù)據(jù)如何過時的示例

Baqend 的 Cache-Sketch 方法

在?Baqend，我們已經(jīng)研究并開發(fā)了一種方法，在實際獲取之前，檢查客戶端中 URL 的陳舊度。在每個用戶會話開始時，我們獲取一個非常小的數(shù)據(jù)結構，稱為布隆過濾器（Bloom Filter），它是所有過時資源集合的高度壓縮表示。通過查看布隆過濾器，客戶端可以檢查資源是否過時（包含在布隆過濾器中）或者是否是全新的。對于潛在的過時資源，我們繞過瀏覽器緩存并從 CDN 獲取內(nèi)容。在其他的所有情況下，我們直接用瀏覽器緩存提供內(nèi)容。使用瀏覽器緩存可以節(jié)省網(wǎng)絡流量和帶寬，并且是很快的。

此外，我們確保 CDN（以及其它基于失效的緩存，如 Varnish）始終包含最新的數(shù)據(jù)，只要它們過時就立即清除資源。

Baqend 如何確保緩存動態(tài)數(shù)據(jù)的新鮮度示例

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

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

性能收益

這一切都歸結為這一點。

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

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

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

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

動手比較?的截圖

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

Thinks 網(wǎng)上商城——所有的事實

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

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

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

Thinks?在電視播放的 30 分鐘里，我們得到了?340?萬的請求，300,000?位游客，高達?50,000?位的并發(fā)訪問游客和高達每秒 20,000 個請求，所有這一切實現(xiàn)了在 CDN 級別的?98.5％的緩存命中率，和平均為?3％的服務器 CPU 負載

因此，頁面加載時間為低于 1 秒，整個時間實現(xiàn)了?7.8％的極大的轉(zhuǎn)化率。

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

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

總結

我們已經(jīng)看到了在設計快速和可擴展的網(wǎng)站時需要克服的瓶頸：我們必須掌握關鍵呈現(xiàn)路徑，理解網(wǎng)絡限制、緩存的重要性和具有水平可擴展性的后端設計。

我們已經(jīng)看到了很多用來解決單個問題的工具，以及移動加速頁面（AMP）和漸進式 web 應用（PWA），這些采取了更全面的做法。但是，緩存動態(tài)數(shù)據(jù)的問題仍然存在。

Baqend?的做法是減少 web 開發(fā)，將構建主要放在前端，通過 JS SDK 使用 Baqend 完全托管的云服務上的后端功能，包括數(shù)據(jù)和文件存儲、（實時）查詢、推送通知、用戶管理和 OAuth 以及訪問控制。該平臺通過使用完整的 HTTP 緩存層次結構自動加速所有請求，并確保可用性和可擴展性。

我們對于 Baqend 的愿景是一個不需要加載時間的網(wǎng)站，并且我們想要給你到達這個目標的工具。

繼續(xù)前往免費試用?www.baqend.com.

PS:文章不錯，忍不住轉(zhuǎn)載了,轉(zhuǎn)載鏈接是:https://github.com/xitu/gold-miner/blob/master/TODO/building-a-shop-with-sub-second-page-loads-lessons-learned.md

轉(zhuǎn)載于:https://www.cnblogs.com/Andrew-XinFei/p/6202779.html

總結

以上是生活随笔為你收集整理的[转载] 全方位提升网站打开速度：前端、后端、新的技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：微信小程序组件循环
下一篇： supervisor开机自启动方法

生活随笔