PRPL 是一个首字母缩略词，它描述了一种用于使网页加载更快并更快地实现交互的模式
- 预加载 后期发现的资源。
- 渲染 尽快渲染初始路由。
- 预缓存 剩余资源。
- 延迟加载 其他路由和非关键资源。
在本指南中，了解这些技术如何协同工作，但仍可独立使用以实现性能结果。
使用 Lighthouse 审核您的页面
运行 Lighthouse 以识别与 PRPL 技术一致的改进机会
- 按 `Control+Shift+J`（或 Mac 上的 `Command+Option+J`）打开 DevTools。
- 点击 Lighthouse 选项卡。
- 选择 性能 和 渐进式 Web 应用 复选框。
- 点击 运行审核 以生成报告。
有关更多信息，请参阅 使用 Lighthouse 发现性能优化机会。
预加载关键资源
如果某个资源解析和获取较晚，Lighthouse 会显示以下失败的审核
Preload 是一种声明式提取请求，它告诉浏览器请求浏览器 预加载扫描器 无法发现的资源，例如 background-image 属性 引用的图像。通过将带有 rel="preload" 的 <link> 标记添加到 HTML 文档的头部，来预加载后期发现的资源
<link rel="preload" as="image" href="hero-image.jpg">
添加 <link rel="preload"> 指令将启动对该资源的请求并将其存储在缓存中。然后，浏览器可以在需要时检索它。
有关预加载关键资源的更多信息，请参阅 预加载关键资源 指南。
尽快渲染初始路由
如果存在延迟 首次绘制（您的站点将像素渲染到屏幕上的时刻）的资源，Lighthouse 会发出警告
为了改进首次绘制，Lighthouse 建议内联关键 JavaScript 并使用 async 推迟其余 JavaScript，以及内联首屏内容的关键 CSS。这通过消除往返服务器以获取渲染阻塞资源来提高性能。但是，从开发角度来看，内联代码更难维护，并且无法被浏览器单独缓存。
改进首次绘制的另一种方法是服务器端渲染页面的初始 HTML。这会在脚本仍在提取、解析和执行时立即向用户显示内容。但是，这会显着增加 HTML 文件的大小，这可能会损害 可交互时间，即可交互时间，或您的应用程序变得可交互并可以响应用户输入所需的时间。
减少应用程序中首次绘制时间没有唯一的正确解决方案，您应该仅在收益超过应用程序的权衡时才考虑内联样式和服务器端渲染。您可以使用以下资源了解有关这两个概念的更多信息。
预缓存资源
通过充当代理，Service Worker 可以直接从缓存而不是服务器获取资源，以便重复访问。这不仅允许用户在离线时使用您的应用程序，而且还可以在重复访问时加快页面加载时间。
使用第三方库来简化 Service Worker 的生成过程，除非您的缓存需求比库可以提供的更复杂。例如，Workbox 提供了一系列工具，使您可以创建和维护 Service Worker 以缓存资源。有关 Service Worker 和离线可靠性的更多信息，请参阅可靠性学习路径中的 Service Worker 指南。
延迟加载
如果您通过网络发送过多数据，Lighthouse 会显示审核失败。
这包括所有资源类型，但大型 JavaScript 有效负载尤其昂贵，因为浏览器需要花费时间来解析和编译它们。Lighthouse 也会在适当时为此发出警告。
为了发送较小的 JavaScript 有效负载，其中仅包含用户最初加载应用程序时所需的代码，请拆分整个捆绑包并按需 延迟加载 代码块。
一旦您设法拆分了捆绑包，请预加载更重要的代码块（请参阅 预加载关键资源 指南）。预加载确保浏览器更快地提取和下载更重要的资源。
除了拆分和按需加载不同的 JavaScript 代码块外，Lighthouse 还为延迟加载非关键图像提供了审核。
如果您在网页上加载了许多图像，请在页面加载时延迟加载所有首屏下方或设备视口之外的图像（请参阅 使用 lazysizes 延迟加载图像）。
后续步骤
现在您已经了解了 PRPL 模式背后的一些基本概念，请继续阅读本节中的下一篇指南以了解更多信息。重要的是要记住，并非所有技术都需要一起应用。在以下任何方面做出的任何努力都将提供明显的性能改进。
- 预加载 关键资源。
- 渲染 尽快渲染初始路由。
- 预缓存 剩余资源。
- 延迟加载 其他路由和非关键资源。
您可以阅读更多关于 PRPL 模式的信息。