I've thought about the same concept before too. The answer to your question rendering the three js on server and displaying it on an older machine will be something like this:

You are going to have to render three js on a server then basically live stream it to the client then capture the client's controls and send it back to the server to apply them but latency is going to be a pain in the ass so better write your code nice and neat and a lot of error handling. Come to think about it Google stadia does the same think too when you play games on youtube.

Server Architecture

So roughly thinking about it I would build my renderer backend like this:

First create a room with multiple instances of your three js code. => this basically means creating multiple (i.e index.js, index1.js, index2.js, etc...) Then Now decide if you wanna do this with the Straight Forward Recorded and Stream method or capture the stream directly from the canvas then broadcast it.

Recorded and Stream method

This means you create the js room then render and display it on the server machine then capture what is displaying on your screen using something like OBS studio then broadcast it to the client. I don't recommend this method.

OR

captureStream() method

After creating your room in your server run the three js code then access the canvas you are rendering the three js code in like this:

var canvas = document.querySelector('canvas');
var video = document.querySelector('video');

// Optional frames per second argument.
var stream = canvas.captureStream(60);
// Set the source of the <video> element to be the stream from the <canvas>.
video.srcObject = stream;

Then use something like webrtc and broadcast it to the client.

This is an example site you can look at: https://webrtc.github.io/samples/src/content/capture/canvas-pc/

Honestly don't ditch the client interaction idea. Instead write code to detect latency before hand then decide to enable it for that specific client

Hope this helps