PRPL 是首字母缩写词,描述了用于加载和 更快速、更具互动性:
- 预加载延迟发现的资源。
- 尽快渲染初始路由。
- 预缓存剩余的资产。
- 延迟加载其他路由和非关键资产。
在本指南中,您将了解这些技巧如何搭配使用,但仍 以达到性能结果。
使用 Lighthouse 审核您的网页
运行 Lighthouse 以发现符合 PRPL 要求的改进机会 方法:
- 按 `Ctrl+Shift+J`(在 Mac 上,按 `Command+Option+J`)打开开发者工具。
- 点击 Lighthouse 标签页。
- 选中性能和渐进式 Web 应用复选框。
- 点击执行审核以生成报告。
如需了解详情,请参阅通过 Lighthouse 发现效果方面的优化建议。
预加载关键资源
如果解析了某个特定资源,并且 Lighthouse 显示以下失败的审核, 延迟提取:
预加载
是一种声明式提取请求,会告知浏览器请求原本无法被浏览器的预加载扫描器发现的资源,例如 background-image
属性引用的图片。将带有 rel="preload"
的 <link>
标记添加到 HTML 文档的标头中,从而预加载延迟发现的资源:
<link rel="preload" as="image" href="hero-image.jpg">
添加 <link rel="preload">
指令将发起对该资源的请求,并将其存储在缓存中。然后,浏览器就能在需要时检索到它。
如需详细了解如何预加载关键资源,请参阅 预加载关键资源指南。
<ph type="x-smartling-placeholder">尽快渲染初始路由
如果存在延迟 First Paint 的资源,Lighthouse 会显示警告, 当您的网站在屏幕上呈现像素时:
为了改进 First Paint,Lighthouse 建议您内联关键的 JavaScript 和
将其余调用
async
、
以及如何内嵌在首屏使用的关键 CSS这有助于提升效果
避免为了获取阻塞渲染的资源而往返服务器。
但是,从开发的角度来看,内联代码维护起来更困难,
不能由浏览器单独缓存。
改进 First Paint 的另一种方法是服务器端渲染 网页的 HTML。使用脚本执行脚本时, 提取、解析和执行不过,这可能会增加 但这可能会影响可交互时间, 或者从应用变为可交互状态并能够响应 用户输入。
没有一个能在您的 您应该只考虑内嵌样式和服务器端 为应用带来的好处超过适当的选择。您可以 请参阅以下资源,详细了解这两个概念。
![与 Service Worker 相关的请求/响应](https://web.developers.google.cn/static/articles/apply-instant-loading-with-prpl/image/requestsresponses-servi-9af9ccb5be804.png?authuser=9&hl=lt)
预缓存资源
通过充当代理,Service Worker 可以直接从缓存中提取资源 而不是服务器。这不仅允许用户使用您的 应用,但也有助于加快网页加载速度, 重复访问。
使用第三方库简化 Service Worker 的生成过程 除非你的缓存要求比库要复杂 提供。例如: Workbox 提供了一种 一组工具,可让您创建和维护 Service Worker, 缓存资产。如需详细了解 Service Worker 和离线可靠性, 请参阅可靠性学习路线中的 Service Worker 指南。
延迟加载
如果您通过网络发送过多数据,Lighthouse 会显示失败的审核。
这包括所有资源类型,但大型 JavaScript 载荷尤其严重 因此代价很高。 Lighthouse 也会适时提供警告。
发送一个较小的 JavaScript 有效负载,其中仅包含 用户最初加载您的应用,然后按需拆分整个 bundle 和延迟加载分块。
成功拆分 app bundle 后,预加载大小 重要资源(请参阅预加载关键资源指南)。 预加载可确保更快地提取和下载更重要的资源 。
除了按需拆分和加载不同的 JavaScript 块之外 Lighthouse 还提供针对延迟加载非关键图片的审核。
如果在网页上加载了很多图片,请暂缓所有非首屏图片,或者 加载网页时(请参阅使用 lazysizes 延迟加载图片)。
后续步骤
现在,您已经了解了 PRPL 模式背后的一些基本概念, 请继续阅读本节中的下一个指南以了解详情。 需要注意的是,并非所有技术 。如果您通过以下任一方式做出努力, 显著提升性能
- 预加载关键资源。
- 尽快渲染初始路由。
- 预缓存剩余的资产。
- 延迟加载其他路由和非关键资产。
您可以详细了解 PRPL 模式。