提高前端性能，前端神器

概括

H5页面通常给人的印象是开发成本较低、迭代速度较快，但用户体验较差。用户最明显的体验问题之一是首屏速度。 H5页面上的所有资源都必须从互联网上实时下载，因此提高这些资源的加载速度将显着提高初始屏幕速度。这种提前向应用程序下发资源，并在打开H5页面时利用预加载的资源来加速访问的技术通常被称为“离线打包”。 B站的线下打包技术方案与大多数互联网公司实现的方案底层逻辑一致，都实现了基础资源投放和拦截匹配机制。不过我们也在此基础上做了一些创新，比如页面快照技术、AB实验能力等。我们还做了很多优化，包括使用扫码调试降低调试成本、更快的版本收敛、有计划的分阶段发布等。目前，我们的离线包装技术已融入12个业务领域的183个项目，并在公司内部广泛应用。

页面加载速度瓶颈分析

如果使用该工具分析一个典型的H5活动页面（2024纪实开机周），你会发现页面速度瓶颈主要在以下几个方面： HTML请求通常包括SSR（服务器端渲染）和CSR（客户端渲染）页面。 SSR受服务器负载、页面复杂度和网络拓扑的影响，但首字节时间相对较慢，但浏览器引擎在收到HTML响应后立即开始解析和渲染，初始屏幕时间相对于SSR会有优势。企业社会责任。 CSR的优点是可以使用位于不同位置的CDN服务节点轻松加速，并且可以缓存固定时间段，从而实现快速到达首字节的时间。但是，所有页面结构都必须是JS。如果它在生成之前运行，则会显着减慢屏幕时间。 CSR页面的响应时间通常为10ms到50ms左右，SSR页面的响应时间通常为50ms到几百毫秒。 SSR 页面需要服务器花费大量时间来渲染。之前几个案例的演示结果表明，中低端机型采用SSR较离线包的首屏提升明显。高端型号的屏幕比SSR 更好。原因是在离线包中渲染页面是一个纯粹的CPU 密集型任务，并且响应速度比SSR 更快，而SSR 必须排队等待处理。服务器端。

代码工程：前端工程生成的文件。在这种情况下，您可以通过枚举每个输出文件、删除太大或不经常使用的文件以及添加需要加载的任何其他在线资源来打包和发布在线爬网。其他来源无法控制。例如，低代码平台生成的页面。在这种情况下，我们使用模拟的浏览器环境来捕获实际请求的资源列表，根据用户定义的规则删除一些文件，然后打包最终的打包目录即可发布。该目录可能包含以下内容：

config.json用于描述客户端需要拦截的URL列表、需要拦截的一些基本信息以及资源映射表的HTML入口文件。客户端根据config.json中的描述找到这个入口文件，并传递给客户端。当你将此文件和其他资源文件（CSS、JS、图片、字体、SVG等）加载到Web视图中时，这些资源在页面运行时发起请求，被客户端查表拦截，并添加到Web中视图将被返回。典型的代码输出目录如图所示：

示例config.json：

离线包裹递送机制

离线包裹递送依赖于Fawkes的ModManager（统一客户端平台）。这有助于在下载过程中集成调度和控制CPU、带宽使用和存储空间使用。 ModManager是客户端资源统一下发通道，大部分需要动态下发的资源都通过ModManager统一管理和下发，可以实现增量包生成、资源错峰下发、版本热推下发等功能。例如。网络环境限制等诸多特点。重用这一基本功能集可以节省建立额外一组交付链接的成本，并且可以更轻松地控制CDN 流量和客户端存储空间使用情况。线下打包平台有定期发布、分阶段发布、计划发布三种发布模式。这些发布模式的实施方案有所不同：

定期发布

代码包直接在线发布，所有符合限制（版本、时间、灰度等政策）的冷启动应用用户将按照资源包优先级逐步下载新版本。如果用户本地没有该软件包的旧版本，则会下载完整的软件包。如果已经存在较新的旧版本，则会下载增量包。然而，即使有了增量更新功能，高峰期的发布也需要额外的批准，因为定期发布会给用户高峰期的带宽带来额外的负担。

如图所示，典型的发布后，由于资源包下载，流量会立即出现峰值，然后随着覆盖范围的增加慢慢下降，直到大多数用户完成更新。因此，除了常规发布之外，还需要更智能的发布策略来降低成本。

交错释放

错峰发布模式设置离线包激活延迟1至3天，在此期间下载离线资源包，以利用流量低谷。这样可以有效利用CDN的闲置流量，节省成本。错峰发布适用于首次发布的软件包，可以利用空闲流量来缓解用户首次完整下载的流量压力。后续版本发布时，您可以根据您的在线时间需求灵活使用发布模式。

预约释放

离线包装实践的一些问题包括：直播业务中的大部分页面都会接入线下套餐，但有些页面往往需要在晚间高峰时段上线，但线下套餐可能会非常昂贵。这是为了在带宽成本高峰期间使其上线。如何保证及时发布，同时也考虑到离线包的情况？我们设计了定时发布功能。预定发布允许您设置特定的非高峰时间点在接下来的24 小时内发布。配置完成后，可以将当前在线使用的包版本设置为立即过期，用户可以降级并请求在线页面访问新版本的内容。新版本将在指定时间发布，之后完成更新的用户将可以正常使用加速功能。预定发布适合需要在高峰期发布新功能且不介意短期性能下降的公司。这意味着您可以实现足够快的发布速度并避免高带宽成本。缺点是，在此期间，用户访问页面的速度可能会受到影响，在线服务可能会出现突然的负载。

资源匹配机制

如图所示，当Webview加载URL时，执行以下步骤：

检查当前是否有离线包可用。这包括检查全局开关、URL 开关和协议匹配。如果当前页面的URL命中了离线包，请检查本地包版本是否在接口发布的版本白名单中。如果存在则进入离线包加载流程。否则，在线请求将正常路由。当进入离线包加载流程时，容器的https拦截功能被启用，实例内的所有资源请求都会被拦截并检查是否有对应的离线资源。同时，离线HTML 资源开始加载。一旦HTML 加载完毕，Webview 就开始请求JS 和图像等资源。然后，请求拦截器识别资源映射表中的这些URL，并使用本地文件系统中的资源返回它们。对于不在列表中的文件，正常检索并返回在线资源。还有一种特殊的资源类型称为公共资源。该类型的资源位于单独的公共包中，当页面到达离线包时，如果URL满足公共资源命名要求，则会尝试加载本地资源。在本地资源加载失败的所有情况下，系统都会恢复请求在线资源以确保至少功能可用。

版本控制和快速回滚策略

由于离线打包主动向客户端投放资源，不可避免地会带来更新时效性问题。在更新时效性方面，我之前在使用ModManager时遇到了以下问题：

使用原始空壳HTML 作为基础，在当前页面的#app 节点中插入结构。如果使用rem 布局，请添加rem fontSize。使用统一的HTML 来配置快照。当应用程序代码意识到当前正在使用快照时，它首先生成完整的dom结构，然后替换dom结构的内容。目前的#app。每个应用程序通过独立处理敏感数据节点中的数据，本质上可以解决上述问题。 HTML快照的技术基础是基于这样的假设：页面的DOM结构与其数据之间存在一一对应的关系，因此相同的数据输入无论渲染多少次都应该输出相同的DOM结构。只要预先缓存了DOM 结构，下次访问时就会先出现旧页面，然后可以无缝切换到新页面。虽然这种假设在大多数情况下都是正确的，但对于实际发生什么问题仍然缺乏业务实践，需要生产应用后相对可靠的最佳实践。这方面的实践预计今年开始，欢迎大家继续关注与合作。

AB实验

离线包会拦截入口HTML文件请求，因此如果页面经过重大修改并且需要进行页面级AB实验，则无法在服务器端做出卸载决策。为此，我们利用URL重写功能，使同一个URL对应不同用户端的两个不同的离线包。一般流程是：

每当Hot Start请求离线包控制接口时，接口都会计算出用户对应的AB实验组，并根据对应组下发URL重写规则，并将地址更改为离线包Rewrite对应版本的URL。当客户端打开页面时，根据映射表将URL重新映射为新的URL，并根据参数要求添加分组结果参数。最后根据修改后的URL打开页面。上述方案可以实现页面的AB功能，但不能只上报组条目数据，因为AB分流决策与页面打开时序不同。实际访问页面的用户数据可能会被上报，影响部分数据的恢复。

上图展示了新旧版本配置的差异。使用两个不同的URL可以让你容纳两个不同的离线包，让你实现AB功能而不影响离线包本身的设计。

适用场景及限制

虽然离线包提供的一些核心功能可以有效提升页面的首屏速度，但由于技术实现和架构方面的原因，仍然存在一些限制。有些场景会失败，有些场景需要保留在线访问功能。离线功能将暂时被禁用，并且将请求在线页面。接入离线包的企业必须确保只能作为加速方式，而不能作为最终的部署目标。失败场景包括：应用版本过低、尚未更新到可用版本的用户（新下载的应用用户或随着时间的推移活跃度较低的用户）、计划发布过程中业务触发的紧急下线或临时禁用、上线的复杂性。离线包的访问量增加。最后，上线前必须完成离线包的功能验证，离线包的发布必须在在线页面上线后进行操作。这增加了一些在线复杂性。虽然离线包资源预加载和界面预加载功能已经比较成熟，通常不会带来额外的问题，但还是要注意自测。通过将线下包发布流程整合到公司前端统一发布平台，解决了线上环节复杂的问题。产生额外的带宽成本虽然所有在线发布的离线套餐都会发送到大多数用户的手机上，但许多用户可能并不是该服务的目标受众。同时，交付过程还会产生额外的带宽成本，尤其是在高峰时段上线时。目前无法限制带宽使用。未来我们可能会根据情况使用云包或者其他方式来优化资源交付的准确性。目前，在使用https拦截功能时，Webview本身的限制是由于IOS系统的一些bug，需要特别注意以下两个问题：

不要直接在离线包页面发起包含发布数据或照片的发布请求。如果需要，您可以根据JSAPI 请求使用您公司的NPM 包。对于IOS离线打包，使用history.push。向左滑动可退出整个WebView 容器，而不是返回上一页。目前没有技术解决方案，只能使用capability.openScheme开启一个新的容器来替代上面的。综上所述，哪些业务适合接入线下套餐？线下套餐通常适合以下类型的业务：

有特定的用户群，比如每天超过5万PV的企业（不是严格要求）。这主要是出于资源利用的考虑。短时间内有大量用户访问的活动页面，或者与收入相关或以速度为导向的业务的业务流程页面，对于相对稳定且变化不大的业务很有用。

离线目的地在哪里？

当我们主动在用户手机上缓存越来越多的资源，以消除网络IO最大的速度瓶颈时，我们发现与客户端接口业务的差距并不那么大。这种格式介于原生和H5 之间，牺牲了一些发布便利性，但提供了更快的加载速度。承载H5的webview本身无法更改，并且必须忍受webview带来的性能问题，但同样重要的是要注意，如果你将页面优化到极致，你的用户将无法真正分辨出哪些页面不同。 我很感兴趣。原生通过加载速度实现，哪些页面已经实现了H5？未来我们计划在部分页面上尝试这样的速度优化策略。

代码本身所有资源都是离线的，允许通过脚本标签离线操作代码引入的第三方库。第三方库的公共包通过离线打包平台自动管理。此外，第三方库的公共包会自动更新和自动发布。通过网络接口数据缓存和stale-while-revalidate策略的结合，确保页面自身的代码资源不再需要加载。页面主动使用上次缓存的界面数据，并在界面预加载数据后替换为最新的数据。 （类似于进入客户端页面后，先显示旧数据和加载标记，然后再更新新数据） HTML 快照策略。充分利用HTML快照，看看JS运行前首页的其他传统优化方法。这包括优化第三方库引用、优化代码执行流程、观察和解决代码中的性能瓶颈等等。等这次实验完成后，我打算再写一篇文章，总结一下我在这样一个综合实践方案下的经验，为其他业务优化提供参考。我们的目标是为H5性能树立新标杆，帮助您利用H5开展更多业务，释放业务迭代潜力。

表现

全球性能： Android：

iOS：

总体而言，离线包显着改善了Android 系统上的页面加载。另一方面，针对IOS系统的改进相对较小，但也有明显的速度提升。从一页剧的角度观察，又从业务的角度观察，线下套餐的提速效果如下：

PV数较小的性能数据是不可靠的，所以从可靠的数据来看，从onload事件的平均时间来看，单纯访问离线包后，非离线包状态的加载时间约为2700ms。加载时间分别缩短了约2300ms 和400ms。经过深度资源分析，将所有在线加载的js 文件放入离线包中，加载时间下降到2023 毫秒，还有可能再提升300 毫秒。总体来看，离线包可以将简单H5页面的加载性能（onLoad）提升700ms。而且，用户体验基本上是在过渡动画完成之前就可以显示页面。

根据页面的FCP数据，我们可以看到，优化后，页面首屏渲染时间从1550缩短至1230，提升了300毫秒，本质上已经接近“秒开”。对于其他更复杂的页面（更多图片、更多JS），离线打包会提高性能。

行业解决方案比较

B站计划与行业计划的区别

综上所述，B站线下打包解决方案具有以下特点： 错峰发布：通过错峰发布，充分利用CDN闲置流量，以低成本发布资源版本控制策略。 通过版本控制策略保留较旧的数据版本，符合前端业务一次发布所有用户更新的共同理念。这在需要紧急更新或者离线调试流程优化的场景下更为重要。扫描二维码调试可以是一个巨大的改进。提高访问效率、保证在线稳定性是性能优化的第一步。 HTML 快照：使用上次渲染的结果来优化下一个条目的首屏速度。不过，调试成本较高，但值得一试。多篇社区文章中简要提到了此解决方案。 AB实验特点：考虑用户体验和业务需求，保证大页面修改时性能不下降，并允许AB实验数据回收。同时，我们选择不实施一些业界常见的解决方案。 as:Webview 在后台预加载并初始化Webview，需要时可以直接使用。这个方案一开始无法实施，因为我们内部的业务容器没有集成，但是集成之后我们发现哔哩哔哩应用容器的二次加载时间本质上减少了。任何低于130 毫秒的时间都会在很长一段时间内消耗大量内存，因此对于优先考虑视频观看体验的应用程序来说这不是一个好主意。然而，在应用程序启动时预加载webview 以缩短初始初始化时间会影响用户启动速度，因此被放弃。提前请求接口也是缺乏收入的问题。这里描述的解决方案是在webview初始化时预先发起接口请求。在完全优化的离线包中，理论上，接口请求会在HTML 和JS 加载后立即开始，从而允许前端在请求返回之前开始从客户端获取数据。这种中间状态下的处理成本也给调试增加了额外的精神压力。理论性能优化性能应该在50-150毫秒左右，这个比较适中。至于在feed流中预加载后续文章的接口的实现方案，还不够通用，可以在各个业务层实现，而不是应该考虑作为全公司离线包的解决方案。有些技术已经到位，有些技术也在实现： 公共打包技术：收集公共JS 资源，避免同时多次打包并使用平台功能自动完成公共资源更新和增量包分发：是对于每个版本。对于一个包，会生成一个增量包，计算该包与之前N个版本的差异，以缓解CDN根据客户端当前版本进行下载。为特定的高优先级服务启用热更新。更新推送有利于快速更新。仅Wi-Fi 下载和版本限制：对传送条件设置某些限制以节省用户流量。

网页视图

常驻方案
简介：对于Feed流或者频繁打开同类页面的场景，可以保持Webview常驻后台，点击链接时将Webview拉到前台，并替换页面的URL参数，页面拉取接口数据并展现。差异点：
Webview常驻方案
B站离线包方案
性能
非常快。由于省去了容器初始化和页面JS初始化的诸多流程，这个方案的性能优于离线包，配合feed流数据接口预取，可以让用户几乎无法感知到加载过程。
性能比较常规，在不使用HTML快照这样的特殊方案时，性能与业界方案是类似的。
方案通用性
较差。适用场景相对局限，比较适合频繁往返于列表页到详情页的这类场景，例如新闻阅读类应用、商城类应用等。
通用性好，同样的方案可以在B站绝大部分H5业务上使用。漫画App、云视听小电视、直播姬等App的也已低成本接入
代码侵入性
强。需要代码做针对性适配，以及客户端配合才能完成一个特定场景下的落地
侵入性低，除了需要注意Post请求问题和History API在IOS上无法记录历史记录外，其他代码与线上业务完全相同
总体看，B站的离线包方案为了方案通用性，牺牲了一些性能表现，好处是可以比较简单地应用在各业务场景上，带来相对普遍的价值。
货拉拉的离线方案
简介：货拉拉方案与本文提到的方案在某些方面是有共通之处的，在基础加速层面上除了底层的技术实现思路采用了加载本地路径的方案，其他包括资源下发、多层降级机制等方面基本类似。差异点：由于技术实现原理类似，因此在性能和通用性上，两者差异较小。我们从另外的方面比较：
货拉拉方案
B站离线包方案
容器实现位置
基于通用容器上的一个独立增强容器，各业务容器基于此拓展
直接放入基础容器内，开箱即用
兼容性
存在跨域问题
基于https拦截，与线上几乎一致
代码侵入性
有少量侵入性，需要对本地加载的路径做一些适配
侵入性低，除了需要注意Post请求问题和History API在IOS上无法记录历史记录外，其他代码与线上业务完全相同
另外我们观察到货拉拉方案里离线包的URL映射是动态下发的，B站的离线包URL映射则是打包到包里的，另外通过一个动态接口控制当前可用的版本。这两个方案都是可行的，总体来看，有这些差异：
动态下发URL映射
打包URL映射
优势
方便灵活，可以很简单地修改映射关系
有利于这个包的逻辑独立性，这也是扫码调试功能好实现的一个因素
缺点
可追溯性差，配置不断在变化，配置和包资源无法一一匹配时，可能导致过去历史版本可能因为配置变更而不能再看
灵活度差，修改URL映射需要发一个新的包
支付宝的Nebula方案离线包能力
支付宝的离线包的定位并非是加速线上业务的能力，而是更接近离线H5应用的模式。在离线包未下载的时候，他会请求提前部署的降级资源，也就是使用的业务并不需要自行部署一套页面在线上，需要有一个域名和url，而是只需要使用它提供的方案就可以完成部署。其运行机制，类似货拉拉方案，是用file协议加载，向H5页面提供一个虚拟域名供识别。在API能力上，配备了一套JSAPI来满足业务的使用，所以看起来比较接近小程序的实现思路。总体来讲，支付宝因为业务都是以一个个独立的H5App来承载的，H5 App之间彼此关联和交互较少，所以方案会接近小程序，而后续支付宝也确实往前走了一步，实现了小程序的能力。B站由于页面基本都是自有的，且Native跳H5、H5跳Native的场景很多，需要为用户提供一个整体性的体验，所以方案更偏向“加速”，而非独立H5 App
UC的NSR方案
UC浏览器在新闻feed流页面加载中采用了NSR（Native Side Rendering），首先在列表页中加载离线页面模板，通过Ajax预加载页面数据，通过Native渲染生成Html数据并且缓存在客户端。NSR本质是分布式SSR，将服务器的渲染工作放在了一个个独立的移动设备中，实现了页面的预加载，同时又不会增加额外的服务器压力。下面看方案对比：
NSR方案
B站离线包方案
性能
更快，通过客户端渲染，可以不依赖Webview生命周期就可以提前渲染出所需的HTML
一般，仍然需要等待容器初始化+html加载+JS编译执行+接口请求+框架渲染
方案通用性
相对一般，有一定的定制性
比较通用，整体都是在Web标准上做的一些优化
代码侵入性
较强侵入性。一个是代码编写接近常规带SSR的页面，另一方面NSR渲染结果和Webview内展现的过程是有一定逻辑的。
较低侵入性。使用常规方案几乎不需要改代码。
如需更快的性能，代码快照会类似这套方案，只不过复用的是上一次渲染的结果。当然使用代码快照也意味着带来更强的侵入性。
兼容性
需要额外考虑在客户端JS环境运行的兼容性
较好，与线上页面类似
腾讯的VasSonic方案
VasSonic除了常规的资源预载之外，还做了以下事情：
webview 初始化和通过客户端代理资源请求并行流式拦截请求，边加载边渲染实现了动态缓存和增量更新VasSonic 的方案整体思路和效果非常不错，特别是对于大部分 web 场景，通常我们的模板较少发生变化，大部分是数据部分变化，能够很好的通过局部刷新做到秒开效果。对于首次加载而言，通过并发请求和 webview 创建带来了不错的性能提升，还能无缝的支持离线包策略。但是 VasSonic 定义了一套特殊的注释标记及拓展了头部，需要包括后台在内的前后端进行改造，对 web 侵入性非常强，接入的工作量及维护成本会非常大。
方案总结
总的来讲，离线包加速方案的各个技术决策其实就是在平衡通用性和性能。通用性越好，能做的事情越少，方案约需要遵循Web标准，当然性能的提升幅度也会小一些。抛开通用性，如果针对业务特定定制更多的优化方案，那么优化效果一定是可以做的更好的，当然也就更专用，难以大规模铺开。B站的离线包在决策时更多考虑了通用性，因此得以在各业务线都能比较低成本地接入，有比较广泛的使用群体。在此基础上，例如电商业务也针对他们的业务特点做了更专用化的定制，例如Webview常驻方案，得到了更好的效果。所以可以认为离线包作为一个通用方案，提升了性能的下限，它并不与专用方案冲突，可以再额外使用专用方案来提升性能的上限。
参考文章
B站离线包在研发阶段基本遵循净室研发规则，除参考了业界方案的一些思路外，具体的方案设计和实现均为自研。
在本篇文章的方案对比方面，主要参考了以下文章：
【移动端h5秒开方案总结】https://blog.towavephone.com/mobile-h5-startup-way/
【货拉拉H5离线包原理与实践】https://juejin.cn/post/7103348563479887885
【CSR、SSR、NSR、ESR傻傻分不清楚，一文帮你理清前端渲染方案！】https://juejin.cn/post/6844904178519834638
【离线化集成方案-安全设计与优化】https://research.szltech.com/ p=1935
【WebView性能、体验分析与优化】https://tech.meituan.com/2023/06/09/webviewperf.html
【蚂蚁金服金融科技产品手册】https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/87479/AntCloud_zh/1578025862524/10%20H5%20%E5%AE%B9%E5%99%A8%E5%92%8C%E7%A6%BB%E7%BA%BF%E5%8C%85%2023200101.pdf
作者:大前端
来源-微信公众号:哔哩哔哩技术
出处:https://mp.weixin.qq.com/s/WMf28adh30v67uuEn99F6Q