2021 年前端性能：定義環境

本指南得到了我們在 LogRocket 的朋友的大力支持，LogRocket 是一項結合前端性能監控、會話重放和產品分析的服務，可幫助您建立更好的客戶體驗。 LogRocket跟踪關鍵指標，包括。 DOM 完成、第一個字節的時間、第一個輸入延遲、客戶端 CPU 和內存使用情況。 立即免費試用 LogRocket。

目錄

1. 準備：計劃和指標
2. 設定切合實際的目標
3. 定義環境
4. 資產優化
5. 構建優化
6. 交付優化
7. 網絡、HTTP/2、HTTP/3
8. 測試和監控
9. 快速獲勝
10. 一切都在一頁上
11. 下載清單（PDF、Apple Pages、MS Word）
12. 訂閱我們的電子郵件通訊不要錯過下一個指南。

定義環境

1. 選擇並設置您的構建工具。
   不要過分關注這些天所謂的酷。 堅持您的構建環境，無論是 Grunt、Gulp、Webpack、Parcel 還是工具組合。 只要你得到你需要的結果並且你在維護你的構建過程沒有問題，你就做得很好。

   在構建工具中，Rollup 和 Snowpack 一直受到關注，但 Webpack 似乎是最成熟的工具，有數百個插件可用於優化構建的大小。 注意 Webpack 路線圖 2021。

   最近出現的最著名的策略之一是在 Next.js 和 Gatsby 中使用 Webpack 進行粒度分塊，以最大限度地減少重複代碼。 默認情況下，可以為不使用它的路由請求未在每個入口點共享的模塊。 這最終成為一種開銷，因為下載的代碼比必要的多。 通過 Next.js 中的粒度分塊，我們可以使用服務器端構建清單文件來確定哪些輸出的塊被不同的入口點使用。

   

   使用 SplitChunksPlugin，根據多個條件創建多個拆分塊，以防止跨多個路由獲取重複代碼。 這改善了導航期間的頁面加載時間和緩存。 在 Next.js 9.2 和 Gatsby v2.20.7 中發布。

   不過，開始使用 Webpack 可能會很困難。 所以如果你想深入研究 Webpack，這裡有一些很棒的資源：

   • Webpack 文檔——顯然——是一個很好的起點，Webpack - Raja Rao 的 The Confusing Bits 和 Andrew Welch 的 An Annotated Webpack Config 也是如此。
   • Sean Larkin 有一個關於 Webpack 的免費課程：核心概念和 Jeffrey Way 為每個人發布了一個很棒的關於 Webpack 的免費課程。 它們都是深入研究 Webpack 的絕佳介紹。
   • Webpack Fundamentals 是一個非常全面的 4 小時課程，由 FrontendMasters 發布，由 Sean Larkin 教授。
   • Webpack 示例有數百個現成的 Webpack 配置，按主題和用途分類。 獎勵：還有一個生成基本配置文件的 Webpack 配置配置器。
   • awesome-webpack 是一個有用的 Webpack 資源、庫和工具的精選列表，包括 Angular、React 和框架無關項目的文章、視頻、課程、書籍和示例。
   • 使用 Webpack 快速構建資產的旅程是 Etsy 的案例研究，該案例研究團隊如何從使用基於 RequireJS 的 JavaScript 構建系統切換到使用 Webpack，以及他們如何優化他們的構建，平均在4 分鐘內管理超過 13,200 個資產。
   • Webpack 性能技巧是 Ivan Akulov 的一個金礦主題，其中包含許多以性能為中心的技巧，包括專門針對 Webpack 的技巧。
   • awesome-webpack-perf 是一個金礦 GitHub 存儲庫，其中包含有用的 Webpack 工具和插件以提高性能。 也由 Ivan Akulov 維護。

1. 使用漸進增強作為默認值。
   儘管如此，經過這麼多年，將漸進增強作為前端架構和部署的指導原則是一個安全的選擇。 首先設計和構建核心體驗，然後使用功能強大的瀏覽器的高級功能增強體驗，創造彈性體驗。 如果您的網站在次優網絡上運行速度較慢且瀏覽器較差且屏幕較差的機器上運行得很快，那麼它只會在速度較快且瀏覽器良好且網絡良好的機器上運行得更快。

   事實上，通過自適應模塊服務，我們似乎正在將漸進增強提升到另一個層次，為低端設備提供“精簡”核心體驗，並為高端設備提供更複雜的功能。 漸進式增強不太可能很快消失。

2. 選擇強大的性能基準。
   有很多未知因素影響加載——網絡、熱限制、緩存驅逐、第三方腳本、解析器阻塞模式、磁盤 I/O、IPC 延遲、安裝的擴展、防病毒軟件和防火牆、後台 CPU 任務、硬件和內存限制， L2/L3 緩存、RTTS 的差異——JavaScript 的體驗成本最高，僅次於默認阻止渲染的 Web 字體和通常消耗過多內存的圖像。 隨著性能瓶頸從服務器轉移到客戶端，作為開發人員，我們必須更詳細地考慮所有這些未知因素。

   170KB 的預算已經包含關鍵路徑 HTML/CSS/JavaScript、路由器、狀態管理、實用程序、框架和應用程序邏輯，我們必須徹底檢查網絡傳輸成本、解析/編譯時間和運行時成本我們選擇的框架。 幸運的是，在過去幾年中，我們已經看到瀏覽器解析和編譯腳本的速度有了巨大的改進。 然而，JavaScript 的執行仍然是主要瓶頸，因此密切關註腳本執行時間和網絡可能會產生影響。

   Tim Kadlec 對現代框架的性能進行了出色的研究，並在“JavaScript 框架有成本”一文中對其進行了總結。 我們經常談論獨立框架的影響，但正如 Tim 所說，在實踐中，使用多個框架並不少見。 也許是舊版本的 jQuery 正在慢慢遷移到現代框架，以及一些使用舊版本 Angular 的遺留應用程序。 因此，探索 JavaScript 字節和 CPU 執行時間的累積成本更合理，這很容易使用戶體驗幾乎無法使用，即使在高端設備上也是如此。

   一般來說，現代框架不會優先考慮功能較弱的設備，因此手機和台式機上的體驗在性能方面通常會大不相同。 根據研究，使用 React 或 Angular 的網站在 CPU 上花費的時間比其他網站多（當然這並不一定說 Rea​​ct 在 CPU 上比 Vue.js 更昂貴）。

   根據 Tim 的說法，有一件事是顯而易見的：“如果您使用框架來構建您的網站，那麼您就需要在初始性能方面進行權衡——即使在最好的情況下也是如此。”

1. 評估框架和依賴項。
   現在，並不是每個項目都需要一個框架，也不是單頁應用程序的每個頁面都需要加載一個框架。 在 Netflix 的案例中，“從客戶端移除 React、多個庫和相應的應用程序代碼將 JavaScript 的總量減少了 200 KB 以上，導致 Netflix 的註銷主頁的 Time-to-Interactivity 減少了 50% 以上。” 然後，團隊利用用戶在登陸頁面上花費的時間來為用戶可能登陸的後續頁面預取 React（請繼續閱讀以了解詳細信息）。

   那麼，如果您完全刪除關鍵頁面上的現有框架怎麼辦？ 使用 Gatsby，您可以檢查 gatsby-plugin-no-javascript，它會從靜態 HTML 文件中刪除 Gatsby 創建的所有 JavaScript 文件。 在 Vercel 上，您還可以允許在生產中為某些頁面禁用運行時 JavaScript（實驗性）。

   一旦選擇了一個框架，我們將至少使用它幾年，所以如果我們需要使用一個框架，我們需要確保我們的選擇是明智的和經過深思熟慮的——尤其是對於我們的關鍵性能指標關心。

   數據顯示，默認情況下，框架非常昂貴：58.6% 的 React 頁面交付超過 1 MB 的 JavaScript，36% 的 Vue.js 頁面加載的 First Contentful Paint 小於 1.5 秒。 根據 Ankur Sethi 的一項研究，“無論你如何優化它，你的 React 應用程序在印度普通手機上的加載速度永遠不會超過 1.1 秒。你的 Angular 應用程序總是至少需要 2.7 秒才能啟動。您的 Vue 應用程序的用戶需要等待至少 1 秒鐘才能開始使用它。” 無論如何，您可能不會將印度作為您的主要市場，但在網絡條件欠佳的情況下訪問您的網站的用戶將獲得類似的體驗。

   當然，可以快速製作 SPA，但它們並不是開箱即用的快速，因此我們需要考慮製作和保持快速所需的時間和精力。 儘早選擇輕量級的基準性能成本可能會更容易。

   那麼我們如何選擇框架呢？ 在選擇選項之前，至少考慮大小的總成本 + 初始執行時間是個好主意； Preact、Inferno、Vue、Svelte、Alpine 或 Polymer 等輕量級選項可以很好地完成工作。 基線的大小將定義應用程序代碼的約束。

   正如 Seb Markbage 所指出的，衡量框架啟動成本的一個好方法是首先渲染一個視圖，然後刪除它，然後再次渲染，因為它可以告訴您框架如何擴展。 第一次渲染往往會預熱一堆延遲編譯的代碼，更大的樹在擴展時可以從中受益。 第二個渲染基本上是模擬頁面上的代碼重用如何隨著頁面複雜性的增長而影響性能特徵。

   您可以通過探索功能、可訪問性、穩定性、性能、包生態系統、社區、學習曲線、文檔、工具、跟踪記錄，在 Sacha Greif 的 12 分制評分系統上評估您的候選人（或一般的任何 JavaScript 庫） 、團隊、兼容性、安全性等。

   

   您還可以依賴在較長時間內在網絡上收集的數據。 例如，Perf Track 大規模跟踪框架性能，顯示使用 Angular、React、Vue、Polymer、Preact、Ember、Svelte 和 AMP 構建的網站的原始聚合Core Web Vitals 分數。 您甚至可以指定和比較使用 Gatsby、Next.js 或 Create React App 構建的網站，以及使用 Nuxt.js (Vue) 或 Sapper (Svelte) 構建的網站。

   一個好的起點是為您的應用程序選擇一個好的默認堆棧。 Gatsby (React)、Next.js (React)、Vuepress (Vue)、Preact CLI 和 PWA Starter Kit 提供了合理的默認值，可以在普通移動硬件上開箱即用地快速加載。 另外，請查看針對 React 和 Angular 的 web.dev 框架特定的性能指南（感謝 Phillip！ ）。

   或許您可以採用一種更令人耳目一新的方法來完全構建單頁應用程序——Turbolinks，一個 15KB 的 JavaScript 庫，它使用 HTML 而不是 JSON 來呈現視圖。 因此，當您點擊鏈接時，Turbolinks 會自動獲取頁面，交換其<body>並合併其<head> ，所有這些都不會產生整個頁面加載的成本。 您可以查看有關堆棧（Hotwire）的快速詳細信息和完整文檔。

1. 客戶端渲染還是服務器端渲染？ 兩個都！
   這是一個相當激烈的談話。 最終的方法是設置某種漸進式引導：使用服務器端渲染來獲得快速的 First Contentful Paint，但還包括一些最少的必要 JavaScript 以保持與 First Contentful Paint 接近的交互時間。 如果在 FCP 之後 JavaScript 來得太晚，瀏覽器會在解析、編譯和執行後期發現的 JavaScript 時鎖定主線程，從而束縛站點或應用程序的交互性。

   為避免這種情況，請始終將函數的執行分解為單獨的異步任務，並在可能的情況下使用requestIdleCallback 。 考慮使用 WebPack 的動態import()支持延遲加載 UI 的部分，避免加載、解析和編譯成本，直到用戶真正需要它們（感謝 Addy！ ）。

   如上所述，交互時間 (TTI) 告訴我們導航和交互之間的時間。 具體來說，該指標是通過查看初始內容呈現後的第一個 5 秒窗口來定義的，其中沒有任何 JavaScript 任務花費超過 50 毫秒（長任務）。 如果發生超過 50 毫秒的任務，則重新開始搜索 5 秒窗口。 結果，瀏覽器將首先假定它到達Interactive ，只是為了切換到Frozen ，最終切換回Interactive 。

   一旦我們到達Interactive ，我們就可以 - 按需或在時間允許的情況下 - 啟動應用程序的非必要部分。 不幸的是，正如 Paul Lewis 所注意到的，框架通常沒有可以向開發人員展示的簡單優先級概念，因此對於大多數庫和框架來說，漸進式引導並不容易實現。

   不過，我們正在到達那裡。 這些天來，我們可以探索幾個選擇，Houssein Djirdeh 和 Jason Miller 在他們關於 Rendering on the Web 的演講以及 Jason 和 Addy 關於現代前端架構的文章中對這些選項進行了很好的概述。 下面的概述基於他們的出色工作。

   • 完整的服務器端渲染(SSR)
     在 WordPress 等經典 SSR 中，所有請求都完全在服務器上處理。 請求的內容作為完成的 HTML 頁面返回，瀏覽器可以立即呈現它。 因此，例如，SSR 應用程序不能真正使用 DOM API。 First Contentful Paint 和 Time to Interactive 之間的差距通常很小，並且頁面可以在 HTML 流式傳輸到瀏覽器時立即呈現。

     這避免了在客戶端獲取數據和模板的額外往返，因為它是在瀏覽器得到響應之前處理的。 但是，我們最終會得到更長的服務器思考時間，從而導致第一個字節的時間，並且我們沒有利用現代應用程序的響應式和豐富的特性。

   • 靜態渲染
     我們將產品構建為單頁應用程序，但所有頁面都使用最少的 JavaScript 作為構建步驟預先呈現為靜態 HTML。 這意味著通過靜態渲染，我們可以提前為每個可能的 URL生成單獨的 HTML 文件，這是很多應用程序無法承受的。 但是由於不必動態生成頁面的 HTML，我們可以實現始終如一的快速首字節時間。 因此，我們可以快速顯示一個登錄頁面，然後為後續頁面預取一個 SPA 框架。 Netflix 採用了這種方法，將加載和交互時間減少了 50%。

   • 使用（重新）水合的服務器端渲染（通用渲染，SSR + CSR）
     我們可以嘗試使用兩全其美的方法——SSR 和 CSR 方法。 通過混合水化，從服務器返回的 HTML 頁面還包含一個腳本，用於加載成熟的客戶端應用程序。 理想情況下，實現快速的 First Contentful Paint（如 SSR），然後通過（重新）水化繼續渲染。 不幸的是，這種情況很少見。 更常見的情況是，頁面看起來確實準備好了，但它無法響應用戶的輸入，從而產生憤怒的點擊和放棄。

     使用 React，我們可以在 Express 等 Node 服務器上使用ReactDOMServer模塊，然後調用renderToString方法將頂級組件呈現為靜態 HTML 字符串。

     使用 Vue.js，我們可以使用 vue-server-renderer 使用renderToString將 Vue 實例渲染為 HTML。 在 Angular 中，我們可以使用@nguniversal將客戶端請求轉換為完全由服務器渲染的 HTML 頁面。 使用 Next.js (React) 或 Nuxt.js (Vue) 也可以開箱即用地實現完全服務器渲染的體驗。

     這種方法有其缺點。 因此，我們確實獲得了客戶端應用程序的完全靈活性，同時提供了更快的服務器端渲染，但我們最終也會在 First Contentful Paint 和 Time To Interactive 之間存在更長的差距，並且增加了 First Input Delay。 補液非常昂貴，通常僅此策略還不夠好，因為它會嚴重延遲 Time To Interactive。

     
   • 使用漸進式水化 (SSR + CSR) 的流式服務器端渲染
     為了最小化 Time To Interactive 和 First Contentful Paint 之間的差距，我們一次渲染多個請求，並在生成內容時分塊發送內容。 因此，我們不必在將內容髮送到瀏覽器之前等待完整的 HTML 字符串，從而改進了 Time To First Byte。

     在 React 中，我們可以使用 renderToNodeStream() 來代替renderToString() () 來管道響應並以塊的形式發送 HTML。 在 Vue 中，我們可以使用可以管道和流式傳輸的 renderToStream()。 使用 React Suspense，我們也可以為此目的使用異步渲染。

     在客戶端，我們不是一次啟動整個應用程序，而是逐步啟動組件。 應用程序的部分首先通過代碼拆分分解為獨立的腳本，然後逐漸水合（按照我們的優先級順序）。 事實上，我們可以先對關鍵成分進行水合，然後再對其餘成分進行水合。 然後，每個組件可以不同地定義客戶端和服務器端渲染的角色。 然後，我們還可以推遲某些組件的水合，直到它們出現，或者用戶交互需要，或者瀏覽器空閒時。

     對於 Vue，Markus Oberlehner 發布了一份關於使用用戶交互水合以及 vue-lazy-hydration 減少 SSR 應用程序的交互時間的指南，這是一個早期插件，可在可見性或特定用戶交互上啟用組件水合。 Angular 團隊使用 Ivy Universal 進行漸進式補水。 您也可以使用 Preact 和 Next.js 實現部分水合。

   • 三態渲染
     有了服務工作者，我們可以使用流式服務器渲染來進行初始/非 JS 導航，然後讓服務工作者在安裝後為導航渲染 HTML。 在這種情況下，Service Worker 會預先呈現內容並啟用 SPA 風格的導航，以便在同一會話中呈現新視圖。 當您可以在服務器、客戶端頁面和服務工作者之間共享相同的模板和路由代碼時，效果很好。

   

   • 帶有預渲染的 CSR
     預渲染類似於服務器端渲染，但不是在服務器上動態渲染頁面，而是在構建時將應用程序渲染為靜態 HTML。 雖然靜態頁面無需太多客戶端 JavaScript 即可完全交互，但預渲染的工作方式有所不同。 基本上，它在構建時將客戶端應用程序的初始狀態捕獲為靜態 HTML，而通過預渲染，必須在客戶端上啟動應用程序才能使頁面具有交互性。

     使用 Next.js，我們可以通過將應用程序預渲染為靜態 HTML 來使用靜態 HTML 導出。 在 Gatsby 中，一個使用 React 的開源靜態站點生成器，在構建期間使用renderToStaticMarkup方法而不是renderToString方法，預加載主 JS 塊並預取未來路由，沒有簡單靜態頁面不需要的 DOM 屬性。

     對於 Vue，我們可以使用 Vuepress 來達到同樣的目的。 你也可以在 Webpack 中使用 prerender-loader。 Navi 也提供靜態渲染。

     結果是更好的 Time To First Byte 和 First Contentful Paint，我們減少了 Time To Interactive 和 First Contentful Paint 之間的差距。 如果預計內容會發生很大變化，我們就不能使用這種方法。 此外，必須提前知道所有 URL 才能生成所有頁面。 所以一些組件可能會使用預渲染來渲染，但如果我們需要動態的東西，我們必須依賴應用程序來獲取內容。

   • 完整的客戶端渲染(CSR)
     所有邏輯、渲染和啟動都在客戶端完成。 結果通常是 Time To Interactive 和 First Contentful Paint 之間的巨大差距。 結果，應用程序經常感覺遲緩，因為整個應用程序必須在客戶端上啟動才能呈現任何內容。

     由於 JavaScript 有性能成本，隨著 JavaScript 的數量隨著應用程序的增長而增長，激進的代碼拆分和延遲 JavaScript 將絕對有必要馴服 JavaScript 的影響。 對於這種情況，如果不需要太多交互性，服務器端渲染通常是更好的方法。 如果這不是一個選項，請考慮使用 App Shell 模型。

     一般來說，SSR 比 CSR 快。 然而，對於許多應用程序來說，它仍然是一個相當頻繁的實現。

   那麼，客戶端還是服務器端？ 一般來說，將完全客戶端框架的使用限制在絕對需要它們的頁面上是一個好主意。 對於高級應用程序，單獨依賴服務器端渲染也不是一個好主意。 如果做得不好，服務器渲染和客戶端渲染都是一場災難。

   無論您是傾向於 CSR 還是 SSR，請確保您盡快渲染重要的像素，並將該渲染與 Time To Interactive 之間的差距最小化。 如果您的頁面沒有太大變化，請考慮預渲染，並儘可能推遲框架的啟動。 使用服務器端渲染將 HTML 分塊流式傳輸，並為客戶端渲染實現漸進式水合- 並在可見性、交互或空閒時間進行水合，以獲得兩全其美的效果。

1. 我們可以靜態服務多少？
   無論您是在處理大型應用程序還是小型站點，都值得考慮哪些內容可以從 CDN（即 JAM 堆棧）靜態提供，而不是動態生成。 即使您擁有數千種產品和數百個具有大量個性化選項的過濾器，您仍可能希望靜態提供關鍵登錄頁面，並將這些頁面與您選擇的框架分離。

   有很多靜態站點生成器，它們生成的頁面通常非常快。 我們可以提前預構建的內容越多，而不是在請求時在服務器或客戶端上生成頁面視圖，我們將獲得更好的性能。

   在構建部分水合、漸進增強的靜態網站中，Markus Oberlehner 展示瞭如何使用靜態站點生成器和 SPA 構建網站，同時實現漸進增強和最小的 JavaScript 包大小。 Markus 使用Eleventy 和 Preact作為他的工具，並展示瞭如何設置工具、添加部分水合、延遲水合、客戶端入口文件、為 Preact 配置 Babel 以及將 Preact 與 Rollup 捆綁在一起——從頭到尾。

   如今，隨著 JAMStack 在大型網站上的使用，出現了一個新的性能考慮：構建時間。 事實上，即使每次新部署構建數千個頁面也可能需要幾分鐘，因此很有希望看到 Gatsby 中的增量構建將構建時間縮短60 倍，並集成到流行的 CMS 解決方案中，如 WordPress、Contentful、Drupal、Netlify CMS和別的。

   

   此外，Next.js 宣布了提前和增量靜態生成，它允許我們在運行時添加新的靜態頁面，並在現有頁面已經構建後更新它們，通過在流量進入時在後台重新渲染它們.

   需要更輕量級的方法？ 在關於 Eleventy、Alpine 和 Tailwind 的演講中：邁向輕量級 Jamstack，Nicola Goutay 解釋了 CSR、SSR 和介於兩者之間的所有內容之間的區別，並展示瞭如何使用更輕量級的方法 - 以及顯示該方法的 GitHub 存儲庫在實踐中。

2. 考慮使用 PRPL 模式和 app shell 架構。
   不同的框架會對性能產生不同的影響，並且需要不同的優化策略，因此您必須清楚地了解您將依賴的框架的所有細節。 在構建 Web 應用程序時，請查看 PRPL 模式和應用程序外殼架構。 這個想法非常簡單：推送獲得交互所需的最少代碼以使初始路由快速呈現，然後使用 service worker 緩存和預緩存資源，然後異步延遲加載您需要的路由。

1. 您是否優化了 API 的性能？
   API 是應用程序通過端點向內部和第三方應用程序公開數據的通信渠道。 在設計和構建 API 時，我們需要一個合理的協議來實現服務器和第三方請求之間的通信。 Representational State Transfer ( REST ) 是一種成熟的、合乎邏輯的選擇：它定義了一組開發人員遵循的約束，以使內容以高性能、可靠和可擴展的方式可訪問。 符合 REST 約束的 Web 服務稱為RESTful Web 服務。

   與良好的 ol' HTTP 請求一樣，當從 API 檢索數據時，服務器響應的任何延遲都會傳播到最終用戶，從而延遲渲染。 當資源想要從 API 中檢索一些數據時，它需要從相應的端點請求數據。 渲染來自多個資源的數據的組件，例如在每個評論中包含評論和作者照片的文章，可能需要多次往返服務器以獲取所有數據，然後才能渲染它。 此外，通過 REST 返回的數據量通常超過渲染該組件所需的數據量。

   如果許多資源需要來自 API 的數據，則 API 可能會成為性能瓶頸。 GraphQL 為這些問題提供了一個高性能的解決方案。 就其本身而言，GraphQL 是一種用於 API 的查詢語言，也是一種服務器端運行時，用於使用您為數據定義的類型系統來執行查詢。 與 REST 不同，GraphQL 可以在單個請求中檢索所有數據，並且響應將完全符合要求，而不會像 REST 通常發生的那樣過度或不足地獲取數據。

   此外，由於 GraphQL 使用模式（說明數據結構的元數據），它已經可以將數據組織成首選結構，因此，例如，使用 GraphQL，我們可以刪除用於處理狀態管理的 JavaScript 代碼，生成更簡潔的應用程序代碼，在客戶端上運行得更快。

   如果您想開始使用 GraphQL 或遇到性能問題，這些文章可能會很有幫助：

   • GraphQL 入門：為什麼我們需要一種新的 API，作者 Eric Baer，
   • A GraphQL Primer: The Evolution of API Design by Eric Baer,
   • Leonardo Losoviz 設計了一個 GraphQL 服務器以獲得最佳性能，
   • Wojciech Trocki 解釋了 GraphQL 性能。

1. 您會使用 AMP 還是 Instant Articles？
   根據您組織的優先事項和戰略，您可能需要考慮使用 Google 的 AMP 或 Facebook 的 Instant Articles 或 Apple 的 Apple News。 沒有它們你也能獲得良好的性能，但 AMP確實提供了一個可靠的性能框架和一個免費的內容交付網絡 (CDN)，而 Instant Articles 將提高你在 Facebook 上的知名度和性能。

   這些技術對用戶來說看似顯而易見的好處是保證了性能，因此有時他們甚至可能更喜歡 AMP-/Apple News/Instant Pages-鏈接，而不是“常規”和可能臃腫的頁面。 對於處理大量第三方內容的內容密集型網站，這些選項可能有助於顯著加快渲染時間。

   除非他們沒有。 例如，根據 Tim Kadlec 的說法，“AMP 文檔往往比其對應文檔更快，但它們並不一定意味著頁面是高性能的。從性能角度來看，AMP 並不是最大的區別。”

   網站所有者的好處是顯而易見的：這些格式在各自平台上的可發現性以及在搜索引擎中的可見性增加。

   好吧，至少以前是這樣的。 由於 AMP 不再是Top Stories的要求，出版商可能會從 AMP 轉向傳統堆棧（謝謝，Barry！ ）。

   不過，您也可以通過重用 AMP 作為 PWA 的數據源來構建漸進式 Web AMP。 缺點？ 顯然，在圍牆花園中的存在使開發人員能夠製作和維護其內容的單獨版本，並且在沒有實際 URL 的 Instant Articles 和 Apple News 的情況下（感謝 Addy，Jeremy！） 。

2. 明智地選擇您的 CDN。
   如上所述，根據您擁有多少動態數據，您可能能夠將部分內容“外包”給靜態站點生成器，將其推送到 CDN 並從中提供靜態版本，從而避免向服務器。 事實上，其中一些生成器實際上是網站編譯器，提供了許多開箱即用的自動優化。 隨著編譯器隨著時間的推移添加優化，編譯的輸出隨著時間的推移變得越來越小。

   請注意，CDN 也可以提供（和卸載）動態內容。 因此，沒有必要將您的 CDN 限制為靜態資產。 仔細檢查您的 CDN 是否執行壓縮和轉換（例如圖像優化和邊緣調整大小），它們是否為服務器工作者、A/B 測試以及邊緣端包含提供支持，這些包含組合頁面的靜態和動態部分在 CDN 的邊緣（即離用戶最近的服務器）和其他任務。 另外，檢查您的 CDN 是否支持 HTTP over QUIC (HTTP/3)。

   Katie Hempenius 撰寫了一份精彩的 CDN 指南，其中提供了有關如何選擇好的 CDN 、如何對其進行微調以及評估 CDN 時要記住的所有小事的見解。 通常，最好盡可能積極地緩存內容並啟用 CDN 性能功能，例如 Brotli、TLS 1.3、HTTP/2 和 HTTP/3。

   注意：根據 Patrick Meenan 和 Andy Davies 的研究，HTTP/2 優先級在許多 CDN 上被有效破壞，因此在選擇 CDN 時要小心。 Patrick 在他關於 HTTP/2 Prioritization 的演講中有更多細節（謝謝，Barry！ ）。

   

   選擇 CDN 時，您可以使用這些比較網站並詳細了解其功能：

   • CDN 比較，用於 Cloudfront、Aazure、KeyCDN、Fastly、Verizon、Stackpach、Akamai 等的 CDN 比較矩陣。
   • CDN Perf 通過每天收集和分析 3 億個測試來衡量 CDN 的查詢速度，所有結果均基於來自全球用戶的 RUM 數據。 另請檢查 DNS 性能比較和雲性能比較。
   • CDN Planet Guides 概述了特定主題的 CDN，例如 Serve Stale、Purge、Origin Shield、Prefetch 和 Compression。
   • Web Almanac：CDN 採用和使用提供有關頂級 CDN 提供商、他們的 RTT 和 TLS 管理、TLS 協商時間、HTTP/2 採用等的見解。 （不幸的是，數據僅來自 2019 年）。

目錄

1. 準備：計劃和指標
2. 設定切合實際的目標
3. 定義環境
4. 資產優化
5. 構建優化
6. 交付優化
7. 網絡、HTTP/2、HTTP/3
8. 測試和監控
9. 快速獲勝
10. 一切都在一頁上
11. 下載清單（PDF、Apple Pages、MS Word）
12. 訂閱我們的電子郵件通訊不要錯過下一個指南。