随着业务的发展，终于要开始搞速度优化了，很久之前以运维的身份参与过一定时间的速度优化项目，现在以研发的身份再参与一次，体会下不同的角度不同的方法
为什么要进行速度优化
- Amazon每增加100ms 收入下降1%;
- Yahoo每降低400ms的加载时间，他们的访问量就提升9%
- Mozilla将他们的页面速度提升了2.2s，每年多获得了1.6亿下载量
- 搜索首屏时间每增加300ms 无点击比例上升1%
一般情况下认为移动端用户对访问速度的比PC端高，但是也有界限
用户体验：<2s，响应快；2~5s，还可以；5~8s，慢，还可以接受；>8s，流失
总结下就是
- 用户访问速度对用户体验至关重要
- 用户访问速度快慢影响收入
优化的目标是什么
对于PC产品速度指标以1s为界限，移动端产品速度如上所述至少在2s内，最好能在1.5s内，能达到1s内就是完美
这里指的时间都是按80分位值计算
面临的挑战是什么
- 移动网络复杂不稳定的网络情况会带来很多不可控因素
- 业务早期粗放的发展模式积累了大量性能低下的代码
- 投入人力有限运维配合程度低，能获取到系统资源有限
速度优化被安排的职责
- 负责团队用户可见组件(及其依赖)的性能评判
- 负责性能优化方案的调研和制定，并逐步在实践中形成一些 设计和开发规范
- 负责定期CR线上服务代码，及时发现可优化的代码段，并发起优化流程直至优化完成
- 参与核心模块和所有C端模块的设计评审，发现问题并给出指导意见
- 组织定期的学习和分享(每个Q一次，在评判结果announce之后），提升整个团队的性能优化能力
- 配合QA制定性能测试方案，根据测试结果提出优化方案，并跟进到底直至落地到线上
- 带领所有同学养成看性能数据的日常习惯，根据服务性能的各项指标及早的发现和解决问题，避免问题放大
杂七杂八的事情不少呵呵。
速度优化任务拆解
全盘摸底，只知道慢，有多慢，慢在什么环节，要尽快分析下，并且建立速度的监控体系，速度性能要直观可见，速度优化结果要有理可依，TODO：
- 指定性能评判标准
- 建立速度指标监控
- 对目前问题作出详尽的分析
快速调研下各种优化方案，这个公司内部做过的太多了，各种前后端方案能快速迁移的方案就快速迁移，TODO：
- 公司内外速度优化方案调研
流程规范下，之前更多的关注的是业务层面的事情，性能问题除非异常恶劣，研发测试都很少关注，要改变下流程和制度:
- 梳理前后端重要页面接口，QA加入性能测试
- 系统设计过评审
起始篇到此为止，后续记录具体的工作