Experimental feature: disableProxy

What would you like?

This has been raised in the past, but the original author gave up on it (and Cypress, unfortunately). Closed (but not resolved) issue is here for context: https://github.com/cypress-io/cypress/issues/22319#issuecomment-1355431707

This feature would add the experimental option to completely disable the Cypress proxy and let the running browser (and Cypress) speak directly to the network.

Why is this needed?

As explained in the docs, Cypress uses a proxy for, among other things, modifying code which potentially would break Cypress during runtime. However, the docs also acknowledge that not all sites are affected by such code, and even provides an option (modifyObstructiveCode) which partially disables it. The proxy is also used for several other features.

However, the proxy also incurs several notable penalties:

• No HTTP2/3 support (see especially https://github.com/cypress-io/cypress/issues/3708 for implications)
• Only supports gzip compression (see https://github.com/cypress-io/cypress/issues/6197)
• Unpredictable network behavior (outgoing headers modified etc)
• Most importantly - demonstrably severe performance impact, especially for modern web apps which use chunking extensively.

So while the proxy certainly has important uses, there should be an option to disable it completely if a team determines they have no use for the extra functionality and would like to optimise performance instead.

Other

While I advocate for Cypress personally at my workplace, I am seeing rising pressure from colleagues to consider Playwright instead - primarily due to performance reasons. The author of the original issue ended up doing the same.

I love Cypress approach to testing, but I can only acknowledge that performance is - and has been for years - one of the primary weaknesses of the framework. The team has done impressive work over the last releases (especially in 9 and 10) to address many sticking points, but much more needs to be done in order to level the playing field with competing solutions - especially Playwright. I believe this would be a step in the right direction.

[lmiller1990]

It would be helpful to know if there is anything in the proxy without Cypress cannot function altogether

This is what I am trying to find out. I’m sure there is something around how Cypress injects itself - whether we can decouple that and have some option to make the proxy do less and thus improve performance is another question.

@adam-thomas-privitar I think that’s actually a bug that is fixed by https://github.com/cypress-io/cypress/pull/25209. You can test this out right now by installing the pre-release with that patch: https://github.com/cypress-io/cypress/commit/6b78454e0d78346729263e5ab0b77c856a43ce42#comments. If you do try it, let me know if it helps. I also want to use Vite and I want to go fast.

Edit you tried it, thanks! I still think we can go faster, but if you see anything that seems like it’s unusually slow, it’s probably a bug - you should create an issue.

[lmiller1990]

I am also curious about this. My understanding is Cypress cannot function without some sort of network proxy. Not only do many features depend on it, but I (think) there’s some fundamental requirement for some sort of network proxy (could be mistaken, but the concept of a network proxy has been in Cypress since the very early days, far before things like cy.intercept existed.

Whether we can make some of the features opt-in or opt-out would be another discussion.

Before doing this, since the goal is to go faster, there’s a better alternative - updating our network stack to some more modern libraries, and using HTTP/2, which is up to 10x faster. I think this would help greatly with performance.

There is an issue tracking that here: https://github.com/cypress-io/cypress/issues/3708.