AI 对话前端性能优化
AI 对话场景下流式更新、长消息列表、Markdown 渲染和代码块展示的前端性能优化思路。
#tech / dev / frontend
#type / synthesis
#status / growing
[!info] related notes
- 所属 MOC: 前端工程化 MOC
- 相关概念: ai-chat-and-streaming-ui, ai-chat-page, ai-product-frontend-reliability, ai-frontend-monitoring-metrics, virtual-list, frontend-performance-optimization-interview-question, frontend-streaming-response-patterns
- 面试问法: ai-chat-frontend-performance-interview-question, how-to-build-streaming-ai-chat-ui-interview-question
AI 对话前端性能优化
AI 对话页的性能问题，通常不是普通列表页问题的简单重复，而是高频流式更新、长文本渲染和复杂块内容叠加后的结果。
一句话定义
AI 对话前端性能优化，核心是减少流式更新带来的高频重渲染，控制长消息列表和富文本渲染成本，并让界面在持续生成时仍然保持顺畅。
常见优化方向
- 合并 chunk 更新频率
- 拆分消息组件边界
- 虚拟化长消息列表
- markdown/code block 懒处理
- 控制滚动和定位逻辑开销
最容易卡的点
- 每个 token 都触发一次大范围渲染
- 大量 markdown 反复重新解析
- 长对话列表不断增长但不做虚拟化
- 大对象 props 频繁变化
最短记忆方式
先减少更新频率，再缩小渲染范围，最后控制长内容成本。
面试要点
来自 ai-chat-frontend-performance-interview-question 的面试视角整理。
一句话回答
重点通常是合并流式 chunk 更新、缩小消息组件渲染边界、对长列表做虚拟化、对 markdown 和代码高亮做懒处理，并持续监控首 token 时间、完整回答时长和交互流畅度。
最稳的回答主线
- 先说高频流式更新的问题
- 再说长列表和富文本渲染成本
- 最后补监控指标和验证方式
可以怎么展开
- 流式层：合并 chunk，避免每个 token 都触发整页刷新
- 组件层：缩小渲染边界，减少无关消息重渲染
- 内容层：对 markdown、代码高亮和大块内容做懒处理
- 列表层：长消息列表要考虑虚拟化和滚动策略
常见误区
- 只盯着网络时间，不看前端渲染成本
- 只讲虚拟列表，不讲流式更新频率控制
- 没有把首 token 时间和完整回答时长纳入监控
可能追问
- 你怎么判断卡顿是网络还是渲染造成的
- AI 对话页为什么比普通聊天页更容易卡
- 你会监控哪些 AI 场景特有指标
最短记忆方式
减少更新频率，缩小渲染范围，控制长内容成本。