一、统计维度分析
页面渲染过程：
按钮点击渲染过程：
由上面的渲染过程可以将统计时间维度分为：
首次渲染：浏览器发起请求、资源下载到渲染页面的时间（按钮和子页面不存在下载资源）
ajax 请求：与后台交互的时间
页面加载：页面从打开到用户可交互的时间总和
通过js代理埋点的方式，使用 google analytics，对所有页面进行全局埋点；
二、GA 结果分析
通过对 GA 数据的详细分析，得到访问量最高的页面以及按钮：
- 统计分析_页面访问统计_页面
- 统计分析_页面访问统计_按钮 (下图展示事件数> 1000 的结果)
首次渲染：首次访问该页面，页面内资源需要从服务器远端下载到本地浏览器，资源下载完成，同时初始化渲染 dom 所消耗的时间
ajax 请求：页面初步渲染完成之后，开始请求后台数据，从请求开始到数据返回的时间
页面加载：进入页面 - 加载资源 - 渲染 dom - ajax 请求 - 二次渲染 ，即页面从进入到彻底加载完成，可响应用户输入的总时间
三、当前系统架构
首次渲染
现状
- 节目管理和节目录制管理为一级界面，会存在首次渲染的耗时，每个页面的资源均为全量引入（13 个 css 文件、32 个 js 文件），加载到渲染平均耗时为 3.5s 左右
分析
- 页面加载冗余资源文件过多
- 国内访问 aws 服务器延时高，访问速度慢
优化方向
- 优化资源文件，初始加载只引入必须的 js 和 css 文件
- 使用 CDN 优化资源文件的下载
- 使用永久缓存方案代替 304 协商缓存
ajax 请求
现状
- 节目管理和子节目页面，ajax 请求耗时过长，平均耗时为 5s 左右
分析
- 页面加载数据之前，需要发起 20 次左右的不同数据库字典的请求
- ajax 存在串行请求的情况
优化方向
- 增加并行度，对必须串行的后端进行整合优化
- 优化后端服务本身的性能
页面加载
现状
- 页面加载时间均耗时过长，其中节目录制管理平均耗时10s左右、节目管理8s左右、子节目管理27s左右
分析
目前系统采用了jquery + bootstrap + vue(仅使用了国际化方案)，该架构对页面的渲染方式是直接操作dom元素
每次操作dom元素，浏览器都会从构建DOM树开始从头到尾执行一遍流程。比如当你在一次操作时，需要更新10个DOM节点，理想状态是一次性构建完DOM树，再执行后续操作。但浏览器没这么智能，收到第一个更新DOM请求后，并不知道后续还有9次更新操作，因此会马上执行流程，最终执行10次流程。显然例如计算DOM节点的坐标值等都是白白浪费性能，可能这次计算完，紧接着的下一个DOM更新请求，这个节点的坐标值就变了，前面的一次计算是无用功。即使计算机硬件一直在更新迭代，操作DOM的代价仍旧是昂贵的，频繁操作还是会出现页面卡顿，影响用户的体验。
优化方向
- 采用新的MVVM架构方案，通过虚拟DOM，减少对真正DOM的操作频次；
四、改进目标
根据网站优化的 2-5-8 原则：去除网络延时的影响的前提下，简单页面渲染时间低于 2 秒；复杂数据页面渲染时间低于 5s；不能超过 8s；
- 初始渲染，资源文件 (css、js) 加载由 45 个减少到 6~8 个，其余资源文件根据页面按需动态加载；
- dom 渲染由百次减少到十次以下；
支持组件化复用、估计整体开发效率提高 30%（随着组件化的积累，最后页面 UI 变成组件的拼装，前端开发只关注业务后，效率最高提升 50%）；
五、架构改进方案
六、分步实施方案
新的架构升级方案，能够和旧架构并行存在，支持单个页面升级；
https://www.processon.com/diagraming/5d410d3de4b0b3e4dcd92a13