Well, it seems easy enough to test if you think you are getting efficiency 'for free'. Dump a 10GB binary into a SingleFileZ, and see if your browser freezes.

I just ran a test on a 10GB HTML page and called window.stop() via a 100ms setTimeout, which, in my opinion, simulates what would happen in a better-implemented case in SingleFile if the call to window.stop() were made as soon as the HTTP headers of the fetch request are received (i.e. easy fix). And it actually works. It interrupts the loading at approx. 15MB of data, the rendering of the page, and it's partially and smoothly displayed (no freeze). So it's not totally useless but it deserves to be optimized at a minimum in SingleFile, as I indicated. In the end, the MDN documentation is not very clear...

Edit: I've just implemented the "good enough of my machine fix" aka the "easy fix", https://github.com/gildas-lormeau/single-file-core/commit/a0....

Edit #2: I've just understood that "parent" in "this method cannot interrupt its *parent* document's loading" from the MDN doc probably means the "parent" of the frame (when the script is running into it).