速度优化起始篇

随着业务的发展,终于要开始搞速度优化了,很久之前以运维的身份参与过一定时间的速度优化项目,现在以研发的身份再参与一次,体会下不同的角度不同的方法

为什么要进行速度优化

  • Amazon每增加100ms 收入下降1%;
  • Yahoo每降低400ms的加载时间,他们的访问量就提升9%
  • Mozilla将他们的页面速度提升了2.2s,每年多获得了1.6亿下载量
  • 搜索首屏时间每增加300ms 无点击比例上升1%

一般情况下认为移动端用户对访问速度的比PC端高,但是也有界限
用户体验:<2s,响应快;2~5s,还可以;5~8s,慢,还可以接受;>8s,流失

总结下就是

  1. 用户访问速度对用户体验至关重要
  2. 用户访问速度快慢影响收入

优化的目标是什么

对于PC产品速度指标以1s为界限,移动端产品速度如上所述至少在2s内,最好能在1.5s内,能达到1s内就是完美

这里指的时间都是按80分位值计算

面临的挑战是什么

  • 移动网络复杂不稳定的网络情况会带来很多不可控因素
  • 业务早期粗放的发展模式积累了大量性能低下的代码
  • 投入人力有限运维配合程度低,能获取到系统资源有限

速度优化被安排的职责

  1. 负责团队用户可见组件(及其依赖)的性能评判
  2. 负责性能优化方案的调研和制定,并逐步在实践中形成一些 设计和开发规范
  3. 负责定期CR线上服务代码,及时发现可优化的代码段,并发起优化流程直至优化完成
  4. 参与核心模块和所有C端模块的设计评审,发现问题并给出指导意见
  5. 组织定期的学习和分享(每个Q一次,在评判结果announce之后),提升整个团队的性能优化能力
  6. 配合QA制定性能测试方案,根据测试结果提出优化方案,并跟进到底直至落地到线上
  7. 带领所有同学养成看性能数据的日常习惯,根据服务性能的各项指标及早的发现和解决问题,避免问题放大

杂七杂八的事情不少呵呵。

速度优化任务拆解

全盘摸底,只知道慢,有多慢,慢在什么环节,要尽快分析下,并且建立速度的监控体系,速度性能要直观可见,速度优化结果要有理可依,TODO:

  • 指定性能评判标准
  • 建立速度指标监控
  • 对目前问题作出详尽的分析

快速调研下各种优化方案,这个公司内部做过的太多了,各种前后端方案能快速迁移的方案就快速迁移,TODO:

  • 公司内外速度优化方案调研

流程规范下,之前更多的关注的是业务层面的事情,性能问题除非异常恶劣,研发测试都很少关注,要改变下流程和制度:

  • 梳理前后端重要页面接口,QA加入性能测试
  • 系统设计过评审

起始篇到此为止,后续记录具体的工作