diff --git a/files/zh-cn/web/performance/how_long_is_too_long/index.md b/files/zh-cn/web/performance/how_long_is_too_long/index.md
new file mode 100644
index 00000000000000..344744f564c627
--- /dev/null
+++ b/files/zh-cn/web/performance/how_long_is_too_long/index.md
@@ -0,0 +1,32 @@
+---
+title: Web 性能时间指标推荐：多久才算太久？
+slug: Web/Performance/How_long_is_too_long
+l10n:
+  sourceCommit: fff37e54dad8353fc89f6c61f5ec408094bcebd8
+---
+
+{{QuickLinksWithSubPages("/zh-CN/docs/Web/Performance")}}
+
+对于加载页面时速度缓慢的定义并不明确，但对于内容加载（1 秒）、空闲（50 毫秒）、动画（16.7 毫秒）和响应用户输入（50 至 200 毫秒）却都有具体准则。
+
+## 加载目标
+
+“不到一秒”通常被吹捧为最佳加载时间，但这意味着什么？一秒应当被视作向用户表明已发送新内容请求并将其加载到网页的最长时间准则，例如浏览器显示网页的标题与背景颜色。
+
+从请求中获取到的第一个资源通常是 HTML 文件，然后该文件会调用其他资源。正如在[关键渲染路径](/zh-CN/docs/Web/Performance/Critical_rendering_path)提到，浏览器在接收到 HTML 后，会立即开始处理和渲染，而非等待其他资源加载。
+
+诚然，在一秒钟内完成加载是理想目标，但很少有网站能达到。期望各不相同，比如商用网络上加载“hello world”预期只需几毫秒；而在西伯利亚北部的用户，用着边缘网络在五年的老设备下载一个猫咪视频时，可能觉得 20 秒内下完就很快了。如果用户等待三、四秒而又没有任何加载提示和进度条，那么网站就可能失去潜在访客，得经过很长时间这些访客才会回归了。
+
+在优化性能时，应设定一个大胆的首次加载目标，比如在移动 3G 网络加载不超过 5 秒，在商用的顶级线路加载不超过 1.5 秒，并充分利用 Service Worker 和缓存，为后续页面加载设定更高的目标。初始加载页面与加载其他资源、响应用户交互和确保动画流畅的时间指标有所不同：
+
+## 空闲目标
+
+浏览器是单线程的（尽管 Web Worker 支持后台线程）。这意味着用户交互、页面绘制和脚本执行都在同一个线程上。如果线程忙于执行复杂的 JavaScript 脚本，那么主线程将无法对用户输入（例如按下按钮）做出反应。因此，脚本执行应该受到限制，划分为可以在 50 毫秒或更短时间内执行的代码块。让线程空闲以响应用户交互。
+
+## 动画目标
+
+为了使页面滚动和其他动画看起来流畅丝滑且响应迅速，内容重绘应以每秒 60 帧 (60fps) 的速度进行，也就是每 16.7 毫秒进行一次操作。16.7 毫秒包含了脚本执行、网页重排和重绘的时间。请注意，HTML 文件大约需要 6 毫秒渲染一帧，只剩下约 10 毫秒用于其他部分。任何低于 60fps 的帧率，特别是不均匀或变化的帧率，都会显得卡顿。
+
+## 响应目标
+
+当用户与内容交互时，提供反馈并确认用户的响应或交互非常重要，并且响应时间应在 100 毫秒内，最好是在 50 毫秒内。50 毫秒在体验上是即时的。对用户交互的确认通常应该是即时的，例如悬停或按下按钮，但这并不意味着即时完成响应。虽然慢于 100 毫秒的反应可能会导致用户交互和响应之间的脱节，但 100 到 200 毫秒的响应过渡可能有助于用户注意到他们的交互所引发的响应，例如打开了菜单。如果响应需要超过 100 毫秒完成，则应提供某种形式的反馈以告知用户交互已然发生。