延迟描述数据通信需要等待多久，吞吐量描述一段时间传输了多少数据，抖动则与延迟变化有关。它们分别影响不同体验，不能用其中一个数字代表全部网络质量。
延迟先问测了哪一段
客户端中的延迟可能来自某种探测方法，并不一定是完整应用请求的耗时。需要知道探测目标、协议、是否经过代理及测量条件，才能理解结果。
往返时延与单向时延也不是同一概念。不同客户端的数字如果方法不同，不能只按大小直接比较。没有说明方法的截图，参考价值有限。
吞吐量决定大文件传输能力
通常说的下载速度更接近吞吐量，它还受测试服务器、本地带宽、设备性能及同时运行任务影响。远端速度高，也可能被本地 Wi-Fi 限制；因此一次测试不能自动定位瓶颈。
传输单位也需要看清：Mb/s 与 MB/s 的字节、比特含义不同，1 字节为 8 比特。界面换了单位，大数字未必代表更高性能。
波动和失败会影响连续体验
视频会议、语音或交互任务可能对变化更敏感。平均值相近的两组记录，波动和失败情况可能差别很大，只看平均延迟会忽略这些差异。
记录时应保留异常样本，并说明是否发生本地断网。不能为了使图表好看而删掉失败值，也不要把每一次本地故障归到服务商身上。
按任务理解指标
阅读文字页面可能更在意请求能否及时完成；下载资料需要关注持续吞吐；实时互动则常需要看等待时间与波动。具体体验还受应用处理和账号条件影响。
合理做法是在相同设备、网络、目标和时段重复观察，同时记录实际任务是否完成，而不是给不同指标随意加权成一个“神秘总分”。
怎样做最小对照
先固定本地设备与网络，暂停无关大流量任务，保留测试方法与目标。每次只更换一个节点，在相近时段重复。结果应带日期与环境，不外推到所有地区和运营商。