个人/小组工作量工单列表Inbound 进线列表与此同时使用了 Clarity 的 Copilot 工具查了一下这几个页面最近的性能我们可以看到 LCP 上确实存在严重问题这个体验确实很糟糕于是我们开始着手分析首先尝试用 AI 工具 CodeX 分析和解决了下这 2 个页面的问题并且在晚上上了一个版本。但事实证明AI 目前还无法解决前端性能问题。尽管 AI 版本没能成功解决问题但是 AI 给出了一些言之有物的方向**结论** 卡顿主因不是接口慢而是点击 查询 后前端主线程被宽表渲染/重排卡住了。 **证据** 个人工作量new /telecol/report/workload/person - 主列表接口378ms - 刷新时间接口164ms - 表格真正出现数据约 5.4s - 长任务3325ms、1644ms - 额外还夹了站内信轮询、根路径 fetch、日志上报 小组工作量new /telecol/report/workload/team - 主列表接口264ms - 刷新时间接口125ms - 表格真正出现数据约 4.6s - 长任务3036ms、1259ms - 还夹了根路径 fetch 和 Clarity 上报 这组数据说明 - 网络请求本身很快核心接口都在 400ms 内 - 但用户要等 4.6s-5.4s 才看到有效数据 - 中间被两段超长主线程任务卡住量级是 3s 1s这就是体感卡顿来源 **怎么理解** 你前面那份线上指标里 LCP/INP 高是合理的。因为真实链路是 1. 刷新页面 2. 点 查询 3. 接口很快返回 4. 前端开始渲染超宽动态表 5. 主线程被长任务占住页面长时间不响应 所以这不是“菜单切换壳层慢”也不是“单纯接口慢”而是“查询触发后的页面渲染太重”。 **顺带确认的一点** 线上当前版本在点 查询 时仍然会额外请求一次 refresh-time。这说明我本地刚做的“把 latestRefreshTime 从首屏/查询链路后移”的优化线上还没生效。 **下一步建议** 优先级直接这样排 1. 先上本地已做的减法 - refresh-time 延后 - 组织树选择器按需请求 - 宽表不再用 x: max-content 2. 继续压表格渲染成本 - 默认少渲染列 - 给动态列稳定宽度 - 把低频列折叠 - 评估表体虚拟滚动 3. 下一轮要抓 flame chart - 现在已经证明“慢在主线程” - 下一步不是再猜而是定位这 3s 长任务到底耗在 ProTable、列计算、还是 DOM layout于是第二天我们不得不手动 DEBUG 解决问题并开启“人工”智能分析。根因定位 Why?具体步骤无论是 MacOS 还是 Windows OS 这个卡顿感都是明显可见的说明跟操作系统 OS 无关然后让坐席用 Chrome 浏览器登录和我们测试用 Chrome 浏览器登录发现卡顿感也是明显可见的说明跟浏览器及其版本无关然后接口的返回速度也很正常都是 100300ms 内返回了数据说明这跟后端的接口速度无关最后这些页面的共性是都是宽表横向有许多列大概有 40 列虽然数据分页后只有 20 条说明这跟页面表格渲染有关最后结果也验证了这一点Chrome Devtools Performance Panel在 的反馈中有一个关键线索是 “一旦页面开始渲染点击 tab 切换无响应造成卡顿感强烈”实测卡顿感极其强烈于是我们开始通过 Chrome Devtools 的 Perfromance Panel 面板手动抓取上述操作路径依赖中 JS 的执行帧火焰图 (Flame Chart)分析引发卡顿感的根源火焰图从图中左下角可以发现其中主要卡顿点在 JS 执行线程跟浏览器的渲染线程上我们再细化一下只选中红色的 LongTask 看看究竟是啥导致了“卡顿”问题的发生3x LongTaskRendering: 3760msScripting: 1410ms1x LongTaskRendering: 1211 msScripting: 113msWhy? 原来是 Recalculate Style performance issuesWhy?是什么导致了这个问题Recalculate Style在它之上还有概念叫 ReflowReflow属于“重新渲染”过程中的一个关键步骤即重排布局。当页面布局发生变化时浏览器会先进行Reflow(重新算位置)然后紧接着进行Repaint(重新画到屏幕上)。所以根据上述分析我们可以得出如下结论浏览器的渲染耗时极高而且它一边计算执行 JS一遍重排Reflow Recalculate Repaint。Which那究竟是什么导致了它一直Reflow呢点进去这个火焰区块发现找到了是 isEleEllipsis 这个方法。那这个方法是干嘛的为什么继续点进去罪魁祸首这个方法的执行居然花了近 100ms 而且这个代码看起来是 ant-design 的代码要去提 ISSUE 了见 https://github.com/ant-design/ant-design/issues/57563如果界面上有 20 rows * 40 columns 800 cells那么久导致了 800 * 100ms 8s 左右的卡顿和延迟这体验确实极差。设计解决方案 How临时解决方案禁用 ellipsis: true 配置全部删除或注释掉。长期解决方案尝试升级 ant-design 的版本看新版本是否有解决这个问题。若有则无事发生。若无则维持临时解决方案且非必要不再使用ellipsis属性。测试解决方案使用上述解决方案后经测试性能变好切换很快符合预期。回顾上述提到的 AI 给出的提示中的第三步3. 下一轮要抓 flame chart - 现在已经证明“慢在主线程” - 下一步不是再猜而是定位这 3s 长任务到底耗在 ProTable、列计算、还是 DOM layout问题出现在列计算 DOM layout。