I am creating an app that has three (3) graphs shown to the user displaying radio data streamed from a server. The rendering of these graphs is relatively expensive; one currently uses a web worker to prevent jitter, and I am considering moving the other two to their own workers as well to free up performance on the main thread.
While the workers are effective in helping page performance, one of the issues is receiving the stream data in the worker. The data describing each graph is a relatively large piece of memory and cannot be sent without using transferable objects. My current solution for the one graph is to pack the data into a binary format, transfer it to the worker, and then parse it back. This creates a passable solution, but is somewhat hacky, and I am concerned is not viable given more than one graph. Another issue with this solution is desync between the rendering time of the canvas and its axes, which are rendered on the worker and the DOM respectively, creating a delay.
One solution I am considering is to connect to the websocket one time in each web worker, creating three connections from the one browser session. This would eliminate the need to transfer any data to the workers and theoretically should improve performance of the main thread, as well as avert desync issues. However, I am not sure if the performance overhead of three workers and multiple websocket connections will outweigh the benefits.
I first checked this question but it only addresses singular connections from workers. I am not sure if this solution will scale well to more than one worker. Is my solution viable, or is there a better way to share the stream data between multiple workers?