两周让 Claude.ai 快3倍：Anthropic 的前端性能优化实践

引言：AI 产品的速度也是护城河

当大模型能力逐渐趋同，用户体验中的响应速度正成为衡量 AI 产品竞争力的关键指标。Anthropic 团队在一篇题为《How we made claude.ai 3x faster in two weeks》的分享中透露，他们仅用两周时间就把 claude.ai 的整体性能提升了约 3 倍。这一话题在 Hacker News 上引发讨论（51 分、12 条评论），也让不少开发者重新审视：AI 应用的性能瓶颈，往往并不只在模型本身。

需要说明的是，本文基于该分享的核心议题展开解读。由于原始素材信息有限，部分技术细节属于结合前端工程通用实践的分析，供读者参考。

为什么 AI 应用会“变慢”

Claude.ai 这类对话式产品有一个天然的性能挑战：它既是一个重交互的前端应用，又要实时处理来自大模型的流式输出。这意味着性能问题可能来自多个层面。

模型推理延迟是最直观的部分，但用户感知到的“慢”常常并非全部来自模型。前端渲染、消息列表的重复渲染、Markdown 与代码高亮的解析开销、长对话历史的内存占用，都会在累积后显著拖慢体验。尤其当一段对话包含数十条消息、大量代码块和数学公式时，浏览器端的渲染压力会成倍放大。

换句话说，“让 Claude 变快”并不等于“让模型变快”，而是一次系统性的工程优化。

性能优化的常见突破口

对于 claude.ai 这样的流式对话应用，两周内实现数倍提速，通常意味着团队抓住了几个高杠杆的优化点。

减少不必要的重渲染

对话应用最典型的陷阱，是每接收一个流式 token 就触发整个消息列表的重新渲染。随着对话变长，这种开销呈线性甚至更高增长。通过组件记忆化（memoization）、精细化状态拆分、将正在流式输出的消息与历史消息隔离渲染，可以大幅降低每一帧的计算量。

组件记忆化（memoization）是 React 等现代前端框架中的核心优化手段。以 React 为例，React.memo、useMemo 和 useCallback 可以让组件在 props 未变化时跳过重新渲染。在流式对话场景中，如果消息列表的每条历史消息都被包裹在 memo 中，当新 token 到来时，只有当前正在生成的消息组件会触发更新，其余已完成的消息保持静止。状态拆分则进一步将"正在流式生成的内容"与"已完成的对话历史"拆分为不同的状态节点，使两者的更新互不干扰。这两种手段组合使用，能将每次 token 到达时的渲染范围从整个消息列表压缩到单一组件，对长对话场景的性能改善尤为显著。

优化流式输出的处理

流式输出如果按字符逐个更新 DOM，会造成频繁的布局与重绘。批量合并 token 更新、使用 requestAnimationFrame 节流、对 Markdown 解析做增量处理，都是常见且有效的手段。

requestAnimationFrame（rAF）是浏览器提供的一个 API，它允许开发者将 DOM 更新与浏览器的屏幕刷新周期（通常为 60fps，即约 16ms 一帧）对齐。大模型的流式输出速度可能远超屏幕刷新率——模型每秒可能吐出数十甚至上百个 token，若每个 token 都立即触发 DOM 写入，每秒会产生大量无效的中间渲染，其中大多数帧在被显示之前就已被下一次更新覆盖。通过 rAF 节流，可以将多个 token 的更新合并到同一帧中统一写入 DOM，既减少了浏览器的布局与重绘次数，又不会让用户感知到视觉上的卡顿。增量 Markdown 解析则是另一个配合手段：避免每帧都对完整文本从头解析，而是只处理新增的片段，将解析开销从 O(n) 降低到接近 O(1)。

首屏与资源加载

代码分割、延迟加载非关键组件（如设置面板、历史侧边栏）、优化打包体积，能显著缩短用户从打开页面到可交互的时间。对于全球化产品，CDN 与缓存策略同样是提速的重要一环。

代码分割（Code Splitting）是现代前端构建工具（如 Webpack、Vite）的核心能力，其原理是将应用的 JavaScript 打包产物按路由或功能模块拆分为多个较小的 chunk，用户访问时只下载当前页面所需的代码，其余部分在需要时才按需加载。对于 claude.ai 这类功能复杂的应用，设置面板、历史记录侧边栏、文件上传模块等非核心功能都是适合延迟加载的候选对象。CDN（内容分发网络）则通过在全球部署边缘节点，将静态资源缓存到距离用户最近的服务器，减少网络传输的物理延迟。两者结合，能有效将首屏可交互时间（TTI，Time to Interactive）从数秒压缩到一秒以内，对全球用户的体验提升尤为明显。

“两周”背后的工程启示

值得关注的不只是“3 倍”这个数字，而是它在两周内完成的事实。这通常说明团队做到了两件事。

第一，有可靠的性能测量。没有基线数据，就无法判断哪里是真正的瓶颈。专业团队会先建立性能监控与 profiling，用数据定位问题，而不是凭直觉优化。

第二，优先处理高杠杆问题。两周时间不足以重构整个系统，能取得 3 倍提升，往往是因为找到了少数几个影响最大的瓶颈——而这正符合性能优化中“80% 的收益来自 20% 的改动”这一经验规律。

对开发者的实际参考价值

对于正在构建 AI 应用的团队，Anthropic 的这次分享提供了几点可迁移的思路：

不要默认“慢”都是模型的问题，前端渲染同样可能是主要瓶颈。
建立性能基线和监控，让优化有据可依。
流式 UI 是对话产品的性能重灾区，值得投入专门优化。
小步快跑、聚焦高影响改动，往往比大规模重构更快见效。

随着 AI 产品竞争进入体验细节的比拼阶段，谁能让用户“用得更顺手”，谁就更可能留住用户。速度，正是这种体验中最容易被感知、也最值得投入的维度之一。

结语

Claude.ai 两周提速 3 倍的案例，提醒行业一个容易被忽视的事实：在 AI 产品中，工程能力与模型能力同样重要。当模型能力成为“标配”，扎实的前端与系统优化，反而可能成为拉开差距的关键。