Linear 为何如此极速？技术深度解析

背景

在传统的 Web 应用开发中，性能往往受限于网络延迟。用户点击一个按钮，浏览器发送 HTTP 请求，服务器查询数据库并返回结果，浏览器重新渲染页面。这个过程通常需要几百毫秒，期间用户会看到加载旋转图标、骨架屏或冻结的界面。

Linear 是一款备受推崇的项目管理工具，以其极致的响应速度著称。更新一个 Issue 仅需几毫秒，而传统 CRUD 应用完成相同操作约需 300 毫秒。这种巨大的体验差异并非源于某种单一的“银弹”技术，而是源于从底层架构到无数细微决策的系统性优化。

本文基于对 Linear 应用行为、官方博客文章及会议演讲的深入研究（作者从未在 Linear 工作，也未见过其源代码），旨在拆解 Linear 实现极速体验背后的技术原理，帮助开发者理解并借鉴其设计思路。

核心内容

1. 浏览器内的数据库：本地优先架构

Linear 性能的核心在于其颠覆了传统的客户端-服务器关系。大多数 Web 应用依赖网络请求获取数据，而 Linear 将实际的数据库置于浏览器本地（使用 IndexedDB）。

• 本地优先更新：当用户进行修改时，UI 首先读取和更新浏览器内存中的数据。
• 异步同步：变更首先应用于本地，随后通过 Linear 自研的同步引擎异步推送到服务器。服务器处理变更并通过 WebSocket 将增量数据广播给其他客户端。
• 消除网络等待：这种架构消除了对网络请求的依赖。由于数据在本地同步，UI 可以同步重新渲染，无需等待服务器响应，从而消除了加载状态。

作者指出，构建极速 Web 应用的最大瓶颈是网络。任何客户端与服务器之间的数据传输都会消耗数百毫秒。Linear 的秘诀在于向用户隐藏所有网络请求，尽可能避免加载状态。

2. 乐观更新与状态管理

Linear 的 API 设计体现了“本地优先”的理念：

// 传统 Web 应用
async function updateIssue({ issue }) {
  showSpinner();
  const response = await fetch(`/api/issues/${issue.id}`, {
    method: "PATCH",
    body: JSON.stringify({ title: issue.title }),
  });
  const updated = await response.json();
  setIssue(updated);
  hideSpinner();
}

// Linear 的方式
issue.title = "Faster app launch"; // 更新内存中的数据（MobX observable）
issue.save(); // 将事务加入队列，由同步引擎批量刷新到服务器

在 Linear 中，issue.title = ... 立即更新内存中的可观察对象，UI 随即同步重绘。issue.save() 仅负责后台队列管理。即使 save() 失败，Linear 也会在后台验证并在必要时回滚，但用户感知到的速度并未受影响。

对于大多数应用，无需自建同步引擎，利用 TanStack Query 或 SWR 等库的乐观更新（Optimistic Updates）也能达到类似效果：

// 使用 SWR 进行乐观更新
mutate(
  `/api/issues/${issue.id}`,
  { ...issue, title: "Faster app launch" },
  false // 不立即重新验证
);

关键原则是：UI 的响应速度不应依赖网络延迟。用户感知的速度取决于界面反应的速度，而非服务器响应的速度。

3. 极简的技术栈

Linear 的技术栈以简单著称，没有使用边缘数据库、React Server Components (RSC) 或复杂的框架。

前端技术栈：

• React + react-dom：UI 运行时。
• MobX：用于可观察图管理和细粒度重渲染。
• TypeScript：端到端统一语言。
• 构建工具：经历了 Parcel → Rollup → Vite → Rolldown 的演变（截至 2025 年中）。
• ProseMirror + y-prosemirror：富文本编辑器，基于 Yjs CRDT 实现实时协作。
• Radix UI：基础 UI 组件。
• Emotion + StyleX：样式解决方案，Emotion 运行时配合 StyleX 编译为原子 CSS。
• Comlink：Worker RPC。
• idb：IndexedDB 封装，支撑本地优先存储。
• graphql-request：与同步服务器的 GraphQL 传输。

后端技术栈：

• Node.js + TypeScript：所有服务器代码统一语言。
• PostgreSQL (Cloud SQL)：Issues 表被分区为 300 份。
• Memorystore Redis：作为事件总线、缓存和同步游标。
• turbopuffer：用于相似 Issue 检测的向量数据库。
• Kubernetes on GCP：每个工作负载对应一个关注点。
• Cloudflare Workers：多区域边缘代理。

其他客户端：

• 桌面端：Electron（复用 Web JS，原生 Chrome）。
• 移动端：Swift (iOS) 和 Kotlin (Android)，均为完全重新实现。

作者特别强调 Linear 坚持使用客户端渲染 (CSR)。虽然 CSR 常被诟病初始加载慢，但通过正确的架构设计，它可以实现“即时”体验。纯客户端渲染简化了心智模型，避免了服务器/客户端边界、缓存头部设置等复杂性。

4. 让首次加载感觉“即时”

对于生产力工具，用户开始工作前的等待时间至关重要。Linear 在构建阶段就致力于减少 JavaScript 和 CSS 的体积，因为网络是瓶颈。

Linear 的构建管线经历了四次重写，目标始终是减少代码体积并提升开发者体验： Parcel → Rollup → Vite → Rolldown

根据官方博客数据，这些优化带来了显著成果：

• 交付代码量减少 50%。
• 压缩后体积减少 30%。
• 冷缓存页面加载速度提升 10-30%。
• 活跃 Issue 视图的首次绘制时间（Safari）下降 59%。
• 内存使用量下降 70-80%。

这些成果主要得益于：

1. 仅支持现代浏览器：放弃遗留支持（无 Polyfills、无 ES5 转译、无 nomodule 回退）。
2. 更好的死代码消除。
3. 激进的代码分割。

关键要点

• 本地优先是核心：将浏览器作为用户的数据库（IndexedDB），通过乐观更新和异步同步消除网络延迟对 UI 响应的影响。
• 隐藏网络请求：极速体验的关键在于让用户感知不到网络请求的存在，避免加载状态（Spinners/Skeletons）。
• 技术栈极简：Linear 未追逐最新框架潮流（如 RSC），而是坚持使用 React + TypeScript + MobX 的简单组合，降低了系统复杂性。
• 构建优化至关重要：初始加载速度取决于构建时的代码体积。通过放弃旧浏览器支持、死代码消除和代码分割，可大幅减少资源体积。
• 乐观更新是通用解法：即使不自建同步引擎，利用 SWR 或 TanStack Query 等库的乐观更新功能，也能显著提升大多数 Web 应用的用户感知速度。
• CSR 并非原罪：通过合理的架构设计，客户端渲染同样可以实现极致的即时体验，且心智模型更清晰。

意义与影响

Linear 的成功案例为 Web 应用性能优化提供了新的范式。它证明了在追求极致用户体验时，架构决策（如本地优先、CSR）比单纯的技术堆砌更为重要。

1. 重新定义“快”的标准：Linear 将 Web 应用的响应速度提升到了接近原生应用的水平，打破了用户对 Web 应用“慢”的刻板印象。
2. 架构简化的价值：在复杂的前端生态中，Linear 选择了极简的技术栈，这降低了维护成本，提高了开发效率，并减少了潜在的性能开销。
3. 同步引擎的重要性：Linear 联合创始人 Tuomas 在 2024 年的一次会议中提到：“我写的代码