一、前言

日志是一种依照工夫程序Prerender（预渲染），是用户在关上网页之前提前将网页中资源加载并执行解析渲染工作，使网页真正被关上时以最快的速度出现进去，现实状态下关上已预渲染的页面简直是即时展示的。

Chromium在过来曾经反对过Prerender（Prerender1.0，应用工夫在2011～2018），其API应用办法如下，针对单个链接做预渲染，因为此能力的应用须要耗费较高的设施资源，实用性不太大，导致没有失去广泛应用，故逐步被弃用。而此API后续利用在NoState Prefetch中，NSP机制只对指标网页中的要害资源进行预加载，并不会执行后续的渲染工作，也不会执行JS，即通过缩小资源加载耗时以进步页面性能，但做不到预渲染及时展示页面的成果。

<link rel="prerender" href="/next-page/">

Chromium从M94开始将Prerender机制（Prerender2.0）从新引入。Prerender2.0是全新的预渲染技术，此版本着重于进步预渲染页面的准确性并缩小执行预渲染所需的设施资源量，缩短页面加载工夫、改善用户体验并升高设施功耗。Prerender2.0比Prerender1.0更加灵便、智能和轻便，能够更无效地进步页面加载速度。

丨1.1 多页面架构（MPArch）

MPArch（Multiple Page Architecture）多页面架构，此架构中采纳了单WebContents模型，实现一个WebContent中治理多个page（可见/不可见），WebContents和Page之间不是一一对应关系。单WebContents模型十分实用BF Cache和Prerender等须要在同一选项卡中反对多个页面的性能。

Prerender2.0建设在MPArch之上，即应用了单WebContents多page模型。而Prerender1.0时还没有反对此能力，而是每预渲染一个页面均创立新的WebContent，每个WebContent仅对应一个预渲染页面，即Prerender1.0采纳的是多WebContents模型。

图片来源于chromium

可见Prerender机制在应用单WebContents模型绝对于多WebContents模型在内存的应用上有着显著的劣势，这应该是Prerender2.0比Prerender1.0轻便之处。

二、Prerender2.0应用及成果

丨2.1 能力应用

应用Prerender2.0机制须要应用新增的Speculation Rules API(https://github.com/WICG/nav-s...)，此API可同时反对触发Prefetch、NSP、Prerender机制。

查看浏览器是否反对此API。

HTMLScriptElement.supports('speculationrules')

API应用示例如下：

<script type="speculationrules">        {          "prerender": [            {"source": "list",             "urls": ["next.html", "./PrefetchTestNew.html"]}          ],          "prefetch": [            {"source": "list",             "urls": ["next.html"],             "requires": ["anonymous-client-ip-when-cross-origin"]}          ],          "prefetch_with_subresources": [            {"source": "list",             "urls": ["next.html"],             "requires": ["anonymous-client-ip-when-cross-origin"]}          ]        }</script>

API中要害

未持续应用<link rel=prerender>的起因如下：

  1. 以后曾经由NoState Prefetch机制应用，若强制改为Prerender机制，将不合乎已应用此API站点的预期（网站并不想对应用此API的URL进行预渲染），且耗费资源大幅度减少，导致网站解体的危险。
  2. 规定可塑性较差，局部要求无奈通过此规定限度，如Speculation Rules API中的requires参数含意难以在此规定中体现，且无奈同时对多个站点预处理。
  3. 因为Speculation Rules API的灵活性较好，Chromium预言此API将逐渐代替规定，成为开发者应用较多的API。

应用了以上API对页面发动Prerender后，如何晓得用户关上了已Prerender的页面，获取形式如下：

  1. 当activationStart大于0时便示意prerender页面复用胜利。
  2. 监听'prerenderingchange'事件。
// 形式1let activationStart = performance.getEntriesByType('navigation')[0].activationStart;// 形式2let wasActivated = false;document.addEventListener('prerenderingchange', (event) => {  wasActivated = true;});

丨2.2 应用成果

应用Chromium提供的视频示例，不应用Prerender能力能够显著的看到页面中内容从0到1展现的过程，而应用Prerender后页面简直是即时展现的。成果比照非常明显。

三、实现流程（基于M97）

丨3.1 解析Speculation Rules API

解析到HTML中的Speculation Rules API后的流程如下：

流程如下：

  1. 解析HTML中蕴含ScriptType为kSpeculationRules的JS内容后，开始对原数据进行JSON解析，匹配出无效内容，包含SpeculationAction（kPrefetch、kPrefetchWithSubresources、kPrerender）、SpeculationRule（urls、requires\_anonymous\_client\_ip\_when\_cross\_origin）；
  2. 若SpeculationAction为kPrerender时，开始判断是否合乎发动prerender的条件（判断条件如下），若合乎则开始执行StartPrerendering；
  • 发动prerender的页面需可见
  • 以后设施平台的内存空间短缺（限度低端机开启Prerender机制）
  • 不容许发动跨域prerender（即prerender URL需和发动prerender的页面同源）（Chromium示意预计于M109反对跨域prerender）
  • 不能反复发动prerender

  • 一个页面中不能发动多个prerender

PrerenderHost是在Browser侧治理着单个预渲染页面的类，其对应着PrerenderHost::PageHolder，在PageHolder中创立预渲染的FrameTree，而PrerenderHostRegistry治理所有的PrerenderHost。可见一个WebContents对应多个FrameTree。

丨3.2 预渲染流程

每个预渲染页面均以PrerenderHost::StartPrerendering()开始，而后执行到NavigationRequset中BeginNavigation办法，前面的逻辑均和失常页面加载流程统一。

  1. 在Browser线程中判断跳转页面是否须要网络层解决，若须要网络层解决，则走网络申请逻辑，实现资源申请并返回主文档首包（也有跳转不须要网络层解决，比方同Document跳转）。无论是否走网络层逻辑，最终都会走到CommitNavigation办法，CommitNavigation就是Browser线程向Render线程提交跳转的入口。
  2. CommitNavigation至Render线程后将创立Document和DocumentLoader等对象，而DocumentLoader是用于解决主文档内容加载实现后回调告诉。待收到主文档数据后开始解析、渲染流程。

预渲染实现后的页面将以FrameTree的构造存在，FrameTree由PrerenderHost持有。每个预渲染页面对应一个PrerenderHost对象，所有的PrerenderHost存储在Map中以frame\_tree\_node\_id作为key，Map以成员变量的模式保留在PrerenderHostRegistry中。此时预渲染的Page对于用户是不可见的。

丨3.3 页面加载流程

点击链接进入已预渲染的页面，仍旧是执行到NavigationRequset中BeginNavigation办法。

  1. 执行BeginNavigation办法时会到PrerenderHostRegistry类中寄存PrerenderHost的Map中查找是否有符合要求的PrerenderHost对象，匹配规定是查看以后navigationRequest中的URL与PrerenderHost中的URL是否统一，统一则匹配胜利，同时返回frame\_tree\_node\_id。找到符合条件的frame\_tree\_node\_id后开始操作将prerenderPage的状态切换为active。
  2. 后续仍旧须要至网络库中申请主文档首包，用于查看页面是否可用，并对申请头进行验证，确保可复用的预渲染页面与须要加载的页面的RequestHeaders和ResponseHeaders内容统一。
  3. 以上验证均通过后，便可执行CommitNavigation，针对BFCache和Prerender页面都是先找到stored\_page，并将stored\_page的状态切换为active，以展现给用户。

找出符合条件的stored\_page，将此页面展示进去，并将上个页面暗藏存储至BFCache中。如下图所示。

四、利用场景

因为预渲染页面对于设施的资源耗费较大，是个须要审慎应用的机制能力，若胡作非为的应用此能力，不仅无奈进步用户的浏览体验，还会耗尽用户的贵重资源，可能带来卡顿、解体等负向影响。Chromium举荐用法中示意当用户加载某些页面的可能性很高时才举荐应用Prerender机制，此时可将Prerender机制带来的正向收益最大化。

丨4.1 Chromium

Chromium将预测技术与Prerender2.0机制联合应用，利用预测技术进步预渲染页面的准确性。通过chrome://predictors页面可看出Chromium对用户行为的预测，如下图。

绿色示意有足够信念触发预渲染。以上示例可看出，当用户在输入框中输出"b"/"ba"/"bai"字符后chromium将对"https://www.baidu.com/"站点发动预渲染，因为通过屡次统计有足够的信念认为用户将进入指标站点。

Chromium会依据用户输出和抉择一直的更新预测后果。

  • 当置信度>50%(图中黄色)，Chromium会发动预链接
  • 当置信度>80%(图中绿色)，Chromium会发动预渲染

同时Chromium会将预测的后果出现在Sug选项栏中，辅助用户进入指标站点。

进入指标站点后通过"performance.getEntriesByType('navigation')[0].activationStart"查看页面是否通过预渲染出现的，依据activationStart大于0可确定此页面已预渲染胜利。

丨4.2 开发者

对于搜寻类浏览器可参考Chromium思路，定制适合的预测器并联合Prerender2.0机制应用，用于晋升搜寻后果页的上屏性能，优化用户体验。

对于网站开发者而言，能够联合本身站点状况应用预渲染技术

  • 对于明确站点中的某些页面是大部分用户会浏览的，便可对这些站点进行预渲染，此场景可通过动态形式将预渲染API写入HTML中。
  • 也可针对不同用户应用不同策略，依据用户行为通过JS动静插入须要预渲染API。

网站掂量应用预渲染能力是否切当，可减少指标查看预渲染成果。次要看两个指标，一个是发动预渲染页面数量，另一个是用户实在加载已预渲染的页面数量（上文中提及的获取形式），两个指标的比照可估算出命中率。网站可调整预渲染策略以放弃高命中率。

五、总结

本文次要介绍了Prerender机制的倒退过程和现状，并对Prerender2.0技术进行介绍。其中重点介绍了Prerender2.0技术的应用、实现流程和利用场景。百度APP是基于Chromium M97，此版本中Prerender2.0机制还在初级阶段，目前为止Chromium还在对Prerender2.0技术进行欠缺，故文档中内容可能和最新计划有些许差别。前期咱们将继续关注Prerender2.0技术倒退，挖掘其利用于业务的可行场景，继续优化页面上屏性能，晋升用户体验。

——END——

参考资料：

[1] Prerender开发者文档：

https://developer.chrome.com/...

[2] Prerender官网文档：

https://docs.google.com/docum...\_cRAjUeE-bqLL0bslL\_zKqiNeCzNom\_w/edit

[3] 多页面架构文档：

https://docs.google.com/docum...

举荐浏览：

百度工程师浅谈分布式日志

百度工程师带你理解Module Federation

巧用Golang泛型，简化代码编写

Go语言DDD实战高级篇

Diffie-Hellman密钥协商算法探索

贴吧低代码高性能规定引擎设计