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

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

本文转自网络，版权归原作者所有，原文链接：https://segmentfault.com/a/1190000040044459
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！