Cypress测试在CI流水线运行耗时远高于本地的原因排查

• 网络链路与解析策略差异
  本地计算机跑测试时，通常通过本地宽带出口就近匹配Azure静态站点关联的CDN POP节点，DNS解析会携带本地子网信息，请求往返延迟基本在10-20ms区间。而on-prem构建控制器、Azure VM的网络出口往往存在额外的链路跳转：比如企业专线强制将构建流量导至核心出口节点再转发公网、Azure侧配置了强制出站的安全网关/防火墙、DNS解析未携带源子网信息导致CDN解析到远端节点，单请求延迟会升到200ms以上。Cypress执行过程中每个页面加载、交互操作的等待时间会随网络延迟线性累积，这种延迟差直接会把总测试时长拉高到本地的2倍。此外企业侧的QoS带宽限制、出站流量限速，也会导致静态资源加载、接口请求的传输耗时上升，甚至触发超时重传进一步拉长总时间。
• 浏览器与Cypress运行环境的配置差异
  本地运行Cypress时，浏览器默认开启GPU硬件加速，JS执行、DOM渲染效率远高于无GUI模式；而CI环境（不管是on-prem控制器还是Azure VM）默认以无头模式运行，多数场景下没有配置虚拟显示的硬件加速支持，甚至直接禁用了浏览器硬件加速，单步页面渲染速度通常仅为本地带硬件加速环境的50%，和观测到的耗时翻倍表现完全吻合。
  除此之外，CI流水线往往会默认开启Cypress的全量日志能力：比如全测试流程录屏、每步操作自动截图、网络HAR日志抓取、控制台日志落盘，这些操作本身会占用磁盘IO与浏览器资源，进一步拉长执行时间。如果是在容器环境中运行Cypress，未配置正确的沙箱豁免参数，也会导致浏览器进程被额外的权限限制拖慢。
• 隐性的资源抢占与性能限制
  不要被实时监控的CPU、内存数值误导，以下两类隐性限制不会在常规监控中体现：
  • on-prem构建控制器通常为多任务并行节点，同一时间可能运行其他代码扫描、打包任务，即便CPU内存空闲，磁盘IO、网络出口带宽可能已经被其他任务占满，Cypress进程因IO优先级较低，频繁进入等待状态。
  • Azure VM如果使用可突发系列（如B系列）机型，一旦之前的任务耗尽了CPU性能积分，VM会被强制降速运行，哪怕实时CPU使用率仅20%，实际执行效率也会大幅下降。
• 终端安全软件的扫描拦截影响
  本地计算机往往会将Cypress进程、关联的浏览器程序加入安全软件的信任白名单，不会对其网络请求、文件读写做全量扫描；而企业管控的构建控制器、Azure VM通常部署了企业级EDR、杀毒软件，会对Cypress发起的每一次网络请求、每一个写入磁盘的日志文件做实时扫描，甚至会拦截部分静态资源请求触发超时重传，这种累积影响在跑完整套测试时，很容易让总耗时较本地翻倍。

内容的提问来源于stack exchange，提问作者onimougwo