什么是 networkidle？
Scrapeless Scraping Browser 提供用于自动化工作流程的受管 Chromium 会话，这些工作流程必须选择可靠的导航和页面就绪条件。
简而言之
- networkidle 是一个自动化工具启发式，不是浏览器生命周期事件。 它根据工具的定义等待一个没有或很少的网络连接的时期。
- 确切的含义取决于框架和选项。 阈值、空闲窗口和哪些请求计数是实现细节。
- 安静的网络并不能证明 UI 就绪。 渲染、计时器、动画、工作者计算或过时的占位符可能仍然存在。
- 繁忙的网络并不能证明 UI 无法使用。 分析、流媒体、轮询和长期连接可以在目标内容就绪后继续。
- 有针对性的等待通常更强。 等待选择器、响应、状态标志或下一步所需的数据条件。
为什么网络安静不是就绪
networkidle 启发式影响浏览器如何暴露状态、渲染内容或决定何时自动化操作是安全的。精确的定义防止团队将狭窄的信号视为普遍答案。它还使测试失败的诊断更容易，因为预期的浏览器行为与文档生命周期、API 或系统边界相关联。
对于网络自动化，实际问题总是比“页面是否准备好？”或“浏览器看起来正常吗？”要狭窄。下一步可能需要启用一个控件、一个框架完成导航、一个组件附加其内部树，或一个渲染表面保持一致。下面的部分将这一概念转变为可观察的检查，而不是依赖民间传说。
networkidle 是一种启发式
networkidle 是一种浏览器自动化等待条件，它将足够安静的网络视为页面就绪的代理。自动化框架计算或跟踪相关的网络活动，并在活动保持在空闲区间的阈值以下后解决等待。浏览器 web 平台不会向页面脚本调度名为 networkidle 的标准事件。
这一启发式很具吸引力，因为现代页面在初始 HTML 加载后加载数据。DOMContentLoaded 可以在客户端请求填充界面之前触发，而 load 可以在应用程序发起的提取完成之前触发。网络的安静有时会捕捉到那之后的工作，而不需要测试作者了解页面的内部选择器。
这种便利性也是弱点。该条件观察传输活动，而不是用户可见的正确性。它无法知道哪个请求重要，响应是否生成了内容，水合是否完成，或所需按钮是否启用。它在几个信号中是一个，而不是一个已完成的定义。
Puppeteer 和空闲的含义
“ Puppeteer waitForNetworkIdle 记录 公开了一个页面方法，该方法在网络空闲后解决，并保证至少配置的空闲时间。导航 API 也接受与网络空闲阈值相关联的生命周期值。确切行为应从项目使用的版本文档中读取。
历史上，Puppeteer 用户遇到的标签区分零个活动连接和一个小的允许数字。这些名称是实现词汇，而不是可移植的网络标准。代码审查应记录所选框架、版本、阈值行为和超时，而不是仅仅说脚本等待网络空闲。
请求拦截、服务工作者、缓存资源、WebSockets 和后台活动可能会影响工具所观察到的内容。即使一个长期连接不被计算为普通请求，轮询或分析也可能阻止一个安静的窗口。验证启发式与目标页面，而不是假设一种选项适合每个站点。
为什么 Playwright 不鼓励它用于测试就绪
“ Playwright 页面加载状态文档 标记 networkidle 在测试中被不鼓励，并推荐能够证明就绪的 web 断言。这一建议反映了 Playwright 更广泛的自动等待模型：操作和断言等待相关元素条件，而不是页面范围内缺乏请求。
有针对性的断言创建了更强的契约。如果测试需要一个已提交的订单行，就等待该行。如果它需要一个响应，就等待匹配的响应然后断言 UI 状态。如果它需要一个禁用的加载覆盖层消失，就断言该转换。这些条件描述了产品行为，并在与分析或资产加载无关的变化中幸存。
networkidle 在探索、诊断或网络活动有 well-understood 有限形状的页面中仍然可以有用。问题不是它从不工作，而是它通常更广泛，且意义不如下一行自动化实际所需的状态。
错误积极：安静但未就绪
页面可以在 JavaScript 执行昂贵的计算、解析大响应或渲染虚拟列表时停止发出请求。CSS 过渡和动画可以继续。客户端路由器可能已获取数据，但尚未提交最终的 DOM。一个破损的请求也可以让网络保持安静，而页面显示错误或空的占位符。
懒惰内容可能等待滚动或交叉才能开始请求，因此页面可能在相关工作甚至尚未开始之前就处于空闲状态。一个计时器可能在空闲窗口后安排下一次获取。服务工作者的响应可以来自于与普通网络加载不相似的路径。这些状态没有确保目标是可操作的。
补救措施是一种应用级条件。等待稳定的计数、非空文本、数据属性、启用的控件或忙碌标记的消失。当可能时，请求应用团队暴露可测试的准备状态，而不是根据流量推断。
假阴性：忙碌但已准备好
分析信标、广告刷新、在线聊天、遥测、轮询、事件流和实时数据可以使页面无限期活动。主要内容可能在几秒钟前就可以使用。网络空闲等待会消耗所有的超时，即使操作本可以安全继续。
媒体页面和仪表板是常见的例子。视频播放器可以继续段请求。价格板可以维持流更新。搜索页面可能在后台报告指标。重要状态不是沉默；是工作流所需的特定内容的存在和稳定性。
一个实用的导航模式使用DOMContentLoaded作为早期里程碑，然后等待目标选择器或响应。这可以避免等待无关的后台流量。如果视觉布局在元素出现后需要短暂的稳定期，请单独测量并证明，而不是将其隐藏在全局启发式中。
选择更好的等待策略
该 DOMContentLoaded生命周期参考 提供一个标准定义的早期里程碑。将它与域条件结合起来：结果容器包含行，应用状态表示水合作用已完成，已知API响应成功，或图像报告完成解码。该条件应直接映射到下一个操作。
优先使用包括可见性、稳定性、启用状态和命中目标的可操作性检查的定位器和断言。对于提取，验证存在和内容形状。对于分页，等待页面令牌或第一行身份的更改。对于截图，等待字体和相关图像，而不是源上的每个连接。
将超时视为安全边界，而不是准备机制。当等待失败时，捕获缺失的条件、当前URL、可见状态、控制台消息和相关响应。诊断证据将模糊的超时转化为可以解决的页面状态问题。
用证据替换全局启发式
从能证明任务可以继续的最小条件或配置开始。保持与标准兼容的浏览器行为，然后仅在工作流需要的地方添加配置控件。记录浏览器版本和相关状态，以便后续差异能够解释。可重复的观察比简单声明某个页面、框架、显示或指纹“完成”或“安全”更有用。
- 定义下一个操作。 准确说明脚本或用户在等待或配置步骤后需要做什么。
- 选择一个可观察的信号。 优先考虑直接支持该操作的浏览器属性、生命周期状态、元素条件或渲染结果。
- 保持相关值的一致性。 浏览器、操作系统、屏幕、本地设置、图形和会话设置应描述一个合理的环境。
- 验证正常的应用行为。 隐私或自动化干预不应默默破坏其更改的API或组件。
- 捕获诊断证据。 当检查失败时，保存相关的URLs、状态、控制台消息和配置名称。
结论
networkidle根据观察到的网络活动中的安静期估算准备情况。它是特定于框架的，并且在延迟渲染时可能过早解析，或者在持续流量的页面上可能过晚。仅在页面请求模式使启发式有意义时使用；否则将早期导航里程碑与接下来所需的精确选择器、响应或应用状态配对。
该 无刮削的刮削浏览器文档 解释了如何配置受管理的浏览器会话，而该 刮削浏览器产品概述 描述了浏览器自动化表面。这些资源提供了在授权工作流中应用该概念的产品上下文。
准备构建更可靠的浏览器等待？
将浏览器渲染、会话配置和自动化基础设施移动到受管理的Chromium环境中。
今天注册并获得 $5的免费积分 — 无需信用卡.
领取您的$5积分→常见问题
networkidle是标准浏览器事件吗？
不。它是自动化框架启发式，普通页面脚本不会接收到标准的networkidle生命周期事件。
networkidle0和networkidle2是通用名称吗？
不。它们与特定工具和阈值语义相关联，因此项目必须咨询其框架和版本的文档。
为什么networkidle可以在工作页面上超时？
轮询、分析、媒体、聊天、遥测和其他后台连接可以在目标UI准备好后仍然保持网络活动。
什么应该替代networkidle？
使用导航里程碑加上针对选择器、响应、数据值、加载状态或下一个操作所需条件的目标断言。