Performance First UI 教会我的东西比任何框架都多

Source: Dev.to

速度不只是数字

作为开发者，我们从小就认为速度是一个数字——毫秒、分数、图表。
但用户从未看到数字。他们感受到的是瞬间：

• 点击之后的那一刻。
• 轻触之后的那一刻。
• 当他们期待得到响应时的那一刻。

如果在那一刻没有任何反应，就会出现问题——不是技术层面的，而是情感层面的。

Lighthouse 很有用。它让整整一代人开始关注性能。
但在 2026 年，仅仅依赖 Lighthouse 就像只看一辆车在空旷跑道上的加速来评判它。真实用户是在拥堵的路上行驶：

• 数据加载时他们在滚动。
• JavaScript 执行时他们在点击。
• 水合完成时他们在输入。

这就是 性能优先 UI 所在的地方——不是在加载时，而是在交互期间。

Interaction to Next Paint (INP)

页面加载是一次介绍。
一次交互是一种承诺。

当用户点击按钮时，他们不仅仅是在请求数据。他们在寻求确认：

“你听到我了吗？”
“你在工作吗？”
“我能信任你吗？”

如果你的界面保持视觉沉默，这个承诺就被打破了。

Interaction to Next Paint 测量的是网络指标中罕见的现实。
它不在乎逻辑何时结束或 Promise 何时解决；它在乎 像素何时变化。

这重新定义了我们编写 UI 代码的方式。把工作放在绘制之前突然变得危险。

常见的 INP 问题

大多数 INP 问题并非由慢服务器引起，而是出于好意：

• 事件处理函数内部逻辑过多
• 状态更新过多
• 组件一次性响应过多

一切都在工作，一切都正确——只是稍微晚了一点。那一点点的迟延会叠加。

一个简单、令人尴尬的修复

我对交互性能的最大提升竟然是如此简单：在显示反馈之前停止真正的工作。

# Before
Click → compute → update UI

# After
Click → update UI → compute

没有花哨的东西。没有新库。只有对绘制周期的尊重。

支持性能优先 UI 的 Next.js 特性

Next.js 在这种思路下悄然演进：

• Partial Prerendering – 界面在完整之前就已经出现。
• Streaming – 内容在不阻塞交互的情况下到达。
• Server Actions – UI 先移动，随后再确认。
• Edge Middleware – 将完整的决策树从客户端移除。

正确使用这些工具，就能让浏览器保持响应能力。

经验教训

我曾追求极简主义：更少的功能，更小的包体。
性能优先 UI 教会了我更好的做法：

• 一次做很多，但不是一次性全部做完。
• 推迟用户看不见的内容。
• 延后用户暂时不在意的事。
• 专注于用户刚刚完成的操作。

缓慢交互的代价

缓慢的交互成本高于慢页面加载，因为延迟发生在用户已经投入的时刻：

• 他们已经点击。
• 他们已经有意图。
• 他们已经准备好。

在这里失去他们，对转化率的伤害远大于慢着陆页。

AI 不能感受犹豫

在 2026 年，AI 可以生成组件、重构代码、优化资源。
但 AI 不能感受犹豫。它无法感知何时转场显得尴尬，或何时反馈来得太晚。这种敏感度正是开发者的真实价值所在。

它要求耐心。
它要求我们观察自己的界面，而不是盲目信任仪表盘。
它要求我们慢慢点击自己的按钮并自问：

这是否让人感到被尊重？

不炫耀。不聪明。尊重。

结论

性能优先 UI 不是潮流；它是一种纠正——回归到倾听用户的软体构建方式。

• 如果你的 UI 立即响应，用户会原谅瑕疵。
• 如果它犹豫不决，用户会记住。

最终，性能不在于速度，而在于 信任。