得物 App H5 秒开优化实战

背景

H5 秒开优化是一个老生常谈的问题，于是得物联合了客户端和 H5 共同发力。本文将逐步介绍如何通过客户端 + H5 的优化手段（1+1>2）把秒开从 30% 提升到 75% ？后续接口预请求、客户端预渲染以及预加载 2.0 上线后还会再次助力指标提升。

为什么要做优化？

Global Web Performance Matters for ecommerce的报告中指出

• 47%的用户更在乎网页在 2 秒内是否完成加载。

• 52%的在线用户认为网页打开速度影响到他们对网站的忠实度。

• 每慢 1 秒造成页面 PV 降低 11%，用户满意度也随之降低降低 16%。

• 近半数移动用户因为在 10 秒内仍未打开页面从而放弃。

整体系统架构图：

指标选择

首先讲一下得物用来衡量秒开的指标 FMP，那为什么不选择 FCP 或者 LCP 呢？FCP 只有要渲染就会触发，LCP 兼容性不佳，得物希望站在用户的角度来衡量秒开这件事情，用户从点击打开一个 webview 到首屏内容完整的呈现出来的时间点就是得物定义的 FMP 触发时机。

指标清楚了之后，再来看一下完整的 FMP 包含哪些耗时。

接下来将分为两大部分进行介绍，客户端优化部分和 H5 优化部分。

客户端优化

通过 HTML 预加载、HTML 预请求、离线包、接口预请求、链接保活、预渲染等手段提升页面首屏打开速度，其中预加载、预请求、离线包分别可提升 10%左右的秒开。

HTML 预加载

通过配置由客户端提前下载好 HTML 主文档，当用户访问时直接使用已经下载好的 HTML 文档，以此减少 HTML 网络请求时间，从而提升网页打开速度。

暂时无法在文档外展示此内容

如何确定需要下载的页面

前人栽树后人乘凉，得物 App 有很多的资源位，banner、金刚位、中通位等，这些位置显示什么内容，早就已经是智能推荐算法产出的了，那么就可以直接指定这些资源位进行预加载。

页面缓存管理

页面被预加载之后，总不能一直不更新吧？那么什么时候更新页面的缓存呢？

• 预加载的页面存放于内存中，关闭 App 缓存就会被清除

• 通过配置过期时间人为控制最大缓存时间

• 在页面进入后发起异步线程去更新 HTML 文档。

被现实打脸：

但是在后面的灰度过程中被现实狠狠的教育了一顿，发现有些 SSR 的页面会涉及到状态的变更，比如说：领劵场景。这些状态都是经过 SSR 服务渲染好的，用户在进入页面时还没有领劵，这个时候去更新 HTML 文档，实属更新了个寂寞，在用户领劵之后关闭页面再次进入，发现页面中的状态仍是让用户领劵，点击领劵又告诉人家你已经领过了。

改进措施

1. H5 页面在打开时针对状态可能会发生变更的组件，再次请求接口获取最新的状态数据。

2. 客户端由进入页面就更新 HTML 文档修改为：关闭 webview 时更新 HTML 文档。

线上收益效果

至此问题也解决了，工程师的任务结束了吗？如果你认为功能做上去就算结束，那么此时此刻请你一定要转变思维，想一想我们的目标是什么？我们的目标是提升秒开，预加载只是一种提升秒开的手段，但是在功能做上去之后并不知道这个功能带来了多少秒开的收益，因此在把功能开发完成上线之后，就要开始关注上线之后的结果，来看看预加载的性能表现如何。 从下图可以看到，预加载开启状态下可提升 10%以上的秒开率。

遇到的挑战

1. 预加载的页面基本上都是 SSR 服务的页面，预加载无形中造成了大量的请求，此时得物的 SSR 服务扛不住这么大的请求量

2. 即使 SSR 服务扛得住，也会对后端整个服务链路造成压力

SSR 服务扩容

要解决服务器压力问题，很自然就会想到增加机器，于是我们对 SSR 机器数量做了一次扩容，将机器数量提升了一倍，这个时候继续尝试扩大预加载的用户数量，但是仍然无法抗住这么大的 QPS，而且此时还引发了第二个问题，算法部门的服务器发出了告警，于是放量计划又一次遇到了阻碍。

破局者 CDN

利用 CDN 服务器的缓存能力既可以减轻 SSR 服务器的压力又可以减少后端服务链路的压力，这么好的东西为什么不用呢？这里留个悬念，后面将 H5 优化部分会详细介绍。

客户端配合改造

• 支持针对 CDN 域名进行全部开放预加载能力，针对非 CDN 域名保持原有放量比例

开屏页预加载

在这个过程中还分析了页面的流量占比，发现开屏广告来源的页面流量占比也很高，那么是不是可以把开屏广告的 HTML 文档内容也给预加载下来呢？

开屏页面预加载策略

1. 对预加载列表进行去重，开屏广告列表中可能会存在重复的页面，他们的背景图和生效时间是不同的

2. 增加了生效时间相关配置，开屏广告列表中存在于未来某段时间才会展示的页面

3. 添加黑白名单控制，开屏广告列表中可能会有第三方合作页面，他们不希望预加载统计会造成 PV 时不准确

预加载展望

既然可以提前下载好 HTML，那是不是可以更进一步，提前把页面内的资源加载好，这样在打开一个页面的时候可以减少大部分的网络请求从而更快速的把内容呈现给用户。这里还需要考虑如何跟下面讲到的离线包进行协作。

HTML 预请求

在 webview 初始化同时，去请求 HTML 主文档，等待 HTML 文档下载完成 且 webview 初始成功后渲染，减少用户等待时间，客户端请求成功后，webview 加载本地 HTML，并保存以供下次使用。预请求 HTML 开启状态下可提升 8%左右的秒开。

预请求 VS 预加载

本质上 HTML 预加载和 HTML 预请求的区别就是下载 HTML 文档的时机不同， 预加载是在 App 启动后用户无任何操作的情况下就会去下载，但是预请求只会在用户单击打开 H5 页面的时候才会去下载。如果用户是第二次打开某个 H5 页面，此时发现本地有已经下载好的 HTML 且尚未过期就会直接使用，这个时候的行为表现就跟预加载的功能是一致的了。

遇到挑战

上线之后发现预请求只提升了 2%左右的秒开，经过分析发现问题：

1. 缓存有效时间太短，页面过期时间只配置了 10 分钟，也就是说在 10 分钟之后用户就要重新去下载一次，那能不能把缓存时间延长呢？

2. H5 页面是没有自更新能力，无法支持配置更长的缓存时间，跟预加载 HTML 问题一致。

深入挖掘

在本地用低端机对整个秒开耗时链路进行了分析，为什么要用低端机分析呢？低端机有个好处，天然的加上了慢放功能，可以最大程度发现问题。

安卓 h5 页面加载 与 原生布局填充并行执行

从图中可以看出 h5 页面加载之前 耗时 分布在 activityStart() 函数，该函数 包含了 onCreateView ，其中耗时最长是 布局填充 inflate()，因为 WebView 对象是提前创建好的，直接从对象池中取出的，所以耗时主要在 初始化过程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗时 87 us，不到 1 ms），耗时还有 WebView 的一些其他初始化，jockey 的初始化 等等。

而秒开的计算是包含了 View 初始化到 WebVIew url 加载 的耗时，从而发现了优化点，可以将 Webview loadUrl 前置，h5 页面加载 与 原生布局填充并行执行。在 onCreateView 时，创建 FrameLayout 进行返回，执行 WebView loadUrl 之后，主线程开始 对布局进行 inflate，布局加载成功后，将其 addView 到 FrameLayout 中，减少了 loadUrl 的阻塞时长。中高端机型有 15ms 左右优化，低端机型有 30 ~ 50 ms 优化 效果。

双端下载 HTML 的时机提前至路由阶段

预请求 HTML 时机是在进入到 native 页面中，这个时间点距离用户单击事件已经过去 100ms，那么是否可以将下载 HTML 的时机提前呢？经过一番探索，最终选择在路由阶段进行拦截，既可以统一收口而且距离用户点击的时间间隔可以忽略不计。通过这种方式将下载 HTML 时机提前了平均 80ms+。

此时的流程变成了下面这样。

可能有的同学会问了，为什么不在用户点击的时候去下载呢？ 从用户点击到路由肯定还是有耗时的。

1. 代码层面不好维护，如果在点击时就需要侵入到业务层面，入口千千万，很难进行维护管理

2. 从点击到路由这部分耗时在线下进行了性能测试，几乎可以忽略不计

最终线上收益效果

在上述问题解决后，将缓存时间修改为 1 天，发现预请求 HTML 开启状态下可提升 8%左右的秒开，已经和预加载的效果相差不大了。

离线包

通过提前将 H5 页面内所需的 css、js 等资源聚合在一个压缩包内，由客户端在 App 启动后进行下载解压缩，在后续访问 H5 页面时，匹配是否有本地离线资源，从而加速页面访问速度。

安卓实现

资源拦截这块安卓这边实现比较简单，webview 支持 shouldInterceptRequest, 可以在该方法内检测是否需要进行资源拦截，需要的话返回 WebResourceResponse 对象，不需要直接返回 null

iOS 实现

但是在 iOS 这边遇到了一些困难，调研了以下方案：

方案一：NSURLProtocol 拦截方式

NSURLProtocol 拦截方式，使用 WKBrowsingContextController 和 registerSchemeForCustomProtocol。 通过反射的方式拿到了私有的 class/selector。通过把注册把 http 和 https 请求交给 NSURLProtocol 处理。通过这种方式确实可以拦截请求，但是发现 post 请求的 body 会出现丢失的问题。而且 NSURLProtocol 一经注册就是全局开启。我们希望他只会拦截接入了离线包的页面，但是没有办法控制他，他会拦截所有页面的请求，包括第三方合作页面，显然这是无法接受的。

方案二：通过 CustomProtocol 拦截请求

在 iOS 11 及以上系统中, 拥有了加载自定义资源的 API：WKURLSchemeHandler。

可以修改当前页面 url 为自定义 scheme 协议，比如：https://fast.dewu.com 修改为 duapp://fast.dewu.com 然后在客户端内注册该 scheme，前端配合修改页面内所有的资源请求未自适应协议，如：src="//fast.dewu.com/xxx" 就可以实现拦截。 但是在测试过程中发现，接口为了安全起见只允许白名单内的域名发起跨域请求，且无法配置多个域名，导致该方案无法继续进行。

方案三：hook handlesURLScheme

仍然是使用 WKURLSchemeHandler 然后通过 hook WKWebview 的 handlesURLScheme 方法来支持 http 和 https 请求的代理。通过这种方式虽然可以拦截请求了，但是遇到了以下问题：

body 丢失问题

不过在 iOS 11.3 之后对这种情况做了修复处理，只有 blob 类型的数据会丢失。需要由 JS 来代理 fetch 和 XMLHttpRequest 的行为，在请求发起时将 body 内容通过 JSBridge 告知 native，并将请求交给客户端进行发起，客户端在请求完成后 callback js 方法。

Cookie 丢失、无法使用问题

通过代理 document.cookie 赋值和取值动作，交由客户端来进行管理，但是这里需要额外注意一点，需要做好跨域校验，防止恶意页面对 cookie 进行修改。

遇到挑战

至此功能开发完成上线，先来一组线上收益数据，安卓开启离线情况有有 10%左右的收益，但是 iOS 开启离线的反而秒开率更低。经过修复处理后 iOS 也可提升 10%以上的秒开。

安卓和 iOS 实现差异

经过分析对比发现，安卓的拦截动作比较轻，可以判断是否需要拦截，不需要拦截可以交给 webview 自己去请求。

但是 iOS 这边一旦页面开启拦截后，页面中所有的 http 和 https 请求都会被拦截掉，由客户端发起请求进行响应，无法将请求交还给 webview 自己去发起。

iOS 缓存问题修复

页面中的资源经过客户端请求代理后原本第二次打开 webview 本身会使用缓存的内存，现在缓存也失效了，于是只能在客户端内实现了一套缓存机制。

1. 根据 http 协议来判定哪些资源可以被缓存以及缓存的时长

2. 添加自定义的控制策略，仅允许部分类型的资源进行缓存

离线包下载错误率治理

从下图可以看到离线包的下载错误率在 6% 左右浮动，这么高的下载错误率肯定是无法接受的， 经过一系列优化手段，把离线包下载错误率从 6%左右浮动下降至 0.3%左右浮动。

先来看下优化前的流程图和问题点

通过埋点发现大量 unknown host 、网络请求失败、网络连接断开的情况。分析代码发现下载未做队列控制，会同时并发下载多个离线包，从而导致多个下载任务争抢资源的情况。针对发现的问题点做出了以下优化：

1. 下载失败添加重试机制，并可动态配置重试次数用于缓解网络请求失败、网络连接断开的问题。

2. 添加下载任务队列管理功能，可动态配置并发下载数量，用于缓解不同下载任务争抢资源的问题。

3. 针对弱网和无网络情况延迟到网络良好时下载。

4. 离线包下载支持 httpdns，用于解决域名无法解析的情况。

下面是优化之后的流程图：

展望：

针对离线资源是直接存储在磁盘上的，每次访问都会有磁盘 IO 耗时，经过在低端机器上做测试发现这个耗时会在 0 - 10ms 之间进行波动，后面会把内存合理的利用起来，通过设置内存上限，文件数量上限，甚至是文件类型，并通过 LRU 策略进行内存文件的淘汰更新

接口预请求

通过客户端发起 H5 页面首屏接口请求，远比等待客户端页面初始化、下载 HTML、JS 下载执行的时机更提前，从而节省用户的首屏等待时间。在本地测试过程中发现接口预请求可提前 100+ms，用户也就可以更快的看到内容。

功能介绍

客户端会在 App 启动后获取配置，保存支持预请求的页面地址及对应的接口信息，在用户打开 webview 时，会并行发起对应预请求的接口，并保存结果。当 JS 执行开始获取首屏数据时，会先询问客户端是否已经存有对应的响应数据，如果此时已经拿到数据则无需发起请求，否则 js 也会发起接口请求并开启竞速模式。以下是整体流程图：

配置平台

那么客户端怎么知道这个页面需要请求什么接口呢？ 以及接口的参数是什么呢？ 那自然少不了配置平台，它支持以下功能：

1. 配置需要预加载的页面 url 并对应一个需要请求的 api url 以及参数

2. 配置审核功能，避免错误配置发布上线

QA

既然有了 SSR 服务端渲染为什么还需要接口预请求的功能？

首先即使是在 SSR 的情况下，首屏内容中仍然可能有部分组件是骨架直出的，需要等待页面渲染执行时才会去请求数据，另外还有一部分页面是 SPA 的。 针对这两种情况都能做到很好的补充。

预建连 &链接保活

开启后 DNS 90 分位耗时从 80ms 降至 0ms，TCP 建连 90 分位耗时从 65ms 分位耗时降为 0，DNS 平均耗时从 55ms 降为 4.3ms，TCP 建连平均耗时从 30ms 降为 2.5ms。

网络请求耗时分析

通过上图可以看到一个网络请求在经过 DNS 解析耗时、TCP 建连耗时、SSL 建连耗时阶段之后才能把请求发出去，那么是否可以节省这段时间的耗时呢？

客户端常用的网络请求框架如 OkHttp 等，都能完整支持 http1.1 与 HTTP2 的功能，也就支持连接复用。了解了这个连接复用机制优势，那就可以利用起来，比如在 APP 开屏等待的时候，就预先建立关键域名的连接，这样进入相应页面后可以更快的获取到网络请求结果，给予用户更好体验。在网络环境偏差的情况下，这种预连接理论上会有更好的效果。

实现方案

可以通过对域名链接提前发起一个 HEAD 请求从而建立链接，网络框架会自动将连接放入连接池。并在默认无操作 5 分钟后进行释放，在五分钟内重复执行上述动作即可一直保持链接。

另外这里需要注意下连接池的数量问题，如果连接池的数据太小，但是域名比较多的话，通过预建连保持的链接很容易就会被释放掉，这就需要通过域名收敛或者调大连接池的数量来进行优化。

线上收益

那预建连会不会增加服务器的压力呢？ 这个肯定是会的，首先会针对预建连功能本身就行灰度策略，在 HTML 页面通过 CDN 托管后，直接针对 cdn 域名进行全量开启，从而不用担心 cdn 域名扛不住压力。

来看一下线上效果，通过下图可以看到在开启后 DNS 90 分位耗时从 80ms 降至 0ms，TCP 建连 90 分位耗时从 65ms 分位耗时降为 0，DNS 平均耗时从 55ms 降为 4.3ms，TCP 建连平均耗时从 30ms 降为 2.5ms。

预渲染

客户端提前通过 webview 将页面渲染好，等待用户访问时，可直接展示。从而达到瞬开效果。但是这种功能肯定不能对所有的页面进行开放，而且存在一定的弊端。

1. 会额外消耗客户端资源，需要在主线程空闲时执行，并需要控制预渲染的页面数量。

2. 如果页面一进入就会下红包雨，这种页面是不适合做预渲染的，需要进行规避。

下图【开学季】是业务上已经进行预渲染的 H5 页面，可以看到在打开【开学季】页面时，页面已经渲染完毕，丝毫没有等待过程。

后面计划把这种能力放大到通用的 webview 上，针对大促以及 PV 量高的页面进行开放。

H5 优化

SSR 服务端渲染

SSR 服务端渲染（英语：server side render）一般情况下，一个 H5 页面的数据渲染完全由客户端来完成，先通过AJAX请求到页面数据并把相应的数据填充到模板，形成完整的页面来呈现给用户。而服务端渲染把数据的请求和模板的填充放在了服务端，并把渲染的完整的页面返回给客户端。

SSR 对于秒开有平均 15%的提升，既然是服务端渲染，就会对服务器造成压力，尤其是在预加载 HTML 功能开启后，那得物是如何解决的呢？

前期优化内容：

1. 接口缓存：node 服务向 ctx 中注入 redis 实例，业务方在服务端渲染的逻辑中处理接口相关的缓存，这其中涉及：配置文件下发、ab 接口。

2. 静态页面缓存：由于页面完成是无接口交互，并且所有用户展示都是一样的，由 renderToHtml 生成静态 html 资源，写入缓存。

3. 无用户状态页面缓存：此类页面大多数情况下展示内容都是一样的，服务端请求的数据也都是一致的，服务端处理的时候根据是否有用户登陆状态判断是否需要缓存。

4. 千人千面接口内容由 SSR 修改为 CSR，并显示骨架图，由于千人千面内容都是由算法接口提供，且算法接口本身响应较慢，因此通过这种方式可以减少服务端响应耗时，且能更快速的给用户展示内容。

破局者 CDN

通过这么多优化手段仍然无法满足预加载的需求，并且通过分析发现网络阶段耗时较长，最终还是搬出了 CDN 这个大杀器，一直没上 CDN 的原因有很多，主要有以下几方面：

• 得物的页面是千人千面的每个人看到的内容都不同

通过上述优化 4 即可解决，将原本 SSR 渲染的内容修改 CSR，由于已经上了 CDN 了，后续计划将这部分内容再次修改回 SSR，这样用户可以更快的看到商品而不是骨架，然后通过 CSR 的方式来更新内容。

• 页面状态变更，无法及时更新缓存

这个问题在上述客户端预加载优化部分已经有解决方案了，可以通过在页面打开后针对有需要的组件再次请求接口刷新数据以确保数据的准确性，但是这部分工作量也是比较大的，梳理出来的需要刷新状态的组件就有 30+，而且之后开发的组件都需要考虑状态更新的事情。

• HTML 模板内容变更无法及时更新

引起模板内容变更的地方有两处，第一个场景就是在搭建器场景下，运营可以动态修改模板内容导致页面结构变更（低频次），第二个场景是项目发版后模板内容需要更新（高频）。

这个问题可以通过在感知到内容变更时自动调用 CDN 服务商的刷新缓存接口来更新 CDN 缓存内容。

预渲染 HTML

通过 puppeteer 将 SPA 页面渲染出来并将 HTML 文档进行保存，配合上述页面刷新策略，并将 HTML 通过 CDN 进行托管，让你的 SPA 页面 像 SSR 一样丝滑。

主要实现方案是通过基于 webpack 的插件prerender-spa-plugin，并配置需要预渲染的路由，这样经过打包之后就会产出对应路由的页面。方案本身是通用的，但是每接入一个页面都需要人工 check。

不起眼的 css 包大小优化

众所周知 css 加载会阻塞 HTML 渲染，最终将首屏公共 css 从 118kb 缩减至 38kb，下图通过 chrome 模拟弱网环境下的 SSR 页面加载时序图。从图中可以看出 styles.fb201fce.chunk.css 下载耗时 18s，阻塞了页面的渲染，HTML 主文档耗时 2.38s 就已经下载完成了，但是实际渲染时间却是在 20s 之后。

优化思路也比较单间，将首屏所需要的 css 文件通过内联方式内嵌到 HTML 中，由 SSR 服务一并返回，并对 css 文件进行拆分，按需加载。

思路有了，接下来就看怎么去实现了，最初尝试了 MiniCssExtractPlugin 插件他可以把 css 分成单独的文件，并且每一个 js 会对应生成一个 css 文件，但是他需要建立在 webpack5 之上，然而项目中使用的 next 版本是 9.5，于是就想着升级到最新版 next12，升级后发现，在构建中其他包各种报错，发现有些包并不支持最新的 next12，在尝试一天的修复之后，仍未解决，且升级到最新版不确定是否会引发其他稳定性问题，暂且搁置寻找其他方法。

经过不懈的努力，通过阅读 next 源码发现了端倪，发现在打包时将所有的公共 css 通过 splitChunks 进行分组，由于项目中组件都是动态引入的，这里直接在 next.config.js 中修改 webpack 打包参数，将 splitChunks.cacheGroups.styles 配置删除，使用默认的 chunks: async 配置，即可实现按需引入。

图片优化

避免图片 src 为空

虽然 src 属性为空字符串，但浏览器仍然会向服务器发起一个 HTTP 请求，尤其是在 SSR 服务器压力扛不住的情况下，因此这里需要特别注意一下。

图片压缩以及格式选择

WebP 的优势体现在它具有更优的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量；同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。

通过向图片服务器传递参数选择合适的分辨率

细节优化

打包优化

• 页面组件拆分，优先加载首屏内容所需资源

• webpack splitchunks 有效拆分公共依赖，提高缓存利用率

• 组件按需加载

• Tree Shaking 缩减代码体积

非关键 js、css 延迟加载

• defer、async、动态加载 js

• iOS 设备延迟加载 js

媒体资源加载优化

• 图片、视频懒加载

• 资源压缩、通过向图片服务器传递参数选择合适的分辨率

其他资源优化

• 数据埋点上报延迟发送，不阻塞 onload 事件触发

• 自定义字体优化，使用 fontmin 生成精简的字体包

页面渲染优化

• 页面渲染时间优化

• SSR 页面首屏 css 内联(Critial CSS)

• 合理使用 Layers

• 布局抖动优化：提前定好宽高

• 减少重排重绘操作

代码层面优化

• 耗时任务分割

• 通过 Web Worker 减少主线程耗时

• 通过 RAF 回调，在线程空闲时执行代码逻辑

• 避免 css 嵌套过深

监控

为了帮助开发者更好地衡量和改进前端页面性能，W3C 性能小组引入了 Performance API ，其中 Navigation Timing API 实现了自动、精准的页面性能打点。得物前端性能监控指标也都是从 Performance API 中获取数据进行上报统计分析的。

系统架构

SDK 数据采集完毕后，会上报到 阿里云 sls 日志平台，随后通过 flink 实时消费清洗数据后落库至 clickhouse 中，平台后端通过读取 clickhouse 数据并做各种聚合处理后使用。

指标大盘

做优化之前首先要建立监控指标，互联网称之为抓手，没有监控指标的情况下，任你怎么优化，都不知道优化的效果怎么样，更不知道下一步该做什么？以及还有哪些问题没解决。因此优化之前指标先行，当然一定要指标的准确性。

指标大盘主要包含以下功能：

1. 可快速查看某段时间内的版本、设备厂商、设备名、设备系统版本以及网络占比情况，还可以根据这些字段进行筛选排查。

2. 中间区域展示了比较关注的整体以及活动页面的客户端耗时和 H5 秒开耗时的情况。

3. 底部区域展示了各业务域的秒开耗时情况。

4. 这里同时展示了平均耗时和 90 分位耗时，平均耗时有个弊端就是很容易被平均，大家应该都有被平均的经历。 90 分位耗时这里简单讲解一下：意思就是有 90%的访问耗时是低于 90 分位耗时的，以此类推 50 分位就是有 50%的访问耗时是低于 50 分位的，分位值是将所有的耗时数据从小到大排序后得出的。

白屏监控

在正常情况下，完成上述的优化措施后用户基本是可以秒开 H5 页面的了。但异常情况总是会有的，用户的网络环境和系统环境千差万别，甚至 WebView 也可能发生内部崩溃。当发生问题时，用户看到的可能就直接只是一个白屏页面了，所以进一步的优化手段就是需要去检测是否发生白屏以及相应的应对措施。

检测白屏最直观的方案就是对 WebView 进行截图，遍历截图的像素点的颜色值，如果非纯色的颜色点超过一定的阈值，就可以认为不是白屏。首先获取包含 WebView 视图的 Bitmap 对象，然后把截图缩小到指定的分辨率大小如:100*auto，遍历检测图片的像素点，当非纯色的像素点大于 5% 的时候就可以认为是非白屏的情况，但是还有很多列外的情况，我们通过图片识别技术对截图进行分析，可以很好的感知当前是否白屏、是不是在 loading、是不是特殊页面等。

白屏是一个重要的指标，我们针对整体白屏率快速拉升、新增白屏页面发出告警通知，便于开发人员及时介入开始排查问题。

性能问题发现

主要通过 CDN 未覆盖监控、http 请求监控、网络监控（加载失败、耗时异常、传输大小异常）、图片监控（未压缩、分辨率异常）等监控手段发现页面中的潜在问题，同时还提供了问题分析能力，在问题分析页面输入页面 url 地址即可帮助您发现问题并给出修改建议。

CDN 未覆盖监控

CDN 的重要性不言而喻，它可以加速资源访问速度，从而提升用户体验，我们通过对线上埋点数据分析，找出 CDN 未覆盖的资源列表，从而推动各业务同学优化。

HTTP 请求监控

为什么要监控 HTTP 请求呢？我们先来看一下 HTTPS 相对于 HTTP 新增的特点：

1. 内容加密：采用混合加密技术，中间者无法直接查看明文内容

2. 验证身份：通过证书认证客户端访问的是自己的服务器

3. 保护数据完整性：防止传输的内容被中间人冒充或者篡改

那么 HTTP 就容易被中间人查看到内容，甚至被篡改，既然如此为了我们服务的安全性就需要对现有的 http 协议统一进行升级改造，那就需要监控去发现。

网络监控

某些页面秒开率低，那就要分析一下原因，是不是这个页面的接口响应比较慢呢，还是说页面本身有请求比较大的资源？ 如果发生网络请求失败的情况也要第一时间感知，不能被动等待用户反馈。

图片监控

包含图片未压缩、图片分辨率异常、图片传输大小大于 300kb 异常、动图资源传输大小大于 1M 异常功能。

页面问题分析

上面列出来一堆功能，对于业务的同学可能比较烦恼，我一个页面具体有哪些问题呢？你不能让我去上面的功能里面一个个看，哪个异常是我负责的页面的吧？ 这个功能本身就行将现有的功能利用起来，通过一个页面 path 进行聚合分析。

异常监控

H5 异常一直是使用 sentry 进行监控的，但是 sentry 系统因缺乏同 PV、DAU 数据的关联性，因此无法衡量产品异常发生后所带来的严重程度。在业务域关联上的缺失导致异常问题无法根据业务域进行划分。用户行为日志也尚未与 Native 端侧打通，在问题分析时容易遇到上下文不全的瓶颈。还有一个问题是 sentry 会有限流措施，当 qps 较高时会丢弃一部分异常数据。

由于 sentry 已经可以帮助我们进行一定的问题排查分析能力，我们不打算做 sentry 同样的功能，而是做 sentry 不支持的部分，针对上述问题我们设计了以下功能：

• 异常问题指标衡量

• 增加异常率、页面异常率、影响用户率趋势

• 增加问题多维度(系统版本、APP 版本、H5 发布版本、网络等)下的分布占比、业务域划分

• 异常问题聚合能力增强（聚合问题能力增强）

• 异常列表支持最新新增、Top PV、异常次数、影响用户数排序

• 区分三方 sdk 异常、接口异常等不同异常类型划分

未来展望

虽然目前秒开率已经做到了 75%以上，但是同时我们还有一个重要的指标，90 分位耗时，致力于提升末尾用户 H5 页面使用体验，在 90 分位优化完成后，可能会考虑继续深入优化 95 分位耗时。

总结

最后感谢那些为得物 H5 页面秒开做出贡献的同学，感谢 H5 团队，同学们都很棒，各种优化手段和想法层出不穷。

至此我们系统的讲解了背景以及从指标建立到秒开优化上线的全过程，全文分成了三个部分，客户端、H5、以及监控。如果阅读本文对您有所收获，麻烦您动一动发财的小手点个赞吧！ 如果阅读完还意犹未尽或者有什么问题和想法欢迎留言区评论交流。

最后的最后奉上整体优化脑图：

文/XU MING

关注得物技术，做最潮技术人！