得物 App 内 h5 的我的项目都是通过 webview 关上。对于 webview 的性能大家广泛的印象就是关上速度比 native 慢。

对于 SPA 利用，一个用户关上 webveiw 拜访 h5 须要通过如下过程：

1. 点击 App 入口（例如 banner 等）
2. 达到新页面，页面白屏。
3. 页面根本框架呈现（骨架屏），然而没有数据，页面处于 loading 状态。
4. 呈现所有数据，页面齐全出现。

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

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

WEBVIEW

联合 App 的 webview 咱们采纳了两个优化伎俩：

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

• html 预加载：App 冷启动会被动拉取要害入口的 html 做缓存。

如下图秒开率有 15% 的进步。

H5 优化

SPA 与 SSR

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 的手机：留神头图。

无损压缩服务

从图片源头上解决图片过大的问题，应用了开源计划 imagemin/imagemin。
会场传图对立收口交互，防止同一张图屡次上传的状况。均匀压缩率 60%。

包体积

• 无用自定义组件的删除 -33k
• 按需 lodash 的大小 -24K
• 神策 SDK 通过 JS 创立 script 加载。且解决神策 sdk 的命名空间前置拜访。76 k
• koa-router 的依赖。-21 k

• 组件按需加载。
  

  总资源优化数据

  上线后第一天优化数据

  Lighthouse 打分维度剖析论断

  Lighthouse 综合打分

  优化前

第一期优化后

论断：Lighthouse 相应晋升了 20%+。

浏览器资源维度数据分析论断

优化前数据：

第一期优化后：

论断：transferred 晋升了 20%。

综合剖析论断

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

SSR 组件体验专项优化

现状

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

计划

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

成果

波及以一键领券，分会场入口等组件
前：

后：

FMP 总成果

通过一系列的致力，App 端优化与 h5 端的优化。咱们把页面的秒开率进步到了 40% 左右。

文|问问 en

关注得物技术，携手走向技术的云端