前端性能对业务数据的影响

  开题之前,思考以下三个性能比较:

for循环for循环 哪个更快?
Math.floor 是否比 |0 更好?
多个 if-else 是否要用 switch-case 替代?

  前端发展至此,前端性能随之变成了一个很有意思的话题。从入门级别的初级工程师,到高级别的专家,都离不开性能问题。那么前端性能该如何理解呢?

总论

  前端时间学习前淘宝前端总负责人winter的课程,受益颇深。前面三个性能比较的例子,在社区或者论坛中大家对此的讨论从未断过,也乐此不疲。但是,它们出了让你写代码的时候纠结之外,毫无意义。
  比如,在写业务的时候,某一个功能模块有数据操作,千方百计的将某个循环操作优化了,可能执行效率提高了一倍。可是在整体来看,页面打开速度一样,用户也没有任何良好反馈,甚至测试都毫无察觉。因此,性能优化不能局限于局部代码。用大佬winter的话来讲,就是一切没有profiling的性能都是耍流氓。凡是真正有价值的性能优化,必定是从端到端的业务场景建立体系来考虑的。

流程分析

  那么我们从何入手,又该怎样考虑和执行呢?总结如下:

  • 现状评估和建立指标
  • 技术方案
  • 执行
  • 结果评估和监控

1. 现状评估

  此处,要解决的问题有两个:

  1. 从用户体验来讲,什么样的性能指标能更好的评估产品的体验?
  2. 对公司来说,什么样的指标会影响到公司业务价值?

  性能问题大致分为三个层次:

  • 页面加载;
  • 动画与操作;
  • 内存,电耗;

2. 建立指标

  从这三个方面来看,如果一个页面在经历了几秒的白屏才打开,那注定用户流失率会极其高。而用户流失率是公司所注重的,因此页面加载则是重中之重。因此,需要大量评测页面加载时常对用户的影响。大量数据表示,加载时间在1s以内,差别都不大。因此首要就是正常网络状况下,加载时长要优化至1s以内。但是会碰到一个新的问题,就是少数极端网络用户(如2g网络)加载时间会极长,在统计后,会极大的拉低平均加载时长,从而影响整体的指标。因此,指标不能反应大多数的用户体验。因此,他们团队提出——秒开率:一秒之内能打开的用户占总用户的比重。

3. 技术方案

  有了目标,便需要以技术手段去解决问题了。在课程中,winter将技术方案有了一个比较系统的划分:

  • 缓存: 客户端的强缓存策略
  • 降低请求成本:
    1. HTTP DNS: 由客户端控制,隔一段时间主动请求DNS获取域名IP,不走系统的DNS
    2. TCP/TLS连接复用:由服务端升级到HTTP2,并尽量合并域名
  • 减少请求数:
    1. JS,CSS打包到HTML
    2. JS控制图片异步加载、懒加载
    3. 小图用data-url
  • 减少传输体积:
    1. 尽量使用svg/gradient等代替图片
    2. 根据机型和网络状况控制图片清晰度
    3. 对低清晰图片使用锐化来提升用户体验
    4. 设计上避免大型背景图

  以上列出的仅仅是部分技术方案事例,但是可见,需要产品、设计、服务端等多方面的协作去完成。因此,性能优化一定是团队事件,而不是有着局限性的个人模块。

4. 执行

  有了方案就要贯彻执行。一个良好的团队,一定有高强度执行力。当然,执行一样不简单。方案靠技术,那执行则靠工程了。
  三个阶段工程水平从低到高如下,而结合多数公司现状,由于自动化成本过高,因此建议制度化+自动化搭配执行,以求高效率高质量。

  1. 纯管理
  2. 制度化
  3. 自动化

5. 结果评估和监控

  一个阶段的工程实施,必定要有阶段性的工程结果和总结。而结果总结并不意味着是最终答卷。此过程是一个长期过程,而分割为多个短期节点或者里程碑。这就要求不光要有结果,还要不断优化,不断更新。那就意味着,我们还需要做好线上监控。线上监控要做好,两个数据不可少:

  1. 数据采集
  2. 数据展现

总而言之

  总而言之,性能的优化,应该基于公司实际业务和实际的用户需求体验而做的一种工程实施,而不是单纯的技术游戏。

参考:《极客时间》之《重学前端》

---本文结束感谢您的阅读---

本文标题:前端性能对业务数据的影响

文章作者:Lomo 朱幸民

发布时间:2019年07月27日 - 11:30:00

最后更新:2019年07月27日 - 15:51:16

原始链接:https://www.zhuxingmin.com/2019/07/27/前端性能对业务数据的影响/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

请作者喝杯咖啡吧~
0%