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 上花费的时间比其他网站多（当然这并不一定说 React 在 CPU 上比 Vue.js 更昂贵）。

   根据 Tim 的说法，有一件事是显而易见的：“如果您使用框架来构建您的网站，那么您就需要在初始性能方面进行权衡——即使在最好的情况下也是如此。”

1. 评估框架和依赖项。
   现在，并不是每个项目都需要一个框架，也不是单页应用程序的每个页面都需要加载一个框架。 在 Netflix 的案例中，“从客户端移除 React、多个库和相应的应用程序代码将 JavaScript 的总量减少了超过 200KB，导致 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. 订阅我们的电子邮件通讯不要错过下一个指南。