Excalidraw FID改善：首次输入延迟减少

Excalidraw FID改善：首次输入延迟减少

在开发者和产品团队频繁使用数字白板进行架构设计、流程梳理或头脑风暴的今天，一个“点下去没反应”的瞬间足以打断创作节奏。这种卡顿感，往往源自网页性能中一个关键但容易被忽视的指标——首次输入延迟（First Input Delay, FID）。

对于像 Excalidraw 这样集手绘风格、实时协作与 AI 生成功能于一体的 Web 应用来说，用户期望的是“打开即用、点击即画”。然而，在低性能设备上加载复杂的前端逻辑时，主线程可能正忙于解析 JavaScript 或初始化第三方库，导致用户的第一次点击要等待数百毫秒才能响应。这不仅破坏体验，更让工具显得“不够专业”。

值得庆幸的是，Excalidraw 团队通过一系列前端工程实践，将平均 FID 从约 210ms 降至90ms 以内，达到了 Google Core Web Vitals 中“优秀”级别。这一优化并非依赖单一技巧，而是一套系统性的性能策略协同作用的结果。

响应力的本质：FID 到底衡量什么？

我们常说“页面卡”，但从技术角度看，“卡”可能是加载慢（FCP）、交互迟钝（FID），或是动画不流畅（FPS）。其中，FID 直接反映的是用户对响应速度的主观感受——你点了按钮，它有没有立刻动起来？

FID 测量的是：从用户执行第一个操作（如点击、轻触、按键）开始，到浏览器主线程真正开始处理该事件之间的时间差。注意，它不是事件处理耗时本身，而是“等待主线程空闲”的排队时间。

举个例子：页面刚加载完，JavaScript 正在执行一段长达 200ms 的同步任务。此时用户点击了画笔工具——尽管 DOM 已渲染完毕，浏览器却必须等当前脚本跑完才能响应点击。这段“干看着不能操作”的等待期，就是 FID。

典型的高 FID 场景包括：
- 主包过大，解析时间长
- 第三方脚本阻塞主线程（如分析 SDK、AI 插件）
- 没有拆分长任务，造成持续阻塞

由于 FID 受用户设备、网络和后台进程影响较大，它无法完全通过实验室测试模拟准确，必须依赖真实用户监控（RUM）数据来评估。这也是为什么很多 Lighthouse 分数不错的页面，在低端安卓机上依然“点不动”。

好在现代浏览器提供了标准 API 来捕获这一指标：

let firstInputDelay = null; const po = new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); const firstInputEntry = entries[0]; if (firstInputEntry && !firstInputDelay) { firstInputDelay = firstInputEntry.processingStart - firstInputEntry.startTime; console.log(`FID: ${Math.round(firstInputDelay)} ms`); // 异步上报，避免干扰主线程 navigator.sendBeacon('/analytics', JSON.stringify({ metric: 'FID', value: firstInputDelay, page: window.location.pathname })); } }); po.observe({ type: 'first-input', buffered: true });

这套采集机制已成为 SPA 应用性能监控的基础能力。但在 Excalidraw 的案例中，真正的挑战不在于如何测量 FID，而在于如何系统性地降低它。

架构瘦身：让核心功能先跑起来

Excalidraw 并不是一个简单的绘图工具。它支持多人协作、本地存储、SVG 导出，还集成了基于大模型的 AI 绘图功能。如果把这些模块全部打包进主 bundle，很容易突破 1MB，直接拖垮首屏性能。

解决方案很清晰：只加载用户马上要用的东西。

项目采用现代构建工具（Vite/Webpack）实现细粒度代码分割。核心思路是将应用划分为多个动态 chunk，按需加载。例如：

const AIInputDialog = lazy(() => import('./AI/AIGenerationModal')); function DrawingBoard() { const [showAI, setShowAI] = useState(false); return ( <div> <CanvasRenderer /> <Toolbar onUseAI={() => setShowAI(true)} /> {showAI && ( <Suspense fallback={<Spinner size="small" />}> <AIInputDialog onClose={() => setShowAI(false)} /> </Suspense> )} </div> ); }

这个模式看似简单，实则深思熟虑。AI 功能虽强大，但统计显示多数用户并不会一进入就使用。若将其随主包预载，等于让所有人为少数场景买单。通过React.lazy+Suspense，AI 对话框组件仅在用户主动触发时才发起请求，既节省带宽又释放主线程压力。

更重要的是，这种“渐进式增强”理念贯穿整个架构设计。比如：
- 协作引擎 Yjs 在用户点击“分享链接”前不会初始化；
- 图标字体资源通过<link rel="prefetch">在空闲时预取，不影响关键路径；
- 离线缓存逻辑延后至页面稳定后注册 Service Worker。

最终，生产环境下的核心 bundle 经 Gzip 压缩后控制在300KB 以内，确保即使在 3G 网络下也能快速抵达并执行，大幅缩短 TTI（可交互时间），间接压低 FID。

主线程保卫战：把重活交给 Web Worker

即便做了代码分割，某些操作仍不可避免地消耗 CPU 资源。比如 AI 请求返回后需要解析 JSON、映射为图形元素、计算布局位置——这些都可能占用几十甚至上百毫秒。

若在主线程执行，哪怕只是短暂阻塞，也可能刚好撞上用户输入，导致明显的卡顿。为此，Excalidraw 将部分计算密集型任务移入 Web Worker：

// aiWorker.js self.onmessage = async function(e) { const { prompt, requestId } = e.data; try { const response = await fetch('/api/generate-diagram', { method: 'POST', body: JSON.stringify({ prompt }) }); const result = await response.json(); const elements = mapToExcalidrawElements(result); self.postMessage({ type: 'success', elements, requestId }); } catch (err) { self.postMessage({ type: 'error', err, requestId }); } };

主线程只需发送消息并监听结果，无需等待网络和计算完成。这种方式不仅能避免阻塞 UI，还能利用多核 CPU 提升整体效率。

此外，AI 客户端内部也做了精细化控制：

class AIClient { constructor() { this.cache = new Map(); this.abortController = null; } async generateFromPrompt(prompt, signal) { const cached = this.cache.get(prompt); if (cached) return cached; // 取消上一次未完成的请求 this.abortController?.abort(); this.abortController = new AbortController(); try { const response = await fetch('/api/generate-diagram', { method: 'POST', body: JSON.stringify({ prompt }), signal: signal || this.abortController.signal }); const result = await response.json(); const elements = this.mapToExcalidrawElements(result); this.cache.set(prompt, elements); return elements; } catch (err) { if (err.name !== 'AbortError') throw err; } } }

这里的关键在于防抖 + 可取消请求。当用户连续修改输入时，旧请求会被自动终止，避免无效计算堆积。结合AbortController，既能节省服务器资源，又能防止回调混乱引发状态错误。

更有意思的是，团队还在空闲时段尝试建立 AI 服务的长连接（如 WebSocket 预热），使得首次调用的实际延迟显著降低——这是一种典型的“用户体验优先”设计。

系统级协同：从加载流程看性能权衡

Excalidraw 的整体架构呈现出清晰的分层结构：

+---------------------+ | 用户界面层 | ← React 组件 + Canvas 渲染 +---------------------+ | 功能逻辑层 | ← 状态管理（zustand）、AI 控制器、导出模块 +---------------------+ | 异步处理层 | ← Web Workers、fetch 请求池、消息队列 +---------------------+ | 数据与协作层 | ← IndexedDB（本地存储）、Yjs（实时同步）、AI API +---------------------+

FID 优化的核心思想，就是在各层之间设置合理的“启动优先级”和“激活时机”。

典型用户打开流程如下：
1. HTML/CSS/JS 首包加载完成（CDN 加速，<1s）
2. React 渲染空白画布 + 工具栏（TTI ≈ 1.2s）
3. 用户点击工具开始绘制 → 主线程立即响应（FID < 80ms）
4. 后台静默加载协作模块 & AI 客户端预备
5. 用户调用 AI 功能时，动态加载 modal 并发起请求

在这个流程中，最关键的交互（如选择、绘制）始终不受后台任务干扰。即使是移动端低端设备，也能保证基础功能的即时响应。

针对不同痛点的技术应对也十分精准：

这些策略共同构成了一个“以用户为中心”的性能体系：先让用户动起来，再慢慢补全高级功能。

性能不止于数字：设计背后的工程哲学

在实施这些优化的过程中，有几个容易踩坑的边界值得注意。

首先是拆分粒度过细的问题。虽然代码分割有益，但过多的小 chunk 会导致 HTTP 请求激增，尤其在高延迟网络下反而得不偿失。Excalidraw 采用“功能域划分”而非“文件级拆分”，确保每个异步模块都有合理体积和使用频率。

其次是预加载的时机选择。<link rel="preload">适合关键资源，而<link rel="prefetch">更适合次级页面资源。对 AI SDK 这类非必现功能，采用空闲时 prefetch 是更优解。

再者是真实数据驱动决策。团队借助 Chrome UX Report（CrUX）和自建 RUM 系统持续追踪全球用户的 FID 分布，发现某些区域因网络基础设施落后，FID 明显偏高。据此针对性优化 CDN 和资源压缩策略，实现了更均衡的体验覆盖。

最后是用户体验引导。新用户首次使用 AI 功能时，会收到轻量提示说明其异步加载特性，避免误以为“崩溃”或“无响应”。这种透明沟通也是良好性能设计的一部分。

结语

Excalidraw 的 FID 优化之旅，本质上是一场对“复杂性”的驯服过程。它没有追求极致精简，也没有放任功能膨胀，而是在丰富功能与流畅体验之间找到了平衡点。

它的启示在于：现代 Web 应用的性能优化不再是单纯的“减法游戏”。我们不再只是删除代码或压缩图片，而是通过架构设计、任务调度和用户行为预测，构建一个智能的、弹性的运行时环境。

当 AI 成为标配功能，当协作成为默认模式，如何不让这些“增强”变成“负担”，将是每一个前端工程师必须面对的课题。Excalidraw 的答案是：让核心更快，让扩展更轻，让用户永远感觉不到等待。

这才是真正的“丝滑”背后，最硬核的工程智慧。