精选文章｜搭建会场下的页面性能优化

前言

App内页面秒开率是得物衡量页面加载性能的指标。我们衡量的标准即FMP。

本文主要从两方面介绍了页面性能优化的手段，一是预加载以及资源内置等依赖native的优化手段，二是web端能独立实现的一些手段，例如：ssr,资源大小等。

通过这些优化我们把会场页面的平均秒开率提高从5%到40%左右。

得物App内h5的项目都是通过webview打开。对于webview的性能大家普遍的印象就是打开速度比native慢。

对于SPA应用，一个用户打开webveiw访问h5需要经过如下过程：

1. 点击App入口（例如banner等）。

2. 到达新页面，页面白屏。

3. 页面基本框架出现（骨架屏），但是没有数据，页面处于loading状态。
   

4. 出现所有数据，页面完全呈现。

从程序执行的角度，我们来看一个没有优化过的webview加载h5的过程：

压缩每一个阶段的时间，是性能优化的关键点。

结合App的webview我们采用了两个优化手段：

• 静态资源内置：js，css等静态资源内置在App。App通过拦截请求直接返回本地文件，当然涉及到一系列的刷新缓存的策略。离线文件命中率当下在40%多。

压缩每一个阶段的时间，是性能优化的关键点。

• html预加载：App冷启动会主动拉取关键入口的html做缓存。如下图秒开率有15%的提高。

SPA会场下页面渲染整个流程：

SSR会场下页面渲染整个流程：

SPA与SSR在FMP上的表现，中间的凹槽是线上切到SPA的情况，可见SSR对于秒开有平均15%的提升。

分析页面的html。

我们发现一些js脚本 block了html的加载。

减少三个block的script的加载。

webp

webp能够达到90%压缩率，其重要性不言而喻。

现有方案在ssr直出的组件没有webp的能力。即使端上支持webp也加载了jpg或者png的图片，导致资源太大。而在ios的14版本后ios有了支持webp的能力，咨询了IOS同学，14版本的占比至少百分之七八十。

方案
node端直出所有图片都为webp。

在端上做一次webp的check，不支持则降级到原jpg或者png。

效果

不支持webp的手机：

支持webp的手机：

从图片源头上解决图片过大的问题，使用了开源方案imagemin/imagemin。

会场传图统一收口交互，避免同一张图多次上传的情况。

平均压缩率60%。

• 无用自定义组件的删除。-33k

• 按需lodash的大小。-24K

• 神策SDK 通过JS创建script加载，且解决神策sdk的命名空间前置访问。76 k

• koa-router的依赖。-21 k

• 组件按需加载。

上线后第一天优化数据

优化前

第一期优化后

结论：Lighthouse 相应提升了20%+。

优化前数据：

第一期优化后：

结论：transferred 提升了20%。

第一期优化根据各种数据汇总，性能整体提升 10%。

有些组件在node端没有直出，且没有图片懒加载的能力。

node端直出组件，且屏外的图片使用懒加载的功能。

涉及以一键领券，分会场入口等组件。

前：

后：

经过一系列的努力，App端优化与h5端的优化。

我们把页面的秒开率提高到了40%左右。