破题

做优化：有指标、有数据、有过程；
做工程：有调研、有过程、有结果。
如：用懒加载、拆包，为什么这么做？这么做有什么收益？
要有 基准测试 ，不应只会敲代码，要做一个思维敏捷之人。
一个完整的解决方案应该是：说标准，讲缘由，理过程，算结果，最后用 数据 、收益来展示成果。

审题

答题思路：

  1. 建立衡量标准：可量化的指标，数据积累，需考虑如何进行数据采集？
  2. 确认优化原因：分析优化能转化出多少价值。
  3. 实施方案
  4. 计算收益

    1. 衡量

    理论基础

    Goolge Chrome 团队提出以用户为中心的 RAIL 模型，用更多的数字维度去阐释网页性能。
    RAIL指：响应（Response），动画（Animation），浏览器空闲时间（Idle），加载（Load）。

    衡量工具

    Lighthouse：的分数反映的是业界的标准，并非项目本身实际需求的标准。
    可自行通过现有工具完成性能指标的采集。如：阿里云的ARMS ，所以在面试时，指标和指标的采集也是考点。

    采集过程

    需要采集哪些指标，常用指标如下：
  • FCP：（First Contentful Paint）首次绘制内容的耗时。起初：window.performance.timing.domComplete与window.performance.timing.domLoading的时间差，但这不具备交互意义，现在通常积累 初次加载 并绘制内容的时间。
  • TTI：（Time to Interact）是页面可交互时间。可通过window.performance.timing.domInteractive与window.performance.timing.fetchStart的时间差完成。
  • Page Load：页面完全加载时间。可通过window.performance.timing.loadEventStart与window.performance.timing.fetchStart的时间差完成。
  • FPS：前端页面帧率。通常在主线程打点完成记录。其原理是：requestAnimationFrame会在页面重绘前被调用，而 FPS 就是计算两次之间的时间差（值越小，页面越卡顿。理解：值小，说明任务多，间隙小，要不停干活）。
  • 静态资源、API请求成功率：可通过window.performance.getEntries()来获取相关信息。

以上就是衡量的理论知识，指标体系和采集方式，接下来说说如何优化。

2. 排查

优化就要定目标，指定目标的前提是，对象是谁？
在性能监控中有一个概念：TP（Top Percentile），如 TP50，TP90等等，如TP50，指 50% 用户打开页面绘制内容时间不超过 6s。
若要提升 FCP，就需提升TP低一点的数据。这就是目标。
以上采集过程中的常用指标，直接影响到 关键业务的转化率。

3. 实施

解决方案：

  • FCP：Loading，骨架屏，SSR
  • TTI：优先加载关注内容。策略上可用 异步加载、懒加载相结合。
    如：核心业务同步加载，非核心业务异步加载，图片懒加载。
  • Page Load：页面完整加载时间可通过异步加载完成。异步加载主要有 webpack 打包 common chunk 与异步组件方式完成。
  • FPS：主要代表的是卡顿情况。React 中引起卡顿主要原因是 长列表、重渲染。
    长列表方案：react-virtualized、react-window 等；
  • 静态资源、API请求成功率：CDN、升级到 HTTPS 协议

    4. 收益

    技术必须服务于业务。

    答题

    我负责的业务是 CRM 管理后台，用户付费进入操作使用，有一套非常标准的业务流程。在我做完性能优化后，整个付费率一下提升了 17%。
    前期管理后台的基础性能数据是没有的，我接手后接入了一套 APM 工具，才有了基础的性能数据。然后我对指标观察了一周多，思考了业务形态，发现其实用户对后台系统的加载速度要求并不高，但对系统的稳定性要求比较高。我也发现静态资源的加载成功率并不高，TP99 的成功率大约在 91%，这是因为静态资源直接从服务器拉取，服务器带宽形成了瓶颈，导致加载失败。我对 Webpack 的构建工作流做了改造，支持发布到 CDN，改造后 TP99 提升到了 99.9%。
    面试 - 13- 如何分析和调优性能瓶颈 - 图1