小白也能看的懂的页面性能优化来一波

阅读 807
收藏 24
2018-01-13
原文链接:mp.weixin.qq.com

当前浏览器不支持播放音乐或语音,请在微信或其他浏览器中播放 处处吻 杨千嬅 - 电光幻影

今天跟我男朋友一起吃周五晚餐的时候

我们打赌看谁能先让对方衣食无忧

为了支持我的公众号事业

然后就让他先给我贡献了一篇技术文章

以下正文为他的原稿


 前言 

当你觉得页面很卡的时候,你有可能需要更换手机,当然也可以让对应的同学进行性能优化了。本文适用给技术小白 & 部分前端同学。

当然了,笔者在写文本之前也针对了部门内部和公司内部的部分H5页面的性能进行粗略的评估,结果当然是非常不令人满意的。或许我们忙于业务,但是有时候我们还是要停下来评估性能,不能把性能优化一直说在嘴上。

 开始正经文章 

前面也说了,页面很卡,那到底很卡是怎么一个概念的,或者是说这么去衡量一个页面很卡,大概总结了下,可以分为以下几点:

  • 页面加载出现较长时间的白屏,术语:弱网环境下量化在不能超过4s

  • 页面在加载过程中出现了明显的页面抖动或多次白屏,术语:页面重排耗能厉害

  • 移动端页面中动画出现了明显的卡顿,术语:FPS低于了40帧

  • 移动端页面在行为交互(按钮点击/页面滚动)的时候出现明显的卡顿,术语:FPS低于了40帧

当我们了解如何通过直观&客观去简单判断一个页面是否卡后,我们可以定性该页面是否需要开发同学去介入进行性能优化。那么性能优化方式又有哪些呢?

  • 页面本身及其静态资源大小减少 & 数量减少

  • 页面交互方式优化,eg:初始化禁止轮播,图片lazyload等

  • 页面视觉优化

  • 页面代码本身优化

  • 其他:太繁琐,省略1W字

但是说到具体的性能优化方案的话我们应该怎么选择,我们所产出的网站在编码方式/打包方式等等诸多方面有较大的不同,这也给我们性能优化增加很大难度。也说明了真正做好性能优化很难,就看你的预期和实际的gap。

既然说到了预期和实际的差距,我们来说说下如何快速缩小这个差距吧,而不是完全解决。特整理了以下大概的处理方法

1.砍加载时间最长的线

绿色区域表示TTFB/蓝色表示LOAD/灰色表示wait或Stalled

  • 缩小TTFB

  • 减少wait时间 -> 每次只能同时发起5个http请求,我们需要考虑我们的打包方式,该规整

  • 缩小部分大文件 -> base文件是否有冗余代码,是否可以拆解到其他文件,均匀分布

  • 合理应用gzip -> flexlbie.js gzip后文件反而大了,得不偿失

综上所属,我们必须控制打包方式,尽量减少冗余代码的加载,以及均匀分配js文件的大小,避免出现较小的js/css文件。当然了http数量方面还是需要减少,在大小和数量取时间最小值吧。最后也要说明一点的事情,部分时候我们会依赖于第三方服务,可能需要第三方的配合来优化。

2.lazyload添加和适当的交互干涉

右下角有个比较明显的1/5,即表示为轮播

原有逻辑:当页面渲染过程中会批量加载所有图片,且当js加载完毕后即执行轮播,可能会出现图片还没有显示完全即下一张

优化后的逻辑:当页面渲染完成前禁止加载未显示的图片,当页面未渲染完毕&图片未加载完毕前不进行任何轮播操作

如上的处理方式一方面优化首屏的加载大小,也保证页面过程不会因为动画执行导致页面整体渲染卡顿

3.视觉干预

白屏时间无论如何都无法避免,这个时候我们需要部分的视觉欺骗。具体方式如上图,在加载过程中给页面默认背景色,在页面开始加载时即会出现load图,这种情况下面会适当的给页面续命,预计可以让用户多等几秒

如果你处理好前面三点后,再删除一些console等冗余代码后,恭喜你,你基本上已经完成页面80%及其以上的性能提升,而且在投入产出比上面非常高,估计1-2天绝对够了,而且还是非常值得投入的。

 说在最后 

其实性能优化真的一个佛系的操作,前面的优化非常的容易,后面10-20%优化就没有底了,这种还是需要有同学有一定的前端功底,深知需要对页面进行完全颠覆重构。但是前面的优化确实可以考虑。

ps:早睡早起,常做运动,多与异性交朋友~

评论
    下载掘金客户端一个帮助开发者成长的社区
    相关文章
    下载掘金客户端一个帮助开发者成长的社区