8

I'm writing an html parser in js which handles and manipulates a lot of nodes.

I would like to split the overhead so I would not cause the UI to freeze.

I thought about using a web Worker but it doesn't have DOM access so currently I'm using setTimeout(0) in my loop to not freeze the UI, but I thought about creating multiple blank iframes and use their window context to do this task.

My question is if it's really considered to be a separate execution context and runs parallel to the main one or it will still freeze the main UI?

AHeyne
  • 3,377
  • 2
  • 11
  • 16
avi dahan
  • 539
  • 3
  • 19
  • 1
    If you use an iframe as a separate execution context, you’ll have to use messages to communicate between contexts. Why not do the same thing with a worker, and leave only DOM-specific code in the main thread? – MTCoster Jan 10 '19 at 17:14
  • 1
    @MTCoster because code inside a blank iframe ( no src ) can access the main dom – avi dahan Jan 10 '19 at 17:16
  • 1
    I didn’t realise that. But the question still stands, why can’t you separate your DOM-specific code from your processor-intensive code and connect them using messages? – MTCoster Jan 10 '19 at 17:17
  • 1
    @MTCoster I can , but if iframe holds the same benefits of a web worker it’s much easier using an iframe . – avi dahan Jan 10 '19 at 17:19
  • Possible duplicate of [Do frames and iframes have isolated javascript contexts?](https://stackoverflow.com/questions/8215061/do-frames-and-iframes-have-isolated-javascript-contexts) – StriplingWarrior Jan 10 '19 at 17:26
  • 1
    @StriplingWarrior not quite, it’s still doesn’t answer my question if I’m running load intensive code inside an iframe will the main ui continue to load in parallel or not – avi dahan Jan 10 '19 at 17:29
  • The answer is yes, each iframe is in a separate thread. – Barmar Jan 10 '19 at 18:15
  • I would strongly recommend *not* using frames as your threads of execution. There's no guarantee that the frame will always be able to access the parent DOM or vice-versa, and I can imagine several reasons why any particular browser might disable such things. It's 2019, not 2005: use web workers and communicate with the parent via messages, don't employ hacky and unreliable workarounds like iFrame-as-a-thread. – IceMetalPunk Jan 10 '19 at 18:47
  • I asked your question in a comment on the answer of the "possible duplicate" I posted earlier, and [Slaks responded](https://stackoverflow.com/questions/8215061/do-frames-and-iframes-have-isolated-javascript-contexts/8215098?noredirect=1#comment95238543_8215098) that "all execution contexts capable of accessing each other's windows run on a single thread." So I would guess that the approach you're suggesting wouldn't actually have the intended result. However, if you find otherwise I'd really love to hear about it. – StriplingWarrior Jan 15 '19 at 20:51

2 Answers2

1

It actually depends on the browser. For example, mobile browsers are less likely to put different embedded iframes in separate threads/processes due to the compute overhead.

But as of early 2021, there is now the (weirdly named) Origin-Agent-Cluster header which allows you to explicitely 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/

joe
  • 3,752
  • 1
  • 32
  • 41
-1

Yes, JavaScript in an iframe runs in its own thread, it doesn't block the parent window. It's mostly like a separate window or tab, the main difference is that it's rendered within the parent frame, and can refer to the parent using window.parent.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • 1
    It seems that the iframe does effect the main ui , if i'm inserting a blank iframe and injecting a script that will just loop for 5 seconds the main ui will also freeze , so am i doing something wrong? the iframe needs to be on different origin? – avi dahan Jan 17 '19 at 13:17
  • 1
    As @avidahan mentioned, this this answer is incorrect (at least with Chromium 75). An infinite loop in an iframe (same-domain or cross-domain - it doesn't matter) will block the parent window's main thread. Even a link opened with `target="_blank"` can apparently block the opener window if you don't use the `rel="noopener"` attribute. I'm wondering whether there's the equivalent of `noopener` for iframes: https://stackoverflow.com/questions/56589672/creating-an-iframe-in-separate-process-so-it-doesnt-block-the-main-thread-of-th –  Jun 13 '19 at 23:21