我运营 Wirewiki.com，这是一个用于检查互联网基础设施（如域名）的网站。它帮助人们检查（历史性的）DNS 记录、DNS 委派、电子邮件可投递性配置等。有很多网站提供这些功能（得益于 vibe coding，增长速度前所未有地快），所以我需要一种方式来脱颖而出。我选择了工具质量/实用性和用户体验。自动完成是浏览 Wirewiki 的主要方式，因此它应该尽可能完整、准确和快速。我希望它是即时的。就像，下一帧即时。我基本上已经实现了这一点。在按下键时（用户开始按下一个键），我们预先获取已输入字符 + 任何下一个字符的建议。而在松开键时（用户释放按键），我们渲染建议。这给了我们一个时间预算：按键按下1的持续时间 + 按键之间的间隙 + 按键按下2的持续时间。如果 API 在第二个按键按下之前返回，我们就会及时准备好结果。（60 赫兹的显示器每隔 16.7 毫秒渲染一次。因此在 p50，我们从技术上有额外的 8.33 毫秒时间预算，但在 p99 接近 0 毫秒。）松开按键 按下按键 wik GET /autocomplete?q=wi 为 'wik' 渲染补全项 API 的时间预算 API 往返时间 q=wi 的请求在按下 i 的瞬间发出；如果其响应在松开 k 之前到达，则 'wik' 的补全项将以零感知延迟渲染。因此，出于本文的目的，我们将延迟定义为从松开按键到结果准备好进行渲染。p99 0 毫秒意味着 99% 的时间，结果将在用户释放按键之前就已准备好。我们需要两件事来实现这一点：客户端预获取和缓存建议，以及足够快的 API。预算有多大？我们现在知道我们可以花费两个按键按下持续时间和一个间隙持续时间，但这在毫秒中是多少？我在以合理的速度输入 100 个域名时测量过，发现 p99 对我来说是 121 毫秒。