套餐带宽很大，网页却仍要等几秒；下载文件很快，会议语音却偶尔断续。这些体验并不矛盾。理解speedcat使用场景中的网络表现，首先需要把响应时间、传输容量和实际获得的数据速度分开，才能让检查方向更明确。
网页并不是一次完成加载
输入网址后，设备通常先查询域名对应的网络地址，再建立连接、完成必要的安全协商，并向目标网站请求内容。浏览器收到页面后，还可能继续请求图片、样式、脚本和字体。缓存可以省去其中一些环节，但首次访问与再次访问的表现可能不同。任何一个等待环节变长，都可能让页面看起来没有反应。不要只凭一张图片出现的快慢，判断整条网络连接是否正常。
延迟关注等待，带宽关注容量
延迟描述数据从发出到到达所需的时间，实际排查中也常参考往返时间。带宽则描述连接在一定条件下可承载的数据速率上限。前者更接近“问一句多久有回音”，后者更接近“同一时间能运多少东西”。这里的类比只用于理解概念，实际访问还受协议、拥堵和目标服务影响。较大的带宽并不自动缩短每一次连接建立和请求响应的等待。
实际吞吐量为什么低于标称带宽
吞吐量是某段时间内真正传输的有效数据速率。无线干扰、同一家庭的其他设备占用、目标服务限速、传输协议开销，都可能使它低于接入套餐标称值。套餐常用比特每秒，下载工具可能显示字节每秒，两者的单位也不同。比较之前应先统一单位，并分清短暂峰值与持续传输表现。一次文件下载的结果，不能直接代表网页、会议与所有应用的体验。
目标网站和设备也会造成等待
当只有一个网站很慢时，目标网站自身处理请求、加载第三方内容或资源文件过大，都可能是原因。设备存储空间紧张、浏览器扩展过多、后台任务繁忙，也会拖慢页面呈现。此时切换线路未必解决问题。可以先观察同一设备的其他网页，再用同一网络中的另一台设备进行对照。比较时保持相近的时间与任务，避免把设备差异误认为线路差异。
按范围逐步缩小问题
先记录慢的是一个页面、一个应用，还是所有访问；再查看Wi-Fi信号、其他设备是否大量传输、移动网络是否仍有可用数据。随后暂停不必要的后台同步，以相同任务复查。如果基础网络正常，再检查客户端来源、系统兼容与已知服务使用条件。每次只改变一个因素，并记下原设置；频繁同时改动DNS、代理和线路，会使前后结果难以解释，也增加恢复原配置的难度。
把观察写成可以复现的记录
有用的记录包括设备类型、网络类型、问题出现的时间范围、具体任务以及已尝试的步骤。记录可以描述“同一网页在两种网络下表现不同”，不必填入没有测得的数据。向他人求助时删除账号、密钥和完整配置地址。阅读线路与延迟指南有助于继续区分抖动和丢包；涉及安装或权限的问题，则应回到设备适配说明核对。先确认问题发生在哪一层，再决定下一步。