performance.dev 5 月 3 日发了一篇技术拆解，专门解释 Linear 为什么用起来很快。
有意思的地方不在于 Linear 用了多稀奇的技术。原文列到的栈很常见：React、TypeScript、MobX、Postgres、CDN、WebSocket、Service Worker。真正反常的是，它把一个典型 Web 应用最容易暴露的部分藏起来了：等网络。
这篇分析也有边界。作者明确说自己没有在 Linear 工作过，也没有看过源码。文中判断来自使用观察、Linear 博客和公开演讲。所以它更像一份外部技术剖面，不是官方源码说明。
但主线很清楚：Linear 的速度不是“前端奇技”，而是一套围绕用户体感做的系统取舍。
本地优先：UI 先动，网络后台追账
传统 CRUD 应用的路径很熟：用户点击，前端发请求，服务端查库或写库，返回结果，页面再更新。
原文提到，一次更新大约可能带来 300ms 级别等待。这个数字单看不吓人。但放到创建 issue、改标题、切换状态、拖拽任务这些高频动作里，300ms 就会变成手感上的卡顿。
Linear 的核心做法是把顺序倒过来。
UI 主要读浏览器里的数据。IndexedDB 负责本地持久化，本地内存状态负责即时渲染。用户改动先在本地生效，再由同步引擎异步推到服务器。服务器再通过 WebSocket 把增量同步给其他客户端。
也就是说，用户看到变化，不必等服务端回包。
这不是魔法，而是把复杂度从交互时刻挪到了架构后面。前台更顺，后台更难。
| 路线 | 用户体感 | 工程代价 | 更适合谁 |
|---|---|---|---|
| 传统 CRUD | 等请求返回后更新 UI，容易出现 spinner | 简单，冲突少 | 低频后台、普通管理系统 |
| Linear 式本地优先 | UI 先变，网络后台同步 | 要处理队列、冲突、离线、回滚 | 高频协作工具、重度工作流产品 |
| TanStack Query / SWR 乐观更新 | 先改缓存，失败再回滚 | 不必自研完整同步引擎 | 多数 Web 团队的现实起点 |
我更在意的是这个判断：Linear 快，不是因为它绕开了后端，而是它避免让用户每一步都等后端。
对前端和全栈团队来说，这会直接影响任务排序。与其先讨论“要不要换框架”，不如先列出产品里最频繁的 5 个操作：创建、编辑、切状态、拖动、删除。能不能先做乐观更新？失败时能不能回滚？列表和详情能不能提前预取？
这些动作比重写架构更小，但更接近用户体感。
加载优化：少发代码，拆细代码，提前缓存
客户端渲染常被批评首屏慢。Linear 仍然坚持 CSR，关键是它不是裸奔式 CSR。
前面有本地数据和缓存兜底，后面还有一整套加载优化。原文根据 Linear 博客和作者观察整理称，Linear 经历过 Parcel、Rollup、Vite、Rolldown 等构建迁移，目标集中在减少 JavaScript 和 CSS、改善加载与开发体验。
Linear 博客曾提到一些数据：50% 更少代码发送、压缩后体积减少 30%、冷缓存页面加载快 10% 到 30%、Safari 上 active issues 视图首次绘制时间下降 59%、内存下降 70% 到 80%。
这些数字要谨慎看。它们说明 Linear 在自己的代码结构和浏览器目标下拿到了收益，不说明某个工具换上去就能自动复现。
更关键的动作有几类：放弃旧浏览器负担，使用原生 ESM，强代码分割，modulepreload 提前拉关键 chunk，用 Service Worker 预缓存后续资源。
原文还观察到，Linear 把依赖拆成更细的 vendor chunk，而不是打成一个巨大的 vendor.js。这样某个 npm 包更新时，只需要让对应 chunk 失效，其他依赖还能继续命中缓存。
这件事对经常打开同一个工作工具的人很实际。一次首屏指标好看，不如每天打开都少等几秒。
这里也能看到 Linear 的取舍：它不是简单相信“客户端渲染更快”。CSR 只有配上本地数据、细粒度缓存、预加载和同步机制，才可能变成好体验。否则只是把等待换了个位置。
普通团队别复刻 Linear，先减少可感知等待
Linear 最容易被误读成一个架构榜样：既然它快，那我们也做本地优先，也写同步引擎。
这不太现实。
同步引擎要处理离线队列、冲突合并、权限变化、跨端一致性和错误恢复。协作编辑还可能牵涉 CRDT 或类似机制。Linear 在 2024 年公开演讲中提到，联合创始人 Tuomas Artman 很早就写了同步引擎。这说明它从产品早期就在押注这套模型。
一个已经跑了多年、有大量历史业务的团队，很难轻松迁过去。尤其是权限复杂、审计严格、强合规的企业系统，本地先更新并不总是成立。某些操作必须等服务端确认，比如付款、审批、权限变更、不可逆删除。
所以普通团队更该拆成两步。
第一步，找出用户最常用、失败率较低、回滚成本可控的操作。比如改标题、切状态、收藏、标记已读。这些地方可以用 TanStack Query、SWR 这类库做 optimistic updates。
第二步，清理加载链路。减少首屏必须执行的代码，拆细路由和依赖，提前预取高概率页面，用 Service Worker 缓存稳定资源。
技术负责人更应该把这当成产品体验账，而不是前端优化账。可以要求团队给出两个清单：哪些交互还在等网络，哪些资源每次都在重复下载。清单比口号有用。
接下来最该观察的，也不是 Linear 会不会再换一个构建工具。
真正的变量有两个：本地优先体验能不能在更复杂权限和合规场景里保持稳定；通用 Web 数据层工具会不会把同步、离线、冲突处理继续产品化。前者决定 Linear 路线的上限，后者决定普通团队能学到哪一步。
回到开头那个问题：Linear 为什么快？
答案不是某个框架赢了，也不是客户端渲染翻身了。它快在一件事上很克制：尽量不让用户看见网络等待。