在低端设备或慢网络下构建 PWA 时，用 PRPL…

适用于构建 Progressive Web App，或需要优化初始路由加载、首屏渲染、预缓存与按需加载的 Web 应用。

适用场景

解决思路

1. 使用 HTTP/2 server push 或 preload hints 高效推送关键资源，减少客户端与服务器之间的往返次数和加载时间。
2. 尽快渲染初始路由，以实现快速首次绘制（first paint）并改善用户体验。
3. 使用 service workers 在后台预缓存频繁访问的路由资源，以最小化服务器请求并支持离线体验。
4. 懒加载（lazily load）不是立即需要的路由和资源。
5. 使用 app shell 架构作为主入口点。
6. 部署并采用 HTTP/2 而不是 HTTP/1.1：HTTP/2 将请求/响应拆成 frames，并通过单个 TCP 连接上的多个双向流发送多个请求/响应，避免 HTTP/1.1 的队头阻塞（head of line blocking）。
7. 利用 HTTP/2 server push 让服务器自动推送额外资源，而不是每次由客户端显式请求；推送的资源会存入浏览器缓存，解析入口文件发现这些资源时可直接从缓存获取。
8. 因为 server push 不是 HTTP cache aware，推送的资源下次访问不可用且需要重新请求，所以在初始加载后使用 service workers 缓存这些资源，避免客户端发送不必要的请求。
9. 识别早期关键资源，并在关键资源上添加 preload 资源提示，让浏览器比自然发现更早获取资源，从而优化当前路由关键资源的加载时间。
10. 控制推送/preload 的文件数量，避免推送过多文件：浏览器缓存有限，且可能浪费带宽请求客户端实际不需要的资源。
11. 在初始路由加载并完全渲染之前，不加载其他资源；PRPL 模式专注于优化初始加载。
12. 通过 code-splitting 将应用拆分成小而高性能的 bundle，使用户只加载当时需要的资源，并最大化可缓存性。
13. 确保请求的 bundle 包含当时所需的最小资源，并且可被浏览器缓存；避免因多个 bundle 共享资源导致浏览器难以识别共享部分而无法缓存这些资源。
14. 使用 app shell 作为主入口点：它是最小文件，包含大部分应用逻辑并在路由间共享，还包含应用 router，可动态请求必要资源。
15. 确保在初始路由于用户设备上可见之前，不请求或渲染其他资源。
16. 初始路由成功加载后，安装 service worker，在后台获取其他频繁访问路由的资源。
17. 利用后台获取让用户无延迟；当用户导航到已被 service worker 缓存的频繁访问路由时，让 service worker 从缓存取所需资源，而不是向服务器发请求。
18. 对不常访问的路由资源使用动态 import（dynamic import）。

适用边界 · 注意事项

• 当应用不需要优化初始加载、低端设备/慢网络性能或离线支持时，引入 PRPL 会增加不必要的复杂度。
• 当无法使用 service workers（如非 HTTPS 或不支持该 API 的环境）、无法控制服务器/构建流程启用 HTTP/2、preload 或 code-splitting 时，PRPL 的核心步骤难以落地。
• 当所有资源都必须立即可用、不能延迟加载或预缓存时，不适合采用懒加载与延后加载策略。