@tnabil I see your point. I’m pretty sure that the solution from the vendors that offer full browser testing capability is to use a Cloud account and scale the test on their infrastructure, assuming your non-production/staging environment can be accessed. It might be possible in your organization to make a financial justification for a paid Cloud account for browser test execution, since the script development work can be accelerated to a degree due to the simplification or abstraction. If you need to re-engineer a lot of the frontend code just to have runnable tests that is a labor cost. Besides scaling, Cloud execution has other realism advantages.
You might be able to take the hybrid test approach, limited to 5-10 full browsers, running in parallel with standard k6 protocol tests at a much higher request level, please see the linked example. To do this you would have at least two different functions (if each was complex, perhaps imported from separate scripts) and group them using scenarios. Of course you would still need to create the server-side/back-end test(s), but perhaps it would be sufficient to simply include the initial SPA home page (or whatever your “first request” is) and all of the API calls that are part of the SPA journey. The test report would include both the Core Web Vital type metrics and the standard k6 protocol metrics.
I have not used Cloud testing, but for on-premises load generation, I have successfully tested various SPAs with up to 30 parallel Chrome instances (headless) on a single AWS Windows host with a good deal of memory. Greater than 30 was overloading this host. In my experiments, I had more success with 1) a slower ramp-up than used with standard k6 protocol tests, and 2) keeping each browser open longer by using a loop on the main function, to save on the impact of terminating and starting new browsers. I believe I was able to accomplish at least a few thousand requests per minute but not 100K/minute. You might want to try your main workflow and see how far you can take it, but yes, some significant resources are needed. I have not used it, but distributed testing may be the workaround for scaling on-premises browser tests.
It has been many months since I have used the browser module, but I recall having to extensively log a test to figure out a nested frames situation for an ecommerce site. Take a look at these logging level options to possibly run your browser workflow(s) as 1 user/1 iteration and perhaps within the debug output (set “K6_BROWSER_DEBUG=true”) it will generate a list of the assets and other dynamic requests which you can consume for the actual load test. This site is another reference for K6_BROWSER_ARGS. You would need to turn off the debug logging for the actual load test; it is very verbose and would cause problems with the overhead. Perhaps write a shell script that runs the debug iteration and upon completion runs the main load test.