01延迟描述等待，吞吐描述传输
延迟用于描述通信过程中的时间消耗。日常说的响应时间还可能包含名称解析、连接建立、加密协商和目标服务处理。吞吐则关注单位时间内实际传输了多少数据。大文件传得快，并不意味着每一次交互都能立即得到响应。
MDN 的延迟说明区分了这些等待环节，有助于理解网页首次打开与后续请求的不同。观察时先说明测量的是网络往返、浏览器请求，还是整个应用操作，不把不同含义的时间直接比较。
02抖动和丢包应结合使用场景
抖动可以理解为延迟在不同时间的变化，丢包则指某些数据未能按预期到达。实时会议可能对响应波动较敏感，文件传输则会以不同方式表现重传与等待。体验相似不代表原因相同，卡顿也可能来自设备负载或目标服务。
不要仅凭一次画面停顿判断存在丢包，也不要把一个应用的统计范围扩展到所有网络流量。先记录发生时的业务、接入方式与其他运行任务，再结合适用工具的定义解释结果。
03本地因素和路径因素分别观察
弱无线信号、干扰、共享接入和后台上传都可能改变响应。先在本地建立对照，例如靠近路由器或暂停自己能够识别的传输。如果同一设备在不同接入条件下表现不同，说明环境可能相关，但仍需考虑测试目标与时间是否相近。
路径距离、拥塞和目标服务处理也会产生等待。某个服务响应慢，不一定说明设备断网；某个地址响应快，也不能保证所有业务顺畅。把本地接入与目标服务分开描述，更方便继续排查。
04怎样看待 Ping 和浏览器计时
不同工具发送的请求类型和统计范围可能不同。有些目标或网络策略不响应某类探测，因此单次 Ping 超时不能独立证明业务不可用。浏览器中的请求耗时还可能包含排队、解析、连接与服务处理，不能直接等同于单纯的网络往返。
比较结果时记录目标、工具、持续时间与样本条件，避免只截取最小值或最大值。不要将一次测量包装成固定延迟，更不要根据一个未知来源截图推断服务的整体表现。测试应服务于解释现象，而不是制造漂亮数据。
05响应突然变差时的检查顺序
先确认是否所有应用都受影响，再观察本地信号和后台任务，然后比较同一目标在相近条件下的表现。若问题总在切换网络后发生，优先阅读网络切换指南；如果所有普通访问都失败，回到基础接入检查。
提交问题时，附上已经脱敏的现象记录、发生时间、设备和网络类型，说明哪些条件已比较过。通过连接状态检查教程整理过程，比只提供一个延迟数字更容易沟通。本页不提供实时 Ping、节点排名或虚构测速成绩。