关于 prpl
介绍用于优化 Web 应用加载的 PRPL 模式，涵盖关键资源推送、尽早渲染、预缓存和延迟加载。适合关注低端设备、慢速网络和关键渲染路径的开发者。
主要功能
- 01推送或预加载关键资源
- 02尽早渲染初始路由
- 03通过 Service Worker 预缓存
- 04延迟加载非关键路由和资源
- 05以应用外壳作为入口
适用场景
- 01优化慢速网络下的应用加载
- 02改善低端设备上的初始渲染
- 03为常用路由准备离线缓存
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/prpl确认已加载。
详细介绍
PRPL 模式
让我们的应用能够在全球范围内访问是一项挑战！我们必须确保应用在低端设备和互联网连接不佳的地区也能保持良好的性能。为了确保应用在条件不佳时也能尽可能高效地加载，我们可以使用 PRPL 模式。
适用场景
- 构建需要在低端设备和慢速网络上保持良好性能的应用时使用
- 这有助于优化 Web 应用的关键渲染路径
说明
- 使用 HTTP/2 服务端推送或预加载提示，高效地 推送 关键资源
- 尽快 渲染 初始路由，以实现快速首次绘制
- 使用 Service Worker 预缓存经常访问的路由，以支持离线使用
- 延迟加载 暂时不需要的路由和资源
- 使用应用外壳架构作为主要入口点
详情
PRPL 模式着重关注四项主要性能考量：
- 高效地 推送 关键资源，从而最大限度地减少与服务端的往返次数并缩短加载时间。
- 尽快 渲染 初始路由，提升用户体验
- 在后台 预缓存 经常访问的路由所需资源，以最大限度地减少向服务端发送的请求，并提供更好的离线体验
- 延迟加载 不常请求的路由或资源
访问网站时，我们首先必须向服务端发起请求以获取资源。入口点所指向的文件会由服务端返回，通常是应用的初始 HTML 文件！浏览器的 HTML 解析器一开始接收服务端发送的数据，就会立即开始解析。如果解析器发现还需要其他资源，例如样式表或脚本，就会向服务端发送另一个 HTTP 请求来获取这些资源！
反复请求资源并不理想，因为我们希望尽可能减少客户端与服务端之间的往返次数！
长期以来，我们一直使用 HTTP/1.1 在客户端与服务端之间进行通信。与 HTTP/1.1 相比，HTTP/2 引入了一些重大变化，让我们更容易优化客户端与服务端之间的消息交换。
HTTP/1.1 使用以换行符分隔的纯文本协议来传输请求和响应，而 HTTP/2 则将请求和响应拆分成更小的部分，称为帧。包含标头和正文的 HTTP 请求至少会拆分成两个帧：标头帧和数据帧！
HTTP/1.1 限制客户端与服务端之间最多建立 6 个 TCP 连接。在同一个 TCP 连接上发送新请求之前，必须先处理完前一个请求！如果前一个请求处理耗时过长，就会阻塞其他请求的发送。这种常见问题称为队头阻塞，可能会延长某些资源的加载时间！
HTTP/2 使用双向流，因此可以通过一个 TCP 连接承载多个双向流，在客户端与服务端之间传输多个请求帧和响应帧！
HTTP/2 通过允许在前一个请求处理完毕之前，先在同一个 TCP 连接上发送多个请求，解决了队头阻塞问题！
HTTP/2 还引入了一种更优化的数据获取方式，称为服务端推送。服务端无需每次都通过发送 HTTP 请求来显式获取资源，而是可以自动发送额外资源，也就是“推送”这些资源。
客户端收到额外资源后，这些资源会存储在浏览器缓存中。解析入口文件时发现这些资源后，浏览器可以快速从缓存中获取资源，而无需向服务端发送 HTTP 请求！ 虽然推送资源可以缩短获取额外资源所需的时间，但服务器推送无法识别 HTTP 缓存！下次访问网站时，我们将无法使用已推送的资源，因此必须重新请求。为了解决这个问题，PRPL 模式会在初次加载后使用 service workers 缓存这些资源，确保客户端不会发出不必要的请求。
作为网站的作者，我们通常知道哪些资源需要尽早获取，而浏览器只能尽力猜测。我们可以为关键资源添加 preload 资源提示，帮助浏览器！
告诉浏览器预加载某个资源，意味着希望浏览器比通常发现它的时间更早获取该资源！预加载是优化当前路由关键资源加载时间的绝佳方式。
虽然预加载资源是减少往返次数、优化加载时间的好方法，但推送过多文件可能有害。浏览器缓存空间有限，而且请求客户端实际上并不需要的资源可能会浪费带宽。
PRPL 模式专注于优化初次加载。在初始路由完全加载并渲染之前，不会加载其他资源！
我们可以通过将应用拆分为小型、高性能的代码包来实现这一点。这些代码包应让用户只在需要时加载所需资源，同时最大限度地提高缓存能力！
缓存较大的代码包可能会带来问题。多个代码包可能包含相同的资源。浏览器很难识别哪些代码包片段被多个路由共享，因此无法缓存这些资源。缓存资源有助于减少与服务端的往返次数，并让我们的应用支持离线使用！
使用 PRPL 模式时，我们需要确保请求的代码包只包含当前所需的最少资源，并且能够被浏览器缓存。
PRPL 模式通常使用应用外壳作为主要入口点。应用外壳是一个最小化文件，包含应用的大部分逻辑，并由多个路由共享！它还包含应用的路由器，可以动态请求所需资源。
PRPL 模式确保在初始路由显示在用户设备上之前，不会请求或渲染其他资源。初始路由成功加载后，可以安装 service worker，在后台获取其他常用路由的资源！
由于这些数据是在后台获取的，用户不会感受到任何延迟。如果用户想要导航到已由 service worker 缓存的常用路由，service worker 可以直接从缓存中快速获取所需资源，而不必向服务端发送请求。
不太常用的路由资源可以动态导入。