使应用程序在全球范围内可访问可能是一个挑战！
我们必须确保应用程序在低端设备和互联网连接较差的地区运行良好。
为了确保应用程序能够在困难的条件下尽可能高效地加载，可以使用 PRPL 模式。
PRPL 模式侧重于四个主要的性能考虑：
-
有效地推送关键资源，从而最大限度地减少到服务器的往返次数并减少加载时间。
-
尽快渲染初始路线，提升用户体验
-
为经常访问的路由在后台预先缓存资产，以最大限度地减少对服务器的请求量并实现更好的离线体验
-
延迟加载请求不频繁的路线或资产
当我们想要访问一个网站时，首先必须向服务器发出请求才能获取这些资源。
入口点指向的文件从服务器返回，通常是应用程序的初始 HTML 文件！
浏览器的 HTML 解析器一开始从服务器接收数据，就会开始解析这些数据。
如果解析器发现需要更多资源，例如样式表或脚本，则会向服务器发送另一个 HTTP 请求以获取这些资源！
必须重复请求资源并不是最优的，因为我们正在尝试最小化客户端和服务器之间的往返次数！
HTTP
长期以来，我们使用 HTTP/1.1 来在客户端和服务器之间进行通信。
尽管与 HTTP/1.0 相比，HTTP/1.1 引入了许多改进，例如能够在使用 keep-alive 标头发送新 HTTP 请求之前保持客户端和服务器之间的 TCP 连接处于活动状态，但仍然存在一些问题 待解决！
与 HTTP/1.1 相比，HTTP/2 引入了一些重大变化，这使我们可以更轻松地优化客户端和服务器之间的消息交换。
HTTP/1.1 在请求和响应中使用换行符分隔的纯文本协议，HTTP/2 将请求和响应拆分为称为帧的更小的部分。
包含标头和正文字段的 HTTP 请求至少被拆分为两个帧：标头帧和数据帧！
HTTP/1.1 在客户端和服务器之间最多有 6 个 TCP 连接。
在通过相同的 TCP 连接发送新请求之前，必须先解决先前的请求！
如果前一个请求需要很长时间才能解决，则此请求会阻止发送其他请求。
这个常见的问题叫做 head of line 阻塞，会增加某些资源的加载时间！
HTTP/2 使用双向流，这使得单个 TCP 连接包含多个双向流成为可能，可以在客户端和服务器之间携带多个请求和响应帧！
一旦服务器收到该特定请求的所有请求帧，它就会重新组合它们并生成响应帧。
这些响应帧被发送回客户端，客户端重新组合它们。由于流是双向的，可以通过同一个流发送请求和响应帧。
HTTP/2 通过允许在前一个请求解决之前在同一个 TCP 连接上发送多个请求来解决行首阻塞！
HTTP 2 服务器推送
HTTP/2 还引入了一种更优化的数据获取方式，称为服务器推送。
不必每次都通过发送 HTTP 请求来明确请求资源，服务器可以通过“推送”这些资源来自动发送额外的资源。
客户端收到附加资源后，这些资源将存储在浏览器缓存中。
当在解析入口文件时发现资源时，浏览器可以快速从缓存中获取资源，而不必向服务器发出 HTTP 请求！
尽管推送资源减少了接收额外资源的时间，但服务器推送并不支持 HTTP 缓存！
下次访问该网站时，我们将无法使用推送的资源，必须再次请求。
为了解决这个问题，PRPL 模式在初始加载后使用服务工作者来缓存这些资源，以确保客户端不会发出不必要的请求。
关键资源预加载
作为网站的作者，我们通常知道哪些资源是早期获取的关键，而浏览器会尽力猜测这一点。
幸运的是，可以通过向关键资源添加预加载资源提示来帮助浏览器！
通过告诉浏览器想要预加载某个资源，就是在告诉浏览器您希望比浏览器发现它更快地获取它！
预加载是优化加载对当前路由至关重要的资源所需时间的好方法。
尽管预加载资源是减少往返次数和优化加载时间的好方法，但推送太多文件可能有害。
浏览器的缓存是有限的，可能会通过请求客户端实际上不需要的资源来不必要地使用带宽。
PRPL 模式
PRPL 模式侧重于优化初始负载。 在初始路由完全加载和呈现之前，不会加载其他资源！
可以通过将应用程序代码拆分成小的、高性能的包来实现这一点。
这些捆绑包应该使用户可以仅在需要时加载他们需要的资源，同时最大限度地提高可缓存性！
缓存较大的包可能是一个问题。 可能发生多个包共享相同的资源。
浏览器很难识别 bundle 的哪些部分在多个路由之间共享，因此无法缓存这些资源。
缓存资源对于减少到服务器的往返次数很重要，并使我们的应用程序离线友好！
在使用 PRPL 模式时，需要确保请求的包包含当时所需的最少资源，并且可以被浏览器缓存。
在某些情况下，这可能意味着根本没有捆绑会更高效，可以简单地使用未捆绑的模块！
通过将浏览器和服务器配置为支持 HTTP/2 推送并有效地缓存资源，可以轻松地模拟通过捆绑应用程序来动态请求最少资源的好处。
对于不支持 HTTP/2 服务器推送的浏览器，可以创建一个经过优化的构建，以最大限度地减少往返次数。
客户端不必知道它接收的是捆绑资源还是非捆绑资源：服务器为每个浏览器提供适当的构建。
PRPL 模式通常使用 app shell 作为其主要入口点，这是一个包含大部分应用程序逻辑并在路由之间共享的最小文件！
它还包含应用程序的路由器，它可以动态请求必要的资源。
PRPL 模式确保在初始路由在用户设备上可见之前不会请求或呈现其他资源。
一旦成功加载了初始路由，就可以安装服务器工作者，以便在后台为其他经常访问的路由获取资源！
由于这些数据是在后台获取的，因此用户不会遇到任何延迟。
如果用户想要导航到 Service Worker 缓存的经常访问的路由，
Service Worker 可以快速从缓存中获取所需的资源，而不必向服务器发送请求。
不经常访问的路由资源可以动态导入。
知识点
-
HTTP
-
PRPL