Proxy Performance suite skipped: test-page-speed.cypress.io fixture needs re-hosting

[ryanthemanuel]

The Proxy Performance suite (packages/server/test/performance/proxy_performance_spec.js) is skipped as of #34527. It cannot be re-enabled until its fixture is served from somewhere that tolerates the load it generates.

What happens

test-page-speed.cypress.io/index1000.html intermittently returns a GitHub Pages error page instead of the fixture. When it does, the page issues 5 requests rather than 1001:

http://test-page-speed.cypress.io/index1000.html
https://test-page-speed.cypress.io/index1000.html
https://github.github.com/pages-staticassets/primer-tiny.css
https://github.github.com/pages-staticassets/gh.svg
https://github.github.com/pages-staticassets/lock.svg

That is the expected 5 to be at least 1000 failure seen on develop — the 5 is literally the error page's own request count. Both http:// and https:// entry points are affected.

Why we think it is load, not a broken artifact

Single requests are completely reliable — repeated curl probes, and a 300-request concurrent burst, returned the fixture every time. It only fails under the access pattern the suite uses: ~15 MB across 1000 requests per capture, 16 captures per job run, on every PR (~237 MB per run). GitHub Pages' documented soft bandwidth limit is 100 GB/month.

The timing fits. This suite used describe(url, { retries: 15 }, fn), a signature Mocha 7 does not support, so it registered zero tests for a long time. #33804 repaired that in May 2026, taking the fixture host from approximately no traffic to hundreds of MB per CI run overnight.

Ruled out

• A Cypress proxy regression. Timings on successful captures match the last green develop run almost exactly (baseline 1269–1440 ms vs 1331–1553 ms; intercepted 2.6–3.7 s vs 2.3–3.8 s).
• Domain verification / TLS. protected_domain_state: null, pending_domain_unverified_at: null, certificate approved through 2026-09-28.
• A stale Pages artifact. cypress-io/cypress-fetch-page was archived with its last Pages build dating from 2019-05-20. It has since been unarchived and rebuilt (clean, 40.8 s, no error). The rebuild did not help.
• Moving the fixture local to the test. Near-zero RTT would remove the real network latency and HTTP/2 behaviour the suite exists to measure, so the numbers would stop meaning anything.

What is needed

Serve the same static fixture from a host that tolerates this burst pattern, on a real remote domain so the suite keeps measuring real network characteristics. The content is ~16 MB of static files (one HTML page plus 1000 copies of a 14.8 KB JPEG) and is recoverable from cypress-fetch-page, which clones normally.

Once it is re-hosted, remove the .skip in proxy_performance_spec.js and point URLS_UNDER_TEST at the new origin.

Also worth considering

At 16 captures per run on every PR, this job is expensive against any host. Trimming the matrix, or running it on a schedule rather than per-PR, would cut the load by a large factor and is worth deciding at the same time as the new home.

Notes

The failure rate observed on 2026-08-07 is partly inflated by diagnosis — the suite was run against the host several times in one hour while investigating.

Mitigations already in #34527, which stay useful whenever the suite is re-enabled:

• capture waits on Network.loadingFinished counts rather than an idle timer, so it stops exactly when the HAR is complete enough
• a load that never requested the images is rejected in ~1 s instead of stalling for the full timeout
• failures report started/finished/failed counts and the first URLs requested, so this condition is identifiable at a glance

[baus]

We discussed re-hosting these assets to S3 or another host, but we landed on a solution similar to #34307. Basically we need to start a server local to CI which introduces some latency for this test to be effective.