得物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

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