PRPL 模式下的应用即时加载

PRPL 模式下的应用即时加载

PRPL 是首字母缩略词,它描述一种模式,该模式用于使网页更快地加载并变得交互式:

  • 推送(或预加载)最重要的资源。
  • 尽快渲染初始路线。
  • 预缓存剩余资源。
  • 延迟加载其他路由和非关键资源。

在本指南中,了解这些技术如何融合在一起,但仍然可以独立使用以实现性能结果。

使用 Lighthouse 审计你的页面

运行 Lighthouse 以发现与 PRPL 技术保持一致的改进机会:

  1. Control+Shift+J(或Command+Option+J在 Mac 上)按打开 DevTools。
  2. 单击 Lighthouse 选项卡。
  3. 选中 “性能渐进式 Web 应用程序” 复选框。
  4. 单击运行审核以生成报告。

预加载关键资源

如果某些资源被解析并延迟获取,那么 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 加载时间过长

要发送较小的 JavaScript 有效负载,其中仅包含用户最初加载应用程序时所需的代码,请按需拆分整个捆绑包和延迟加载块。

除了按需拆分和加载不同的 JavaScript 块外,Lighthouse 还提供了对延迟加载非关键图像的审核。

延迟加载屏幕外的图像
延迟加载屏幕外的图像

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