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

性能总论

一切没有 profiling 的性能都是耍流氓。凡是真正有价值的性能优化,必定是从端到端的业务场景建立体系来考虑的。

性能体系的建立可以分成以下几部分:

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

1.现状评估和建立指标 


对于指标又要考虑两个因素。一方面,对用户来说,什么样的性能指标能更好地评估它的体验?另一方面,对公司来说,什么样的指标会影响业务价值呢?

性能问题可以分成很多方面,最重要的几个点是:

  • 页面加载性能;
  • 动画与操作性能;
  • 内存、电量消耗。

注意,这里我们仅仅是对“性能”两个字的分析和解读,在对大量的用户数据分析后,我们发现,其实这三部分中,“页面加载性能”跟用户的流失率有非常强的关联性,而用户流失率,正是公司业务非常看重的指标。

用户平均加载时间作为性能指标,但是会有严重的问题:

  • 当加载时间低于一定数字,用户体感差别不大了,我们经过一定的研究,认为这个数字大约是 1 秒;
  • 少数超长时间加载的用户(如 2G),会极大影响整个指标,即指标不能反映大多数用户的体验

所以基于以上分析,有了个新的指标——秒开率

2.技术方案


基于秒开率指标,我们可以设计技术方案,首先考虑一下如何解决这个问题。

第一用户从输入 URL 后按下回车,到底发生了什么。

  1. 从域名到 IP 地址,需要用 DNS 协议查询;
  2. HTTP 协议是用 TCP 传输的,所以会有 TCP 建立连接过程;
  3. 如果使用 HTTPS,还有有 HTTPS 交换证书;
  4. 每个网页还有图片等请求。

从这个分析和实际试验的结果看,网页的加载时间,不但跟体积有关系,还跟请求数有很大关系,因此,我们最终设计的技术方案大约可以这样划分:

前端的性能对业务数据的影响_第1张图片

这里涉及的并不仅仅是前端技术,有服务端、客户端、设计师团队,所以要想做好性能优化,绝对不能把自己限制在局部的视角,必须是整个业务一起考虑,才能有良好的收效。

3.执行


执行也不简单,如果说方案主要靠技术,那么执行就是靠工程实施了。根据公司的实际情况,工程实施可能有不同的程度,我把工程水平从低到高分成三个阶段:

纯管理:纯行政管理,是由经理用纯粹的管理手段来执行方案。纯粹管理方式容易造成执行不到位。这样的执行方式多数出现在非技术岗位。

 制度化;制度化执行方式是用规则代替人的命令,指定责任人,通过培训、checklist、定期 review 等具体措施来保证实施,但是制度化执行方式还有很大成分是依靠人的主动性的,对程序员来说,还有更好的方式:自动化。

 

 自动化。自动化的方式是在一些重要的操作路径上设置规则,针对我们的性能优化,有两个点适合做这件事:一个是把开发好的页面发布上线,另一个是开发好的页面 URL 投放到首页等处的链接。

4.结果评估和监控


执行完了之后,还要有一定的结果总结,才是一个完整的工程实施,而且,凡是工程实施,肯定要有一定长效机制,不能优化完了退化,这些都要求有线上监控机制。要想做线上监控,分两个部分:

数据采集;

同样需要发布平台或者开发工具来配合,对性能数据来说,Performance API 非常好用,它是浏览器记录的性能数据,一般来说,我们用统一的代码把它上传到服务器端就够用了。

数据展现。

可以用不同的数据可视化方案来展现性能数据,没有一定之规。一般的数据监控平台,会提供报警机制,对性能来说,报警需求不是特别强烈,但是也可以设置一些条件,针对秒开率特别低的网页报警。

结语:性能应该成为一个团队的日常工作的一部分,持续进行。

此文章为4月Day15学习笔记,内容来源于极客时间《重学前端》

你可能感兴趣的:(前端,服务器)