Does iframe runs on the same thread as the owner?

Question

I have a CPU intensive work to do and i don't want to degrade the user experience. since web workers (http://ejohn.org/blog/web-workers/) are a new feature and are not supported by all browsers, i thought to open an iframe with an HTML + JS that will do all the dirty work and using some cross-domain communications to pass on the results. Unfortunately i noticed that the owner of the iframe suffers from the CPU work of the iframe window.

Does this behavior is as designed? is there a way to solve this?

Answer 1

As of early 2021, there is now the (weirdly named) Origin-Agent-Cluster header which allows you to request dedicated resources for an iframe. It is currently supported on Chrome (88+) with positive reception from Mozilla and Safari.

Origin-Agent-Cluster is a new HTTP response header that instructs the browser to prevent synchronous scripting access between same-site cross-origin pages. Browsers may also use Origin-Agent-Cluster as a hint that your origin should get its own, separate resources, such as a dedicated process.

[...] For example, if https://customerservicewidget.example.com expects to use lots of resources for video chat, and will be embedded on various origins throughout https://*.example.com, the team maintaining that widget could use the Origin-Agent-Cluster header to try to decrease their performance impact on embedders.

To use the Origin-Agent-Cluster header, configure your web server to send the following HTTP response header: Origin-Agent-Cluster: ?1 The value of ?1 is the structured header syntax for a boolean true value.

More details here: https://web.dev/origin-agent-cluster/

Answer 2

One way to sort of simulate multi-threadedness would be to have a Javascript function do a little bit of work, then call setTimeout with that same function; then the function will do a little work and call setTimeout again, and this cycle will continue forever or until they close the frame or you signal to stop working. MDN has a good example of how to set this up.

Between timeouts, Javascript should not consume any processor time. You might have to play around a little bit to see how long your timeouts should be -- 1ms is probably way too short, but 1s is definitely way too long. Another factor will be the processor speed of the computer running the job, so you might need to do some pseudo-benchmarking on the client's side via Javascript before you can determine how long to delay each time.

Answer 3

JavaScript is single-treaded. Separate tabs or windows may run in separate threads or processes depending on the browser, however you cannot communicate between these windows, so there is no way you can explicitly utilize more than one thread or process in JavaScript.

If it is a question of UI responsiveness, Rushakoff have a good answer. While JavaScript is running, no HTML rendering happens and the UI is not responsive. By using timeouts, control can be released back to the rendering/UI-thread periodically, giving a more responsive feel, even if it still only runs single-threaded.