提高转化率

转化率是指用户进行某一目标行为的访问次数与总访问次数的比率。这些行为包括订阅、购买等。

留住用户是提升转化率的关键。有研究表明，缩短渲染时间可以提高转化率：将3G连接的渲染时间从14秒缩短到2秒后，访问量增加了19%，总会话增加了35%，新用户增加了7%，活跃用户增加了17%。同样，缩短小程序渲染时间也会有效提高转化率。

改善用户体验

性能是打造良好用户体验的必要元素。当用户进入小程序时，性能好可以快速加载页面。如果性能差，加载速度太慢，用户就得等待。当用户对低性能小程序的容忍度达到一定程度时，就会选择放弃。《High iOS Apps》一书中的数据显示，如果启动时间超过 3s，25% 的用户会放弃使用该应用。

3. 绩效指标与衡量

用性能指标来评估小程序的加载速度是非常有必要的，首先我们来回顾一下小程序页面加载的关键阶段。

这些阶段的含义如下：

阶段

意义

下载小程序包阶段

（FP）

第一次绘制界面

（FCP）

第一张有内容的画

（FMP）

第一幅有意义的绘画

到达时间 (TTI)

页面被绘制出来并且变得可交互。

我们最关注的是从用户点击小程序到第一页第一次有意义绘制（FMP）的总时间。

百度智能小程序为开发者提供了性能监控指标平台，帮助开发者监控小程序线上加载性能，开发者可以在“开发者平台-开发管理-运维中心”界面查看小程序的加载性能监控。

在运维中心，用户可以监控小程序的性能指标（在运维中心里FMP叫驻屏时间），如下图所示：

4. 如何优化性能 4.1 小程序启动流程

有效识别小程序性能问题、制定优化策略的一个重要前提是能够理解并熟悉小程序的启动流程。

因此我们先简单介绍一下百度智能小程序的启动流程，如下图所示：

接下来我们简单介绍一下小程序框架在各个环节的主要内容：

1.用户点击打开小程序

小程序启动的起点。

2.下载小程序包

当用户首次打开小程序时，会下载最新版本的小程序包。

3.启动小程序运行框架

初始化小程序逻辑层

初始化小程序渲染层

4. 首次渲染

在逻辑层初始化完成后，小程序框架会收集页面显示所需要的数据（），然后将这些数据发送给渲染层（）。

渲染层收到之后会初始化页面，绑定模板和数据，开始首次渲染（FCP）。

5.执行页面生命周期

渲染层完成页面首次渲染后，通知逻辑层（）开始执行页面生命周期。

开发者通常在生命周期中开始请求页面主数据（小程序想要在首屏展示给用户的数据）。

6. 首次有意义的渲染

当数据请求完成后，开发者通常会将数据发送给渲染层()，渲染层绘制完成后再触发FMP。

在下文中，我们将把对页面主数据的请求以及对应的请求分别称为核心请求（）和核心。

4.2 如何识别性能问题？

性能问题可能发生在启动过程的不同阶段。

不同的小程序针对的使用场景不同，业务逻辑不同，展现给用户的页面结构也不同，因此性能问题的表现形式也会有很大差异。

即使是同一个小程序，不同阶段的问题对最终的性能影响也是不同的，我们往往需要聚焦性能瓶颈，而忽略相对不重要的部分。

另外，小程序启动过程中的各个阶段并不是独立的，而是存在一定的联系，在完成一些性能优化之后，性能问题可能与之前有明显的不同，需要重新分析和考虑。

因此小程序性能问题的分析和识别是一个相对复杂的过程，以往小程序性能问题的分析通常是基于过往的性能优化经验，或者通过阅读小程序代码来进行，但这个过程不仅耗时耗力，而且最终的结果也未必准确。

工欲善其事，必先利其器，使用好的工具将大大提高我们分析问题、解决问题的效率。

百度智能小程序提供了启动性能分析工具（t.hk.uy/bbsQ），可以分析小程序的启动性能......

在下文中，启动性能分析工具有时被称为性能工具。

上图为启动性能分析工具的展示页面，主要由顶部栏、左侧栏和主面板三部分组成。

顶部栏中央为两个选择器，用于选择历史性能数据和不同页面对应的性能数据；左侧栏用于切换不同的主面板，展示不同类型的性能数据分析结果。

在FMP面板中，启动性能分析工具将启动过程转换成时序图：

1.左侧为逻辑层，右侧为渲染层

2. 从上到下，时间逐渐增加

3、线的长度表示该阶段在整个启动过程中的时间占比（相对值）。

在时序图的右侧，有一个表格，列出了各个阶段具体的开始、结束和耗时（绝对值）。

4、绿线表示当前线程繁忙，灰线表示空闲，左右连接线表示通讯（事件、数据传输），蓝线表示请求。

通过时序图可以快速判断哪个阶段相对最耗时。

4.3 如何解决性能问题？

不同的性能问题需要不同的解决方案。

根据经验，小程序的性能问题通常出现在初始化小程序逻辑层、请求主要数据（执行）、首次有意义渲染几个阶段。下面将介绍这些性能问题的具体表现以及对应的优化策略。

小程序包优化：减少小程序初始化耗时

在时序图中，通常体现为App.之前耗时过长，如下图所示：

在应用程序之前，主要阶段是加载和执行逻辑代码。

加载逻辑代码所需的时间主要与小程序逻辑代码的大小有关。

一般来说，小程序包越大，其逻辑层代码量就越大，因此加载所需的时间就越长。

开发者可以使用分包、独立分包（t.hk.uy/bbsS）或者删除无用的代码...

执行逻辑代码所花费的时间主要和小程序逻辑代码业务相关。

开发者除了需要优化js代码本身的执行时间之外，还需要关注swan API的调用。

很多 Swan API 涉及到与客户端应用的通信，因此耗时比 js 代码执行要多。小程序可能会重复调用很多 API，但是这些 API 调用的结果都是不变的，比如 etc。所以建议根据业务情况对结果进行缓存，这样会有效减少逻辑代码的执行时间。

尽早请求：尽早发送核心请求

很多开发者会在 中发出核心请求，但如启动流程所示，执行依赖于第一次渲染的完成，如果第一次渲染很慢，就会导致执行来不及。

百度智能小程序提供了页面级的生命周期 Page，该生命周期在页面首次渲染前触发，相比 ，生命周期执行时间会有很大提升。

下图为提前请求后的时序图效果：

可以看出，请求响应和首次页面渲染是并行处理的。因此，优化效果会非常明显。

经过本次优化，百度知道、百度百科、宝宝知道小程序的性能提升分别达到了、、和。

想要访问的开发者可以参考：页面.访问指南(t.hk.uy/bbsT)。

请求响应优化：减少核心请求所花的时间

在时序图中，这反映在核心蓝线太长：

优化请求响应除了优化网络服务器本身的性能之外，还可以从以下几个方面考虑：

打开

用于预先与业务服务器建立网络连接，以便后续的主请求可以重用该连接，提高请求速度。

上图是使用前后对比：配置完成后，小程序框架在加载逻辑代码的同时，会发送预连接请求，在发送主请求时，可以直接复用该连接，减少主请求的时长。

配置指南（t.hk.uy/bbsW）

启用服务器端 gzip

Gzip 是节省带宽，加快数据传输速度的有效方法，当服务器开启 gzip 后，可以减少请求传输的大小，使得传输速度更快。

减少请求响应的大小

某些情况下，请求响应中包含大量与页面显示无关的数据，导致传输量很大，响应时间很长；比如响应量为200K，其中只有50K与页面显示相关。

包含过多无用数据的原因可能是一个数据接口服务于多个需求，每个需求都需要不同的数据，导致大小过大。

您可以考虑同意一种新的数据格式并与服务器交互以减少请求响应的大小。

渲染优化：避免首次渲染过多内容

如下面的时序图所示，在请求完成后，核心渲染成为最耗时的一个阶段。

通常这意味着开发人员渲染了太多内容。

很多业务场景下，小程序渲染的页面高度超过一屏，但首次进入页面时，只需要渲染可见内容，页面首次渲染完成后，其余页面内容会继续异步渲染，因此可以对首次渲染的内容做一些取舍或者删减，例如：

案例参考：宝宝知道问答页面按需渲染优化（t.hk.uy/bbsY）

五、总结与展望

开发者了解小程序的性能指标和启动流程后，通过启动性能分析工具，就可以轻松发现性能问题并进行优化。除了上文提到的性能问题和优化策略，开发者还可以阅读百度智能小程序官方提供的性能优化文档，获取更加详细的优化方法和实践案例。

除了开发者自己根据时序图进行分析外，目前性能工具还提供了性能分析清单，可以自动分析小程序的性能问题并给出优化建议。 检查项和建议都是基于小程序当前运行结果和线上统计数据，并结合小程序性能优化的实践经验，因此通常更加直观有效。

未来我们会尽力提前警示开发者可能出现的性能问题：将自动化性能分析与小程序发布流程有机结合，在全面发布前拦截性能问题，避免上线后才发现改动会导致非预期的性能下降。

- - - - - 结尾 - - - - -