AI 对话前端性能优化
AI 对话场景下流式更新、长消息列表、Markdown 渲染和代码块展示的前端性能优化思路。
#frontend
#synthesis
#growing
[!info] related notes
AI 对话前端性能优化
AI 对话页的性能问题，通常不是普通列表页问题的简单重复，而是高频流式更新、长文本渲染和复杂块内容叠加后的结果。
一句话定义
AI 对话前端性能优化，核心是减少流式更新带来的高频重渲染，控制长消息列表和富文本渲染成本，并让界面在持续生成时仍然保持顺畅。
常见优化方向
- 合并已解析的文本增量，限制 UI 更新频率；首段与结束事件及时提交，避免批处理本身增加可见延迟
- 拆分消息组件边界
- 虚拟化长消息列表
- markdown/code block 懒处理
- 控制滚动和定位逻辑开销
最容易卡的点
- 每个 token 都触发一次大范围渲染
- 大量 markdown 反复重新解析
- 长对话列表不断增长但不做虚拟化
- 大对象 props 频繁变化
面试要点
本节保留面试回答与追问；实际优化顺序由测量确定。
一句话回答
重点通常是合并流式 chunk 更新、缩小消息组件渲染边界、对长列表做虚拟化、对 markdown 和代码高亮做懒处理，并持续监控首 token 时间、完整回答时长和交互流畅度。
最稳的回答主线
- 先说高频流式更新的问题
- 再说长列表和富文本渲染成本
- 最后补监控指标和验证方式
可以怎么展开
- 流式层：合并 chunk，避免每个 token 都触发整页刷新
- 组件层：缩小渲染边界，减少无关消息重渲染
- 内容层：对 markdown、代码高亮和大块内容做懒处理
- 列表层：长消息列表测量后考虑虚拟化；流式文本高度会变化，需保留滚动锚点，用户上翻阅读时不强制滚到底部
常见误区
- 只盯着网络时间，不看前端渲染成本
- 只讲虚拟列表，不讲流式更新频率控制
- 没有把首 token 时间和完整回答时长纳入监控
可能追问
- 你怎么判断卡顿是网络还是渲染造成的
- AI 对话页为什么比普通聊天页更容易卡
- 你会监控哪些 AI 场景特有指标
验证
使用相近长度与速率的响应，对比首段可见延迟、主线程长任务、交互响应和内存；不能只看组件 render 次数。抽查批处理后文字完整、顺序正确，末尾残留 chunk 被提交，代码块和滚动位置不抖动。
最短记忆方式
先测量，再减少无效更新、缩小渲染范围，控制长内容成本。
Digital Biome