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

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

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

總覽

我將把應用程序加載分為三個不同的階段：

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

初始渲染

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

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

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

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

減少渲染阻塞的請求

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

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

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

避免順序渲染阻塞請求鏈

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

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

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

看一下這個例子：

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

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

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

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

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

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

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

重復使用服務器連接以加快請求

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

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

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

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

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

減小文件大小并使用CDN

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

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

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

使用 service workers 跳過網絡

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

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

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

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);  
   })  
 );  
}); 

應用加載

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

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

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

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

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

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

•  網頁本身專用代碼
•  共享應用程序代碼
•  很少更改的第三方模塊（非常適合緩存?。?/li>

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

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

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

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

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

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

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

加載頁面數(shù)據

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

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

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

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

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

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

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

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

window.userDataPromise = fetch("/me") 

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

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

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

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

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

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

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

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

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

服務端端渲染

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

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

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

下一頁

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

預取資源

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

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

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

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

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

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

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

結論

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

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

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

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