這篇文章介紹了一些使前端應(yīng)用程序加載更快并提供良好用戶體驗的技術(shù)。

我們將研究前端的總體架構(gòu)，如何首先加載必需的資源，并最大化資源緩存的概率。

無論你的頁面是否需要成為客戶端應(yīng)用程序，還是如何優(yōu)化應(yīng)用程序的渲染時間，我都不會說太多后端如何傳遞資源。

總覽

我將把應(yīng)用程序加載分為三個不同的階段：

•  初始渲染 – 用戶看到任何東西之前需要多長時間？
•  應(yīng)用程序加載 – 用戶可以使用該應(yīng)用程序需要多長時間？
•  下一頁 – 導航到下一頁需要多長時間？

初始渲染

在瀏覽器的初始渲染之前，用戶看不到任何東西。渲染頁面至少需要加載 HTML 文件，但是大多數(shù)時候需要加載其他資源，例如 CSS 和 JavaScript 文件。一旦這些都加載完畢，瀏覽器就可以開始在屏幕上渲染。

在本文中，我將使用 WebPageTest 瀑布圖。你網(wǎng)站的請求瀑布可能看起來像這樣。

HTML 文檔將加載一堆其他文件，并在這些文件加載后渲染頁面。請注意， CSS 文件是并行加載的，因此每個其他請求不會增加明顯的延遲。

（備注：gov.uk 啟用了 HTTP/2，因此資產(chǎn)域可以重新使用與 www.gov.uk 的現(xiàn)有連接！我將在下面詳細討論服務(wù)器連接。）

減少渲染阻塞的請求

css 和（默認情況下） script 文件會阻止其下方的任何內(nèi)容渲染。

你可以通過以下幾種方法來解決此問題：

•  將腳本標簽放在 body 標簽的底部
•  使用 async 異步加載 script
•  內(nèi)聯(lián)使用小型的 JS 或 CSS 代碼段（如果需要同步加載）

避免順序渲染阻塞請求鏈

讓你的網(wǎng)站變慢的不一定是阻止渲染的請求數(shù)量。更重要的是每種資源的下載大小，以及瀏覽器發(fā)現(xiàn)需要加載資源的時間。

如果瀏覽器僅在另一個請求完成后才發(fā)現(xiàn)需要加載文件，則可以獲取同步請求鏈。發(fā)生這種情況可能有多種原因：

•  CSS 中的 @import 規(guī)則
•  CSS 文件中引用的 Webfonts
•  JavaScript 注入鏈接或腳本標簽

看一下這個例子：

這個網(wǎng)站在它的某個 CSS 文件中使用 @import 加載 Google Fonts。這意味著瀏覽器需要一個接一個地發(fā)出這些請求：

•  文件 HTML
•  應(yīng)用程序的 CSS
•  Google 字體 CSS
•  Google Font Woff文件（在瀑布圖中未顯示）

要解決這個問題，首先需要將 Google Fonts 的 CSS 請求從 @import 移動到 HTML 中的 link 標記，這就切斷了請求鏈條上的一個環(huán)節(jié)。

為了進一步加快速度，建議直接在 HTML 或 CSS 文件中內(nèi)聯(lián) Google Fonts CSS 文件。

(記住，來自 Google Fonts 的 CSS 響應(yīng)取決于用戶代理。如果你用 IE8 發(fā)出請求，CSS會引用一個 EOT 文件，IE11 會得到一個 woff 文件，而現(xiàn)在的瀏覽器會得到一個 woff2 文件。但是如果你不介意舊的瀏覽器使用系統(tǒng)字體，那么你可以復制粘貼 CSS 文件的內(nèi)容。)

即使頁面開始呈現(xiàn)后，用戶仍可能無法對該頁面執(zhí)行任何操作，因為在加載字體之前，不會顯示任何文本。可以通過 font-display swap 來避免這種情況，現(xiàn)在 Google Fonts 默認情況下已經(jīng)開始支持。

有時，消除請求鏈是不可行的。在這些情況下，可以考慮使用 preload 或 preconnect 標記。例如，在實際的 CSS 請求發(fā)出之前，上面的網(wǎng)站可以連接到 fonts.googleapis.com。

重復使用服務(wù)器連接以加快請求

建立新的服務(wù)器連接通常需要在服務(wù)器的瀏覽器之間進行3次往返：

•  DNS 查詢
•  建立 TCP 連接
•  建立 SSL 連接

連接就緒后，至少需要再進行一次往返來發(fā)送請求并下載響應(yīng)。

下面的瀑布顯示連接已啟動到四個不同的服務(wù)器：hostgator.com，optimize.com，googletagmanager.com 和 googelapis.com。

但是，對同一服務(wù)器的后續(xù)請求可以重新使用現(xiàn)有連接。因此，加載 base.css或 index1.css 的速度很快，因為它們也托管在 hostgator.com 上。

減小文件大小并使用CDN

除了文件大小之外，還有兩個其他因素會影響請求時間，這些因素都在你的控制范圍內(nèi)：資源大小和服務(wù)器位置。

向用戶發(fā)送盡可能少的數(shù)據(jù)，并確保將其壓縮（例如，使用 brotli 或 gzip ）。

內(nèi)容交付網(wǎng)絡(luò)在大量位置提供服務(wù)器，因此其中之一可能位于你的用戶附近。用戶可以連接到與其附近的 CDN 服務(wù)器，而不必連接到中央應(yīng)用程序服務(wù)器。這意味著服務(wù)器的往返時間將大大縮短。這對于諸如 CSS，JavaScript和  Image 之類的靜態(tài)資產(chǎn)特別方便，因為它們易于分發(fā)。

使用 service workers 跳過網(wǎng)絡(luò)

service workers 允許你在請求進入網(wǎng)絡(luò)之前攔截它們。這意味著你可以實現(xiàn)瞬時首屏渲染!

當然，這只在你不需要網(wǎng)絡(luò)發(fā)送響應(yīng)時才有效。你需要已經(jīng)緩存了響應(yīng)，所以用戶只有在第二次加載你的應(yīng)用時才會受益。

下面的 service workers 緩存呈現(xiàn)頁面所需的HTML和CSS。當再次加載應(yīng)用程序時，它會嘗試為緩存的資源提供服務(wù)，如果資源不可用，則會返回到網(wǎng)絡(luò)。 

self.addEventListener("install", async e => {  
 caches.open("v1").then(function (cache) {  
   return cache.addAll(["/app", "/app.css"]);  
 });  
});  
self.addEventListener("fetch", event => {  
 event.respondWith(  
   caches.match(event.request).then(cachedResponse => {  
     return cachedResponse || fetch(event.request);  
   })  
 );  
}); 

應(yīng)用加載

好的，現(xiàn)在用戶已經(jīng)可以看到一些東西，然后他們在可以使用你的應(yīng)用程序之前還需要什么？

•  加載應(yīng)用程序代碼（JS和CSS）
•  加載頁面的基本數(shù)據(jù)
•  加載其他數(shù)據(jù)和圖像

請注意，不僅僅是延遲從網(wǎng)絡(luò)加載數(shù)據(jù)會延遲渲染。加載代碼后，瀏覽器將需要解析，編譯和執(zhí)行它。

Bundle split：僅加載必要的代碼，并最大化緩存命中率

Bundle split 允許只加載當前頁面所需的代碼，而不是加載整個應(yīng)用程序。Bundle split 還意味著可以緩存其中的一部分，即使其他部分已經(jīng)更改，需要重新加載。

通常，代碼被分成三種不同類型的文件:

•  網(wǎng)頁本身專用代碼
•  共享應(yīng)用程序代碼
•  很少更改的第三方模塊（非常適合緩存！）

Webpack 可以使用 optimization.splitChunks 自動拆分共享代碼以減少總下載量。確保啟用運行時塊，以使 chunk 哈希穩(wěn)定，并從長期緩存中受益。

分離頁面特定的代碼不能自動完成，你需要識別可以單獨加載的位。通常這是一個特定的路徑或一組頁面。使用動態(tài)導入來延遲加載代碼。

Bundle split 會導致更多的請求被發(fā)送來加載你的應(yīng)用程序。但是只要請求是并行發(fā)送的，這就不是什么大問題，特別是當你的站點開啟了 HTTP/2 服務(wù)的時候。你可以看到在這個瀑布的前三個請求:

然而，這個瀑布圖還顯示了兩個按順序發(fā)出的請求。這些塊只在這個頁面中需要，并通過 import() 調(diào)用動態(tài)加載。

如果你知道需要這些塊，你可以通過插入預加載鏈接標記來解決這個問題。

但是，你會看到，與總頁面加載時間相比，這樣做的好處可能很小。

另外，使用預加載有時會適得其反，因為加載其他更重要的文件時可能會延遲。

加載頁面數(shù)據(jù)

你的應(yīng)用程序可能是用來顯示一些數(shù)據(jù)的。下面是一些提示，你可以使用這些提示盡早加載數(shù)據(jù)并避免呈現(xiàn)延遲。

在開始加載數(shù)據(jù)之前不要等待包

這是一個順序請求鏈的特殊情況:你加載應(yīng)用程序包，然后代碼請求頁面數(shù)據(jù)。

有兩種方法可以避免這種情況：

•  將頁面數(shù)據(jù)嵌入HTML文檔中
•  通過文檔中的內(nèi)聯(lián)腳本啟動數(shù)據(jù)請求

將數(shù)據(jù)嵌入HTML可以確保你的應(yīng)用程序不必等待數(shù)據(jù)加載。這也降低了應(yīng)用程序的復雜性，因為你不必處理加載狀態(tài)。

但是，如果獲取數(shù)據(jù)會大大延遲你的文檔響應(yīng)，那將不是一個好主意，因為這會延遲你的初始渲染。

在這種情況下，或者如果你通過服務(wù)工作者提供緩存的HTML文檔，則可以將內(nèi)聯(lián)腳本嵌入到HTML中以加載此數(shù)據(jù)。你可以將其作為全局 promise 提供，如下所示： 

window.userDataPromise = fetch("/me") 

然后，如果數(shù)據(jù)準備就緒，你的應(yīng)用程序可以立即開始渲染，或者等到準備就緒。

對于這兩種技術(shù)，你都需要知道在應(yīng)用開始呈現(xiàn)之前頁面必須加載哪些數(shù)據(jù)。對于與用戶相關(guān)的數(shù)據(jù)（用戶名，通知 ...），這往往很容易，但是對于特定于頁面的內(nèi)容，則比較棘手。考慮確定最重要的頁面并為這些頁面編寫自定義邏輯。

等待非必需數(shù)據(jù)時不要阻塞渲染

有時生成頁面數(shù)據(jù)需要緩慢的復雜后端邏輯。在這些情況下，如果足以使你的應(yīng)用程序具有功能性和交互性，則可以首先加載較簡單的數(shù)據(jù)版本。

例如，分析工具可以在加載圖表數(shù)據(jù)之前首先加載所有圖表的列表。這使用戶可以立即查找他們感興趣的圖表，還可以幫助將后端請求分散到不同的服務(wù)器上。

避免順序數(shù)據(jù)請求鏈

這可能與我先前關(guān)于在第二個請求中加載非必需數(shù)據(jù)的觀點相沖突，但是如果每個完成的請求都不會導致向用戶顯示更多信息，則避免順序請求鏈。

與其先發(fā)出關(guān)于用戶登錄身份的請求，然后再請求其所屬團隊的列表，不如在用戶信息旁邊返回團隊列表。你可以使用 GraphQL ，但自定義用戶呢? includeTeams=true endpoint 也很有用。

與其首先請求用戶登錄為誰，然后請求他們所屬的團隊列表，

服務(wù)端端渲染

服務(wù)端端渲染意味著在服務(wù)器上預渲染你的應(yīng)用程序，并使用整頁HTML響應(yīng)文檔請求。這意味著客戶端可以看到完全呈現(xiàn)的頁面，而不必等待加載其他代碼或數(shù)據(jù)！

由于服務(wù)器只是將靜態(tài)HTML發(fā)送給客戶端，因此你的應(yīng)用尚無法進行交互。需要加載應(yīng)用程序，它需要重新運行呈現(xiàn)邏輯，然后將必要的事件偵聽器附加到DOM。

如果看到非交互式內(nèi)容很有價值，請使用服務(wù)器呈現(xiàn)。如果你能夠?qū)⒊尸F(xiàn)的HTML緩存在服務(wù)器上并將其提供給所有用戶而又不會延遲初始文檔請求，那么它也將有所幫助。例如，如果你使用 React 來渲染博客文章，則服務(wù)器渲染非常合適。

下一頁

在某個時候，用戶將與你的應(yīng)用進行交互并轉(zhuǎn)到下一頁。打開初始頁面后，你可以控制瀏覽器中發(fā)生的事情，因此你可以準備進行下一次交互。

預取資源

如果你預加載了下一頁所需的代碼，則可以消除用戶啟動導航時的延遲。使用 prefetch 標記，或 webpackPrefetch 用于動態(tài)導入： 

import(  
    /* webpackPrefetch: true, webpackChunkName: "todo-list" */"./TodoList"  
) 

注意你使用了多少用戶數(shù)據(jù)和帶寬，特別是當他們使用移動連接時。如果他們使用的是你網(wǎng)站的移動版本，或者他們啟用了保存數(shù)據(jù)模式，你可以減少預加載。

對于用戶最可能需要的應(yīng)用程序部分，要有策略。

重用已經(jīng)加載的數(shù)據(jù)

在應(yīng)用程序中本地緩存 Ajax 數(shù)據(jù)，并使用它來避免未來的請求。如果用戶從團隊列表導航到“編輯團隊”頁面，你可以通過重用已經(jīng)獲取的數(shù)據(jù)來立即進行轉(zhuǎn)換。

請注意，如果你的實體經(jīng)常被其他用戶編輯，并且你下載的數(shù)據(jù)可能已經(jīng)過期，那么這種方法將不起作用。在這些情況下，在獲取最新數(shù)據(jù)時，請首先考慮以只讀方式顯示現(xiàn)有數(shù)據(jù)。

結(jié)論

本文介紹了許多因素，這些因素可能會在加載過程的不同時刻使你的頁面速度減慢。使用 Chrome DevTools，WebPageTest和Lighthouse之類的工具來確定其中哪些適用于你的應(yīng)用程序。

實際上，你幾乎不可能在所有方面進行優(yōu)化。找出對用戶有最大影響的因素，并專注于此。

我在寫這篇文章時意識到的一件事是，我根深蒂固地相信，發(fā)出許多單獨的請求對性能不利。過去，當每個請求都需要一個單獨的連接時，Thas就是這樣，而瀏覽器每個域只允許幾個連接。但是，使用 HTTP/2 和現(xiàn)代瀏覽器已不再是這種情況。

并且有強烈的理由支持拆分請求。它允許僅加載必要的資源，并可以更好地利用緩存的內(nèi)容，因為僅需要重新加載已更改的文件。