
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 还提供了对延迟加载非关键图像的审核。

如果你在网页上加载许多图像,请在加载页面时推迟所有折叠以下或设备视口之外的图像。