This is a browser level detail. You do need to have the tab visible on the screen to get processing resource allocated to the tab.
As this is implemented at Browser level it is not something TensorFlow.js can change. The reason for this is that many people have tens of tabs open, if all tabs could have unlimited processing your computer would fast come to a halt or use battery for laptop/mobile pretty fast. Thus only active tabs are given most resources.
As you mentioned, Web Workers at the domain level may be a good bet here. Not sure what the problem with React is, as I am a vanilla JS guy myself, but WebWorkers are well supported at the browser level:
https://caniuse.com/webworkers
Remember you do not have DOM access in web worker, so you will need to stream data to it if you are taking data from say webcam or something, process, and stream back without using DOM elements.
Thus you would also need offscreen canvas support for WebGL acceleration I believe, which is not well supported on iOS / Safari / Firefox:
https://caniuse.com/offscreencanvas
More details in this blog:

  

      Medium – 19 Sep 19
  

  
    

Webworker in TensorFlowjs

  We are excited to announce that TensorFlow.js will begin supporting Web Workers in its next release.

  
    Reading time: 2 min read
  

  

  
    
    
  

  


Also we discovered recently that WebGL on WebWorker will still block main GUI:
  

      github.com/tensorflow/tfjs
  

  
    
  
	  
  

  
    
      TFJS WebGL on WebWorker still blocks GUI 2
    

    
      
        opened 
        
          
        
        Aug 11, 2021
      
      


      
        
          
          jasonmayes
        
      
    

    
        
          type:bug
        
    
  


  
    After investigating a [report by a user](https://discuss.tensorflow.org/t/how-to…-get-the-duration-of-predict/3311/18) who was attempting to use web workers + tfjs to reduce lagging of GUI when model performs inference I have noticed that when using backend "webgl" web worker makes no effect on executing code in a separate context as this does not apply to GPU.

I have confirmed that by setting backend to "cpu" there is no performance issue, as the TFJS execution correctly is executed on a new thread, such that the browser DOM updates are not interfered with. I have also confirmed that browser relies on GPU to update DOM for anything visual - not CPU.

Thus the request here is how to limit "webgl" execution to leave enough processing for DOM updates for other user tasks to prevent this "jankiness" from occuring.

Demo of issue:

https://codepen.io/jasonmayes/project/editor/DBYaRj

Simply change first line of tfWorker.js to import one of:

`importScripts('dist/cpu.js');`

or for WebGL backend change to:

`importScripts('dist/main.js'); `

Confirmed this issue across devices including Windows 10, Desktop, Chrome and also Xiaomi 8 (Android phone with Snapdragon 845 processor)

Example output from Chrome Dev tools shows GPU block when using WebGL backend and also that all execution comes from WebWorker.js.

![unnamed](https://user-images.githubusercontent.com/4972997/128932303-e422ed1d-ef87-46dc-bc36-ee2aac0fe260.png)
  

  

  
    
    
  

  


We have found a potential fix for this but not pushed live yet. This is due to how the GPU is shared on the browser and again is not TFJS issue itself, but we found a workaround for now.
I assume this will gain support over time, but still relatively new right now, in which case you may want to force Web Assembly backend instead:

  
      

      blog.tensorflow.org
  

  
    

Introducing the WebAssembly backend for TensorFlow.js 2

  We’re happy to announce that TensorFlow.js now provides a WebAssembly (WASM) backend for both the browser and for Node.js! This backend is an alternative to the WebGL backend, bringing fast CPU execution with minimal code changes. This backend helps...