106浏览
背景
用户场景
▪覆盖客服团队：日均处理数百会话，单会话消息量达数十条以上。
▪核心操作频率：日均查询交互区+工具区要等数据超万次，对实时性要求极高。
▪效率影响：工作台响应速度直接影响客服服务效率，卡顿或延迟可能导致单会话处理时间增加。
优化目标
618大促期间，减少客服接线过程中的无效等待时间，提高客服接线效率，保障C端用户的问题能得到及时回复。
解决方案
分析量化
监控平台
监控平台本质上采取Lighthouse进行上报，有完善的端侧性能监控体系，可以实时采集线上用户数据，便于对页面性能进行分析。
工作台对比
| 统一工作台和方圆工作台对比 | |||
|---|---|---|---|
| 工作台 | 前端模块 | 交互逻辑 | 业务复杂度 |
| 统一工作台 | 9 | 一般 | 一般，仅支持在线模式 |
| 方圆工作台 | 16 | 复杂 | 复杂，同时支持在线+语音 |
| 监控平台初始数据对比（良好/一般/较差） | |||||||
|---|---|---|---|---|---|---|---|
| 工作台 | 总分 | 首次输入延迟(FID) | 首次内容绘制(FCP) | 最大内容绘制时间(LCP 标准值为 2500ms) | 首字节耗时(TTFB) | 累积布局偏移(CLS 标准值为 0.1) | |
| 统一工作台 | 84 | 5.93 | 1068 | 2766 | 233 | 0.22 | |
| 方圆工作台 | 78 | 21.65 | 1446 | 3002 | 487 | 0.42 | |
通过对比可以看出：与统一工作台相比，方圆工作台涵盖的前端模块更多、交互逻辑和业务更复杂，在业内常用指标最大内容绘制时间(LCP）和累积布局偏移(CLS）上表现更差，对应的页面加载速度和页面布局稳定性更不理想，需要对其针对性优化。
数据收集
为了解决方圆工作台线上数据少的问题，自研无头浏览器工具，模拟客服接线的真实场景，自动化批量跑测性能指标，上报监控平台分析。
| 流程图 |
|
优化步骤&成果
| 优化步骤 | 方圆工作台监控平台分数 | 细节指标对比 |
LCP优化：接口请求治理：梳理全量http接口127 个 ，通过监控平台的请求总览看板，对高异常占比请求的根因排查与系统性优化 20个，针对非交互类功能的相关 4个接口实现WebSocket 消息通道标准化改造。接口时序调整：梳理页面加载流程，延后非关键接口，调整为优先加载用户信息接口并触发IM模块渲染。懒加载策略调整：移除 IM 模块的懒加载，交互响应速度提升。通过Performance分析，对一些非必要资源（进线提示音等wav文件）实行懒加载和避免重复加载。预加载机制：通过监控平台的静态资源监控看板，对耗时资源添加prefetch标签，实现关键资源的预加载。CLS优化：固定布局：通过Lighthouse分析，找到影响页面CLS的body元素和IM模块（会话列表+聊天区），通过设置初始宽度，避免动态加载时的页面抖动。技术架构优化：通信方案：封装socrates-micro-bus实现跨应用消息收发，通过规范收发消息类型，提高代码可维护性。通道SDK：socrates-websocket统一 WebSocket 连接管理，一套代码，多端（工作台、h5、pc）运行，提高开发效率和生产质量。HTTP库：socrates-http为各个项目的http请求提供标准化能力。 | 78 => 93 | CLS: 0.42 => 0.08 LCP: 3002 => 2302 |
总结与展望
总结：核心指标全面超越在线工作台：LCP 下降 23%，CLS 下降81%，客服反馈操作流畅度提升显著。
展望：当前优化重点聚焦于页面加载性能提升，后续将结合 FPS、CPU 占用率、内存消耗等多维度性能指标，针对客服工作台从加载完成到操作交互的全流程体验进行深度优化
