X 网页重构：流式渲染与 AI 编程协作

IT之家#AI编程#前端性能#工程实践

Editor brief · 编辑速览

X 通过统一服务架构、引入流式服务端渲染，将慢网环境下主页首帖加载降至约 2.7 秒，登录前启动文件从 582 个减至 10 个。团队让 AI 承担移植、测试和修复，并用 AGENTS.md、复用工作流及自动检查约束代码质量。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

X 网页版这次重构，最值得前端关注的是加载顺序：旧版先下载外壳和 JavaScript，再请求数据；新版通过流式服务器渲染，让帖子更早出现在屏幕上。据报道，Slow 4G 下账号主页首条推文的加载时间从 22 秒降至 2.7 秒，缩短 87.73%。

这次改造还把面向用户、搜索引擎和链接预览的三套服务器合为一套，并让 AI 编码智能体承担大量迁移工作。性能收益很具体，但技术栈、团队规模与 AI 的贡献，需要分开判断。

旧版网页应用 rweb 已服务 X 网页版近十年。对于未登录用户，它的加载过程存在串行依赖：先下载页面外壳与 JavaScript，再请求数据，最后渲染内容。前面的步骤没有完成，后面的步骤就得等。

网络越慢，这条链路越容易把用户困在启动画面。

报道中的 Slow 4G 模拟条件是：网络延迟约 150ms，下行速度 1.6 Mbps，上行速度 750 Kbps。在这样的环境下，减少必须下载的资源、缩短内容显示前的依赖链，比单独优化某个组件更有机会改变体验。

新版采用 Vite、React、Fastify、Platformatic Watt、Relay 与 GraphQL，并引入流式服务器渲染。服务器可以先发送页面外壳，在数据到达时继续推送内容，浏览器无需等全部 JavaScript 下载完，才开始显示帖子。

这次优化最有解释力的变化，是内容显示不再被全部 JavaScript 的下载挡住。

团队还把登录前页面的启动文件从 582 个减至 10 个，并优化图标、图片结构化数据和样式表加载顺序。不过，原文没有给出各项改动的独立收益，不能把 87.73% 的降幅全部归给流式渲染，也不能把文件数量下降直接当作传输体积同比下降。

旧架构把普通用户渲染、搜索引擎渲染和链接预览放在不同系统里。同一个 URL 可能有三种生成页面的方式，修一次 SEO、错误页或元信息，就可能要改多个代码库。

新版将三套服务器合为一套，但保留了按访问者返回不同内容的策略：

统一的是维护入口，响应内容仍然按需要裁剪。搜索引擎需要完整文档，聊天软件只需要生成分享卡片，没必要让它们都走普通用户的页面流程。

团队还用 Rust 重写了链接预览卡片图服务。原文没有提供这项重写前后的性能或资源消耗数据，因此无法判断收益有多少来自语言变化，有多少来自实现方式调整。

据 X 披露，最初版本由不到 5 名工程师在不到 6 个月内完成。AI 编码智能体承担了大量移植、页面转换、测试编写和问题修复；工程师主要负责架构设计、需求决策、代码审查和真实浏览器验证。

这个分工比「用了 AI，所以做得快」更值得参考。

团队通过统一的 AGENTS.md、超过 25 个可复用工作流，以及提交前自动格式化、类型检查和 lint 规则，约束生成代码。重复任务有操作流程，代码提交有检查，人再验证真实页面行为。

但这不是一份 AI 效率对照实验。原文没有提供不用 AI 的工期、返工率或缺陷率，也没有说明迁移涉及多少页面、复用了多少既有能力。「不到 5 人、不到 6 个月」对应最初版本；自 9 月底以来，已有超过 20 人参与开发，不能把前一个数字理解为整个项目始终只有这个规模。

我认同优先调整加载链路和重复维护成本。对于内容型网站，先让用户看到内容，通常比围绕启动画面继续打磨更值得投入。

但普通团队不必据此照搬整套技术栈，更不必直接从零重写。渐进引入服务端渲染、减少启动资源、统一元信息生成，也可能解决自己的主要问题。原文没有这些路线的对照数据，无法证明全面重构是成本最低的选择。

性能结果也有明确边界：22 秒到 2.7 秒测的是 Slow 4G 下账号主页的首条推文加载时间，并非所有页面、所有网络或所有用户的整体性能。原文只说部分页面首次内容绘制时间明显下降，没有给出具体数值和完整测试方法。

截至报道所述的 11 月 5 日，新版已服务未登录的 X.com 和搜索引擎抓取页面，登录用户仍按国家和地区灰度迁移，rweb 保留为回退方案。这说明团队仍在分阶段验证迁移结果。