PRPL 模式下的应用即时加载
PRPL 是首字母缩略词，它描述一种模式，该模式用于使网页更快地加载并变得交互式：
- 推送（或预加载）最重要的资源。
- 尽快渲染初始路线。
- 预缓存剩余资源。
- 延迟加载其他路由和非关键资源。
在本指南中，了解这些技术如何融合在一起，但仍然可以独立使用以实现性能结果。
使用 Lighthouse 审计你的页面
运行 Lighthouse 以发现与 PRPL 技术保持一致的改进机会：
- 按
Control+Shift+J（或Command+Option+J在 Mac 上）按打开 DevTools。 - 单击 Lighthouse 选项卡。
- 选中 “性能和渐进式 Web 应用程序” 复选框。
- 单击运行审核以生成报告。
预加载关键资源
如果某些资源被解析并延迟获取，那么 Lighthouse 将显示以下失败的审核：
预加载是声明性的获取请求，它告诉浏览器尽快请求资源。通过在 HTML 文档的开头添加 <link> 标记 rel="preload" 来预加载关键资源：
<link rel="preload" as="style" href="css/style.css">
浏览器为资源设置了更合适的优先级，以便尝试尽早下载资源而不延迟window.onload事件。
尽快渲染初始路径
当某些资源延迟 First Paint（网站在屏幕上渲染像素的那一刻）时，Lighthouse 将发出警告：
为了改进 First Paint，Lighthouse 建议内嵌关键 JavaScript 并使用推迟其余部分 async，以及内嵌在上面使用的关键 CSS。通过消除往返服务器以获取渲染阻止资源的往返操作，可以提高性能。但是，从开发角度看，内联代码更难维护，并且无法由浏览器单独缓存。
改进 First Paint 的另一种方法是在服务器端呈现页面的初始 HTML。当脚本仍在获取，解析和执行时，这将立即向用户显示内容。但是，这会大大增加 HTML 文件的有效负载，这可能会损害 Time to Interactive，或者损害你的应用程序变为交互式并响应用户输入所花费的时间。
没有任何正确的解决方案可以减少应用程序中的 First Paint，并且只有在收益大于应用程序的权衡因素时，才应考虑内联样式和服务器端渲染。
预缓存资源
通过代理访问，服务工作人员可以直接从缓存中获取资源，而无需重复访问服务器。这不仅使用户可以在脱机时使用你的应用程序，还可以缩短重复访问时的页面加载时间。
除非你有比库所提供的更复杂的缓存要求，否则请使用第三方库来简化生成服务工作者的过程。例如， Workbox 提供了一系列工具，使你可以创建和维护服务工作者以缓存资源。
延迟加载
如果你通过网络发送太多数据，那么 Lighthouse 将显示审核失败。
这包括所有资源类型，但是大型 JavaScript 有效负载尤其昂贵，这是因为浏览器需要花费很长时间来解析和编译它们。 Lighthouse 还会在适当时为此提供警告。
要发送较小的 JavaScript 有效负载，其中仅包含用户最初加载应用程序时所需的代码，请按需拆分整个捆绑包和延迟加载块。
除了按需拆分和加载不同的 JavaScript 块外，Lighthouse 还提供了对延迟加载非关键图像的审核。
如果你在网页上加载许多图像，请在加载页面时推迟所有折叠以下或设备视口之外的图像。