H5开屏从龟速到闪电，企微是如何做到的

导读｜H5开屏龟速常是令开发者头疼的问题。腾讯企业微信团队对该现象进行分析优化，最终H5开屏耗时130ms，达到秒开效果！企微前端开发工程师陈智仁将分享可用可扩展的Hybird H5秒开方案。该团队使用离线包解决了资源请求耗时的问题，在这个基础上通过耗时分析找到瓶颈环节，进一步采用“预热”进行优化提速以解决了WebView初始化、数据预拉取、js执行（app初始化）耗时的问题。希望这些通用方法对你有帮助。

背景

服务端渲染（SSR）是Web主流的性能优化手段。SSR直出相比传统的SPA应用加载渲染规避了首屏拉取数据和资源请求的网络往返耗时。团队针对Web开发也已经支持了SSR能力。近期出于动态化运营的考虑，我们选择了Web开发，同时我们也接到了提升体验的诉求。

以企业微信要开发的页面为例：采用SSR方案，从用户点击到首屏渲染的耗时均值约600ms，白屏时间的存在是可以感知到的。为了尽可能消除白屏达到秒开效果，我们尝试做更多探索。

方案思路

1) 方案选型

如何实现页面秒开呢？从最直观的渲染链路来入手分析。下图列出了从用户点击到看到首屏渲染可交互，一个SPA应用主要环节的加载流程。我们调研了业内相关方案，从渲染链路的视角来看下常见方案的优化思路。

• 
  
• 传统离线包
  

在加载渲染过程中，网络IO是很明显的一个耗时瓶颈。传统的离线包方案思路很直接，如果网络耗时那就将资源离线，很好地解决了资源请求的耗时。用Service Worker也能达到离线包的效果，同时也是Web标准。首次渲染优化一般需要结合客户端配置预启动脚本来达到缓存资源的效果。

• 
  
• SSR
  

SSR则从另外的角度出发，在请求页面的时候就进行服务端数据拉取和页面直出，首屏得以在一个网络往返就可以展示，有效地规避了后续需要等待css/js资源加载、数据拉取的时间。性能体验有比较大的提升，在BFF普及的情况下开发模式简单，很受欢迎。

• 
  
• 公司内相关工作
  

考虑到WebView的初始化（冷启动/ 二次启动）、页面网络请求、首屏数据接口的耗时，白屏时间还是可感知地存在的。以我们要开发的页面为例采用SSR首屏耗时均值600ms，可交互时间均值1100ms。如何进一步消除白屏？这里为各位介绍公司内外针对h5首屏性能优化的优秀方案。

手Q团队的VasSonic是集大成者，主要思路是采用WebView和数据预拉取并行的方式。这套方案需要客户端和服务端采用指定协议改造接入，开发时也有一定的改造工作。

微信游戏团队主要思路是利用jsCore做客户端预渲染，用户点击后直接上屏。这个方法也达到了很好的效果，首屏FCP时间从1664ms降低到了411ms。

我们做了一个简要的方案对比，可以看到每个方案都针对渲染链路的某个或多个环节做了优化，其中VasSonic的效果比较显著。不过结合企业微信业务实际情况，我们列出了如下几点考虑：

首先，接入对客户端和服务端有一定的改造成本，业务开发也有一定的改造工作。其次，我们已经有一套的统一发布平台，希望能复用这套发布能力。最后，性能上有没有进一步优化的空间呢？业务需求对体验上的要求是希望达到更好的性能效果或者说尽可能完全地消除白屏。

基于以上考虑，我们在上述方案的基础上做了进一步的实践探索，以期望达到更好的性能效果。

	离线包	SSR	VasSonic	CSR
资源加载
数据拉取
JS执行
WebView启动优化
首屏FCP
可交互(取决于JS执行)

2）方案架构

为了达到尽可能完全消除白屏，我们还是从初始问题出发，结合渲染链路进行分析，思路上针对每个环节采取对应的优化方法。

每个环节的优化在具体落地时会存在着方案的利弊取舍。比如预拉取数据一般的思路是交给客户端来做，但是存在着客户端请求和h5请求两套机制（鉴权、请求通道等方面）如何协调的问题。在渲染链路分析时，如果业务的js执行也贡献了不少耗时，有没有可能从通用基础方案的角度来解决这个问题，同时也能减少业务对性能优化的关注？这是个值得各位思考探索的问题。具体的内容会在后面展开来说。

如图展示了方案的优化思路和主流程。方案使用离线包解决了资源请求耗时的问题，在这个基础上通过耗时分析找到瓶颈环节，进一步采用预热的思路进行优化提速，解决了WebView初始化、数据预拉取、js执行（app初始化）耗时的问题，最终达到了理想的性能体验。

图1 上屏流程

图2 方案架构

下面我们具体介绍下方案，包括：离线包技术、预热提速和进一步的优化工作。

离线包加速

为了规避资源请求耗时，我们使用了离线包技术。离线包技术是比较成熟的方案，相关打包、发布拉取的方案这里不多说了，主要说下方案中一些设计上的考量。

1）加载流程

我们通过offid作为离线包应用的标识，fallback机制保证离线资源不可达时用户也可以正常访问页面，通过离线包预拉取和异步检测更新机制提高了离线包命中率，尽可能消除了网络资源加载的耗时。

2）fallback机制

因为用户网络状况的不确定性，离线包加载可能存在失败的情况。**为了保证可用性，我们确定了离线包加载不阻塞渲染的思路。**当用户点击入口url，对应offid离线包在本地不存在时，会fallback请求现网页面，同时异步加载离线包。所以我们针对离线包的打包结构，按照现网URL path来组织资源路径。这样客户端请求拦截处理也会比较方便，不需要理解映射规则。当发现离线包不匹配资源时，放过请求透到现网即可。如图展示了我们的离线包结构示例。

3. 离线包生命周期

为了提高离线包命中率，我们会配置一些时机（e.g.入口曝光）来预拉取离线包。

离线包的更新机制：客户端加载时根据offid检测到本地离线包的存在，则直接使用拉起，同时启动异步版本检测和更新。如果新包版本号大于本地版本号则更新缓存，同时发布平台也支持区分测试环境、正式环境以及按条件灰度。

上了离线包后，可以看到页面的首屏耗时均值从基准无优化的1340ms降到了963ms，离线包的预拉取和更新策略则使离线包命中率达到了95%。首屏耗时得到了一定的降低，但也还有比较大的优化空间，需要更一步的分析优化。

预热提速

通过离线包的加速，我们解决了资源请求耗时的问题，不过从整个渲染链路来看还有很大的优化空间，我们做了具体的耗时分析，找出耗时瓶颈，针对耗时环节做了进一步的优化提速。

1）耗时分析

离线包技术规避了资源请求耗时，但是从整个渲染链路来看还有很大的优化空间，我们做了耗时分析如下。

Hybird应用中，WebView初始化是比较耗时的环节，这里我们针对iOS WebView做了测试。

数据拉取方面，不同入口页面的耗时不一，某些入口页面比较重的接口耗时超过了1s。

此外，我们发现js执行也贡献了不少耗时。以某入口页面为例，框架初始化时间～10ms，app初始化时间～440ms。

2）渲染链路预热提速

• 
  
• 
  

  预热流程

  
  
  

我们的目标是消除白屏，这里理想的方案是找到一种和业务无关的通用解法。方案的主要思路是预热，把能提前做的都做了。预热是不是就是把WebView提前创建出来就好了呢？不是的，这里的预热涉及到多个渲染环节的优化组合。如图展示了预热的整体流程，下面一个个来解。

2）WebView预创建

为了消除WebView的耗时，我们采取了全局的预创建WebView，时机为配置入口曝光。不过全局复用预热WebView不可避免地会引入可能的业务内存泄露问题，下文会介绍对应的规避方案。

• 
  
• 
  

  数据预拉取

  
  
  

数据拉取是页面渲染的一个耗时环节。为了消除数据预拉取耗时，在预创建WebView阶段我们同时进行了数据预拉取。

数据预拉取常见的思路是交给客户端来做，但是存在着客户端请求和h5请求两套机制如何协调的问题，以请求鉴权为例，存在以下的问题：

第一，Web团队自身有一层node BFF，实现了相应的数据拉取业务逻辑，而客户端则走的私有协议通道请求C++后台，二者是不同的鉴权机制。

第二，如果交给客户端来做，可以接入HTTP请求这套机制，改造成本比较大，如果复用原有通道，则一份数据业务逻辑需要两套实现。

如何设计一套通用可扩展的方案？我们希望做到客户端只关注容器的能力（预热、资源拦截等），屏蔽掉更深入的对Web的感知，这样的解耦可以有效控制方案的复杂度。因此，这里我们针对离线包配置项增加了preUrl字段，使客户端维护更通用的能力，数据预拉取交给业务团队来做，具体如下：

第一，客户端：拉取某个离线包配置项时会读取该字段，同时针对当前曝光的入口url可能存在多个有着不同的数据需求，这里会进行收集，将曝光url中的业务key参数拼接到preUrl来初始化WebView，这些作为通用能力。

第二，业务：preUrl页面在加载时会拉取相应的业务数据存到localStorage，实际的数据预拉取请求放到业务方发起，也可以很好地兼容已有的技术栈。

• 
  
• 
  

  JS预执行

  
  
  

很接近目标了，最后js执行的耗时能不能消除呢？首先来看下440ms的耗时具体在哪里，通过分析看到，框架初始化仅需要不到10ms的时间，而真正的大头在业务代码的执行，其中代码编译耗时～80ms，其余的都是业务app初始化执行时间，这个是业务本身复杂度造成的。

我们首先考虑了创建两个WebView的方案，一个负责加载preUrl预拉取数据，另一个负责loadUrl上屏，这样设计上比较简洁健壮，不过实践下来发现效果不理想，如图展示了该方案的效果，渲染不稳定可以感知到白屏的存在。在已经有了预拉取数据和离线资源的情况下，理论上用户点击后需要等待的就只有渲染这块的耗时，实际我们发现在复杂应用初始化时存在js执行耗时较大的问题。

最终我们做了一个预执行的解法。结合SPA的特点，将preUrl作为SPA的一个子页面，不需要UI展示，只负责预拉取数据，这样子页面加载完成的同时也完成了app提前初始化。而相应的不同入口切换页面时，不同于复用预热WebView重新reload页面，为了保留app初始化的效果，我们采取了一套Native通知Web SDK，页面切换交给WebView控制的方案。其中，Native通知则以调用SDK全局方法的方式。通过这种方式，入口页面间切换其实只是hashchange触发的子页面渲染，达到了不错的效果。流程图即预热方案的上屏部分。

该方案执行后我们达到了预期目标效果，最大限度地消除了白屏接近Native体验。需求上线后通过监控数据可以看到在命中预热和离线包逻辑的情况下，从用户点击到页面上屏可交互耗时均值约130ms。

进一步优化

1）离线包安全

在离线包安全方面，为了防止包篡改，每我们次打包发布时都会生成包签名和文件md5。客户端在使用解析离线包时会校验完整性，在返回离线资源时会校验文件完整性。

2）稳定性

整体方案在性能上已经达到目标了，保证稳定性对产品体验也很重要。**我们为了消除js执行的耗时，采取了Native通知Web SDK控制页面切换的方式。虽然比较灵活但是也带来了稳定性的问题。**具体来说，如果SDK在做页面切换时异常，之后用户打开每个入口url都会看到相同的页面。入口页面的业务在用户使用过程中如果跳转了非SPA的链接同时没有注入SDK，之后的页面切换也会失效。

如何保证预热容器的可用性呢？我们设计了一套通知机制确保客户端感知到预热容器的可用状态，并在不可用时得以恢复，如图。预热容器会维护isInit和isInvokedSuc两个状态。只有当preUrl成功加载和SDK执行成功上屏时，两个状态才会置true，此时的预热WebView才是可用的，否则会回退到普通容器模式进行load url来加载页面。

此外，在每次入口url曝光时，已有的预热容器也会销毁重建，也有效保证了容器的稳定性。

3）内存泄露

使用全局的预创建WebView，不可避免的会引入可能的业务内存泄露问题。在测试过程中，我们也发现了这种例子。可以看到当点开使用了预热容器的页面后放置一段时间，整个内存在不断上涨，最终会导致PC端页面的白屏或者移动端的Crash，这个状况最终归因是业务逻辑的实现存在缺陷。

不过在基础技术的角度而言，开发者也需要采取措施来尽可能规避内存泄露的情况。主要思路是减少同一个预热容器的常驻，也就是对存活的容器设置有效期，在适当的时机检查并清理过期容器，我们选择的时机是App前后台切换时。

4）解决副作用

出于性能考虑，我们选择了通过Web SDK控制页面的方案，同时使用了全局的预创建WebView。这带来了副作用——当页面对容器做了全局的设置，可能会影响到下一个页面的表现。比如：设置document.title、通过私有JSAPI设置了WebView导航栏的表......

当执行这些操作时，在下一个页面也复用预热容器的情况下，全局设置没有得到清理重置或者覆盖，用户会看到上个页面的表现。

为了解决上述问题，业务可以在每个页面主动声明需要的表现来覆盖上个页面的设置，理想的方法还是基础技术来规避这个问题来保证业务开发的一致性。我们在SDK控制切换页面时，进行了一系列的重置操作。

此外，在Windows和Mac端，我们也设计了双预热WebView的方案来完全解决这个问题。每次使用时同时创建新容器，得以保证每次打开入口页面都是使用新创建的容器。当然，方案的另一面则是会带来App内存的上涨。

总结

我们从渲染链路入手，针对每个环节进行分析优化，最终沉淀了一套可用可扩展的Hybird H5秒开方案。从渲染链路的角度来看，方案通过离线包和预热一系列优化，将用户从点击到可交互的时间缩短到了一个SPA路由切换上屏步骤的耗时。

上线后我们监控发现，命中了预热离线逻辑的页面首屏耗时～130ms，相比于离线包、SSR都有优势，同时预热离线容器命中率也达到了97%，达到了理想的体验效果。希望本篇对你有帮助。

‍