去掉一层东西，Claude.ai直接快了 65%

文章目录

1、前言
2、到底升级了什么？
- [2.1 一句话总结](#2.1 一句话总结)
- [2.2 新旧架构对比](#2.2 新旧架构对比)
- [2.3 性能提升数据](#2.3 性能提升数据)
3、为什么要动这一刀？
- [3.1 SSR 对 Claude.ai 来说是错误的选择](#3.1 SSR 对 Claude.ai 来说是错误的选择)
- [3.2 SSR 回潮的历史背景](#3.2 SSR 回潮的历史背景)
- [3.3 也有不同的声音](#3.3 也有不同的声音)
4、新架构技术栈详解
- [4.1 Vite：不只是构建工具](#4.1 Vite：不只是构建工具)
- [4.2 TanStack Router：类型安全的客户端路由](#4.2 TanStack Router：类型安全的客户端路由)
- [4.3 边缘 Workers：离用户最近的地方](#4.3 边缘 Workers：离用户最近的地方)
5、更大的趋势：前端架构的集体"轻量化"转向
- [5.1 Cloudflare 的 vinext：用 Vite 重写 Next.js](#5.1 Cloudflare 的 vinext：用 Vite 重写 Next.js)
- [5.2 "回归 SPA" 的理性回归](#5.2 "回归 SPA" 的理性回归)
6、我的看法
- [6.1 这不是 Vite 的胜利，是"用对架构"的胜利](#6.1 这不是 Vite 的胜利，是"用对架构"的胜利)
- [6.2 AI 产品的前端体验被严重低估了](#6.2 AI 产品的前端体验被严重低估了)
- [6.3 技术选型要基于场景，不要跟风](#6.3 技术选型要基于场景，不要跟风)
- [6.4 Vite 的崛起代表了一种更健康的工具链哲学](#6.4 Vite 的崛起代表了一种更健康的工具链哲学)
- [6.5 关于未来的一点预判](#6.5 关于未来的一点预判)
7、总结

🍃作者介绍：AI 应用工程师 / 产品架构师，阿里云专家博主。Java 后端出身，现专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。

🦅个人主页：@逐梦苍穹

🐼GitHub主页：https://github.com/XZL-CODE

✈ 您的一键三连，是我创作的最大动力🌹

1、前言

3 月 20 日，Anthropic 工程师 Felix Rieseberg 发了一条推文，在前端圈掀起了不小的波澜：

"We moved our architecture from SSR to a static Vite + TanStack Router setup that we can serve straight from workers at the edge. Time to first byte is down 65% at p75, prompts show up 50% sooner, navigation is snappier."

翻译过来就是：Claude.ai 和桌面端应用把前端架构从 SSR 切换到了 Vite + TanStack Router 的静态方案，直接部署到边缘 Workers 上。p75 的 TTFB 下降 65%，提示词展示速度提升 50%，导航更快了。

Vue 和 Vite 的作者尤雨溪第一时间转发，配了一句 "Claude.ai now powered by Vite"，颇有一种"实至名归"的味道。

这件事之所以值得写一篇文章来聊，不只是因为性能数据好看，更因为它背后折射出一个正在发生的行业转向：前端架构正在经历一次集体"轻量化"回归，而 Vite 正站在这场变革的中心。

作为一个日常重度使用 Claude 的 AI 应用工程师，我对这次升级有不少想说的。

2、到底升级了什么？

2.1 一句话总结

Claude.ai 前端从 SSR（服务端渲染）架构 迁移到了 Vite + TanStack Router 的纯客户端 SPA 架构，静态资源直接部署到边缘 Workers 节点。

名词速查（后文会详细展开，这里先建立基本认知）：

SSR（Server-Side Rendering，服务端渲染）：每次用户访问页面时，服务器先执行代码生成完整 HTML，再发送给浏览器。优点是搜索引擎能直接抓取内容，缺点是每次请求都有服务端计算开销。

SPA（Single Page Application，单页应用）：浏览器只加载一次 HTML，后续所有页面切换都由 JavaScript 在客户端完成，不再请求服务器生成新页面。交互流畅但首次加载稍慢，且搜索引擎不易抓取。

SSG（Static Site Generation，静态站点生成）：在构建阶段（而非用户请求时）就把所有页面预先生成好，部署时只需分发静态文件。速度最快，但内容更新需要重新构建。

SEO（Search Engine Optimization，搜索引擎优化）：让网站内容更容易被 Google、百度等搜索引擎发现和收录的技术手段。SSR 和 SSG 天然对 SEO 友好，SPA 则需要额外处理。

CDN（Content Delivery Network，内容分发网络）：将静态资源（HTML/JS/CSS/图片）缓存到全球各地的边缘节点，用户访问时从最近的节点获取，大幅降低延迟。

TTFB（Time To First Byte，首字节时间）：从用户发起请求到浏览器收到第一个字节的耗时，是衡量网站响应速度最基础的指标。

2.2 新旧架构对比

用表格拆开来看：

维度	旧架构 (SSR)	新架构 (Vite SPA)
渲染方式	服务端渲染，每次请求服务器执行 React 渲染逻辑	客户端渲染，浏览器直接运行 JS
构建工具	大概率是 Next.js	Vite（目前最新 Vite 8 已集成 Rolldown）
路由方案	Next.js 文件路由	TanStack Router（类型安全 + 客户端路由）
部署方式	需要 SSR 服务器节点	静态文件直接推送到边缘 CDN Workers
首字节时间	包含服务端渲染计算开销	边缘节点直接返回预编译 HTML，几乎零计算

2.3 性能提升数据

Felix 公布的三组关键数据：

指标	提升幅度	含义
TTFB (P75)	下降 65%	75% 的用户白屏时间砍掉近三分之二
提示词展示速度	提升 50%	用户输入问题后，更快看到 AI 开始回复
页面导航	明显更快	切换对话、跳转页面的响应速度显著改善

P75 的 TTFB 下降 65%，这个数据很夸张。TTFB 是衡量 Web 性能最基础的指标之一，反映的是从用户发起请求到浏览器收到第一个字节的耗时。SSR 架构下这个时间包含服务器执行渲染逻辑的开销，而静态部署方案下，边缘节点直接返回预编译好的文件，中间几乎没有计算过程。

根据 2025 年的基准测试数据，传统 SSR 未缓存的 TTFB 通常在 200-900ms 之间，而 SSG（静态站点生成）+ CDN 缓存命中的 TTFB 仅需 20-50ms。Claude.ai 这次 65% 的降幅，完全符合从 SSR 切到静态边缘部署的预期收益区间。

3、为什么要动这一刀？

3.1 SSR 对 Claude.ai 来说是错误的选择

这是整件事最核心的问题：Claude.ai 本来就不该用 SSR。

SSR 的核心优势是什么？

SEO 友好：搜索引擎可以直接抓取渲染好的 HTML
首屏直出：用户不需要等 JS 执行就能看到内容

但 Claude.ai 的场景是什么？

用户登录后才能使用，对话内容是私有的，不需要 SEO
核心交互是在一个长时间运行的会话里打字、等 AI 回复、切换对话
需要 WebSocket 长连接 （一种在浏览器和服务器之间建立的持久双向通信通道，不同于传统的"请求-响应"模式，服务器可以主动向浏览器推送数据）和实时流式输出
交互模式极度 SPA 化------用户几乎不会刷新页面

在这种场景下，SSR 的优势完全派不上用场，反而带来了额外的服务端计算开销。每次页面请求都要经过一台服务器执行 React 渲染逻辑，再把 HTML 发给浏览器，浏览器还要做一次 Hydration（注水，即把服务端渲染的静态 HTML "激活"为可交互的 React 应用，需要重新绑定事件监听器等）才能交互。这就是典型的"用了不该用的架构"。

评论区有开发者直接吐槽：

"到底是谁决定在 Claude.ai 上用 SSR 的？我真的很惊讶，做出世界上最好 AI 模型的团队，居然会做出像初级工程师一样的架构决策。"

虽然话说得有点刻薄，但从技术角度看确实不算冤枉。

3.2 SSR 回潮的历史背景

要理解为什么 Claude.ai 一开始会选 SSR，需要看一下前端架构的历史演变：

阶段	时间	主流观点
SPA 时代	2013-2019	React/Angular/Vue SPA 是现代前端的正确方式
SSR 回潮	2019-2022	Next.js 引领 SSR，Jamstack（JavaScript + API + Markup 的架构理念，强调前端预构建 + API 调用，而非传统服务端渲染）成为主流范式
SSR 极端化	2022-2023	RSC（React Server Components，React 服务端组件）+ Server Actions，一切都应该在服务端
理性回归	2024-2025	承认场景差异，SPA 在特定场景无可替代

在 2022-2023 年那个时间窗口，Next.js 推动的 SSR/RSC 叙事几乎成了"政治正确"。很多团队在没有认真评估自身场景的情况下，就默认选择了 Next.js + SSR。Claude.ai 大概率就是在这个背景下做出的初始技术选型。

3.3 也有不同的声音

当然也有冷静的观点。一位叫 Rhys Sullivan 的开发者指出：

"Next.js 并不强制你使用 SSR，它同样可以输出静态页面、从 CDN 分发。Claude.ai 之前性能不好，未必是 Next.js 的锅，可能只是用错了模式。"

这个观点很中肯。SSR vs SPA 从来不是非黑即白的问题。关键在于你的产品形态是否真的需要服务端渲染。 Claude.ai 这个案例之所以效果这么明显，恰恰是因为它本来就不适合 SSR，迁移到纯静态方案后自然能释放出大量性能空间。

4、新架构技术栈详解

4.1 Vite：不只是构建工具

Vite 在这次迁移中承担的是构建工具 + 开发服务器的角色，替代了原有的 SSR 框架。

但现在的 Vite 已经远不止是一个构建工具了。随着 2026 年 3 月 Vite 8.0 的正式发布，Rolldown（基于 Rust 的打包器）已经完全替代了原来的 esbuild + Rollup 双引擎架构，形成了 Vite + Rolldown + OXC（Oxidation Compiler，基于 Rust 编写的高性能 JavaScript 编译工具集，包含解析器、代码转换器和压缩器） 的端到端 Rust 工具链。

一些关键数据：

指标	数据
NPM（Node Package Manager，JavaScript 包管理器）周下载量	5000 万+
构建速度提升（vs Rollup）	10-30 倍
真实项目案例：Excalidraw	22.9s → 1.4s（16x）
真实项目案例：Linear	46s → 6s（87% 减少）
真实项目案例：GitLab 内存占用	降低 100 倍
使用企业	Google、Apple、Microsoft、OpenAI、Anthropic、Shopify、Cloudflare
State of JS 2024 满意度	第一名，95%

尤雨溪在 2024 年 10 月创立了 VoidZero 公司，获得 460 万美元种子轮融资，愿景是 "为 JavaScript 生态系统构建一个开源、高性能、统一的开发工具链"。Vite 8 的发布被他称为 "Vite 2 以来最重要的架构变革"。

从生态覆盖来看，几乎所有主流前端框架都已经拥抱 Vite：Vue/Nuxt、React/Remix、Svelte/SvelteKit、Astro、Solid、Angular、TanStack Start、Ember... 这不是某个框架的胜利，而是整个前端工具链的一次代际升级。

4.2 TanStack Router：类型安全的客户端路由

TanStack Router 在这次迁移中负责客户端路由，取代了 Next.js 的文件路由系统。

它最大的特点是类型安全程度极高------路由参数、搜索参数、loader 返回值全部在编译期自动推断，IDE 会在你拼错路由参数时直接报红。

核心特性：

特性	说明
类型安全路由	全自动推断，编译期保证，IDE 实时报错
文件路由	配合 Vite 插件，零配置生成类型化路由树
自动代码分割	路由自动拆分为关键部分和懒加载部分
内置数据加载	loader + SWR（Stale-While-Revalidate，一种缓存策略：先返回缓存的旧数据让页面快速展示，同时在后台重新请求最新数据）缓存，消除请求瀑布流
搜索参数一等公民	URL 即状态，支持 Zod（TypeScript 的运行时类型校验库，可以定义数据结构并自动校验）验证，可通过链接分享

对比 React Router：

维度	TanStack Router	React Router
类型安全	全自动推断	需手动注解
代码分割	自动（插件支持）	需手动配置
搜索参数	类型化 + schema 验证	原始字符串
数据预加载	内置（hover/intent 触发）	需自行实现
包体积	~45KB	~20KB
感知加载时间	降低 30-40%	基准

对于 Claude.ai 这种高交互场景，TanStack Router 的优势非常明显：类型安全减少运行时错误、自动代码分割提升加载速度、内置预加载让导航感知更快。

4.3 边缘 Workers：离用户最近的地方

迁移后的静态资源直接从边缘 Workers 节点分发，不再需要经过 SSR 服务器。

边缘部署的核心优势：

对比维度	SSR 服务器	边缘 Workers
请求处理	需要执行 React 渲染逻辑	直接返回静态文件
TTFB	200-900ms（未缓存）	20-50ms（CDN 缓存命中）
冷启动	Serverless: 200ms-10s	Workers: < 5ms（理论）
全球覆盖	通常部署在少数区域	330+ 城市节点
计算成本	每次请求都有服务端计算	几乎零计算

以 Cloudflare Workers 为例，它基于 V8 Isolate（V8 是 Chrome 浏览器的 JavaScript 引擎，Isolate 是其提供的轻量级沙箱隔离机制，每个 Isolate 拥有独立的内存和执行环境）。单个运行时实例可同时运行数百到数千个 Isolate，内存消耗仅为 Node.js 的 1/10，启动速度快约 100 倍。

这就是 Claude.ai TTFB 能下降 65% 的根本原因：用户请求不再需要经过一台服务器执行 React 渲染逻辑，边缘节点直接返回预编译好的静态文件，中间几乎没有计算过程。

5、更大的趋势：前端架构的集体"轻量化"转向

5.1 Cloudflare 的 vinext：用 Vite 重写 Next.js

就在 Claude.ai 迁移的同一时期，Cloudflare 公开了他们的 vinext 项目------直接在 Vite 上重新实现了 Next.js 的 API 层。

更震撼的是，这个项目是一个工程师用一周时间完成的，借助 Claude Opus 辅助开发，花费约 $1,100 的 API 费用。

性能对比数据：

指标	Next.js 16 + Turbopack	vinext + Vite 8 + Rolldown	差距
构建时间	7.38s	1.67s	快 4.4 倍
Bundle（打包产物）体积	168.9 KB	72.9 KB	缩小 57%
API 覆盖率	---	94%	---

vinext 不是对 Next.js 的封装，而是在 Vite 原生插件体系上从头实现 Next.js 的 API 语义（App Router、RSC、Server Actions、ISR（Incremental Static Regeneration，增量静态再生------允许在不重新构建整个网站的情况下，按需更新单个页面的静态内容）等全部支持）。

这说明什么？Vite 的插件化架构足够强大，完全可以支撑框架级别的复杂需求。 而 Rolldown 带来的构建速度提升，让整个工具链的性能上了一个台阶。

5.2 "回归 SPA" 的理性回归

Claude.ai 的迁移不是孤例。2024-2025 年，越来越多的团队开始反思 SSR 是否被滥用了。

Northflank 案例 是最有代表性的：这家基础设施平台从 Next.js 迁出后，页面渲染时间从 700ms 降到 20ms（快 50 倍），FCP（First Contentful Paint，首次内容绘制------浏览器第一次渲染出文字或图片的时间）从 2.1s 降到 0.5s。

Hacker News 上的高赞评论精准总结了社区共识：

aswerty: "SSR 已成为前端时尚，供应商推动用户采用以增加服务器端计算消耗。建议使用普通 React SPA 配合懒加载。"
babyent: "用 SSR：公开可索引的内容。用 SPA：私有 B2B 应用，数据不需要公开索引。"

甚至 Vercel CEO Guillermo Rauch 自己都在 2025 年表态："Next.js 的一个优点是你完全可以在最简单的模式下使用它，作为静态页面或 SPA。" ------Vercel CEO 亲自强调 SPA 的合法性，本身就很说明问题。

社区得出的核心教训：

没有"正确"的默认架构，只有适合具体场景的架构
技术选型应从业务需求出发，而非追随框架厂商的推广方向
Vercel 等托管商的商业利益与技术最优解存在结构性偏差
复杂不等于更好------很多 Next.js 项目用简单的 SPA 反而更健康

6、我的看法

作为一个每天都在用 Claude 的 AI 应用工程师，我想从几个角度聊聊自己的观察。

6.1 这不是 Vite 的胜利，是"用对架构"的胜利

很多人把这件事解读为"Vite 比 Next.js 好"，但我觉得这个角度偏了。核心问题不是工具的好坏，而是场景匹配度。

Claude.ai 是一个登录后使用、高度交互、实时流式输出的 AI 对话产品。这种产品天然就是 SPA 的最佳战场。之前用 SSR，就好比拿着一把锤子去拧螺丝------不是锤子不好，是用错了场景。

迁移后效果立竿见影，恰恰说明之前的架构选型存在明显的错配。

6.2 AI 产品的前端体验被严重低估了

这是我感触最深的一点。很多 AI 产品把所有精力都放在模型能力上，前端体验经常是"能用就行"的状态。

你去试试 OpenAI 的 Codex，再对比 Claude 的 Web 体验，差距非常明显。Anthropic 愿意花时间把前端架构做一次大手术，说明他们确实把用户体验当回事。

Felix 在推文末尾的态度值得品味：

"我们还没做完，甚至远远没完成。但我们在意这些细节，会一点一点打磨下去。目标是让 Claude 每天都好一点点。"

这种工程文化在 AI 公司里其实挺难得的。模型能力是核心竞争力没错，但用户感受到的是模型能力 × 产品体验的乘积。前端响应快 50%，用户就能更早看到 AI 开始回复，感知延迟大幅降低------这对一个对话产品来说，价值不亚于模型推理速度的提升。

6.3 技术选型要基于场景，不要跟风

这件事给我最大的启示是：不要因为"大家都在用 Next.js"就选 Next.js，不要因为"SSR 是主流"就上 SSR。

我在企业内部做 AI 应用落地时也经常遇到这个问题。很多团队在选技术栈时，第一反应是"现在流行什么"，而不是"我的业务场景需要什么"。

一个简单的判断框架：

你的应用需要 SEO 吗？ 不需要 → 大概率不需要 SSR
用户是登录后使用吗？ 是 → SPA 足够
交互复杂度高吗？ 高 → SPA 更合适
后端是 Node.js 吗？ 不是 → 纯前端 SPA + API 分离更干净

Claude.ai 四个问题的答案分别是：不需要、是、极高、大概率不是。四项全中，SPA 就是最优解。

6.4 Vite 的崛起代表了一种更健康的工具链哲学

Vite 的做法是：我只做构建工具该做的事，把框架选择权交给你。 你要用 React、Vue、Svelte 都行，你要 SPA、SSR、SSG 都行。这种"不绑定、不锁定"的哲学，和 Next.js "全包全管"的路线形成了鲜明对比。

从商业角度看，Vercel 推 SSR 有其商业逻辑------服务端渲染需要服务器，服务器需要托管，托管需要付费。而 SPA + CDN 的方案，成本低、依赖少，反而不利于托管商的营收。

技术选型不应该被商业利益所左右。这是我作为工程师最朴素的判断。

6.5 关于未来的一点预判

结合 Vite 生态的发展速度和社区的理性回归，我觉得接下来会看到：

更多 AI 产品效仿 Claude.ai 的做法，从 SSR 迁移到 SPA + 边缘部署
Vite + TanStack Router 会成为新一代 SPA 应用的标准搭配
Next.js 不会消亡，但会收缩到它真正擅长的领域（内容站、电商、SEO 密集型应用）
前端工具链的 Rust 化会持续加速，Rolldown + OXC 只是开始

7、总结

Claude.ai 这次架构升级，表面上是一次技术迁移，本质上是一次**"纠错"**------把不适合的架构换成了适合的架构。

效果也证明了这一点：TTFB 下降 65%，提示词展示快 50%，导航更流畅。这些数据不是靠多加几台服务器堆出来的，而是通过去掉不必要的复杂性实现的。

有时候，让产品变快的最好方式，不是加东西，而是减东西。

这或许是这件事给所有开发者最重要的启示。

参考资料：

Felix Rieseberg 推文（2026-03-20）
尤雨溪转发推文
Vite 8.0 官方发布博客
VoidZero 官方发布周总结
Cloudflare vinext 项目博客
TanStack Router 官方文档
Northflank: Why we ditched Next.js and never looked back
State of JavaScript 2024 调查报告
Hacker News 社区讨论：SPA vs SSR in 2024

|-----------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| 🚀 持续探索 AI 与前沿技术 分享大模型应用、软件开发实战与行业洞察。欢迎关注公众号 【龙哥AI】，加入 7000+ 技术同行的交流圈！ 🌟 探索技术边界，让开发更有效率 | |