[lelandfe]

The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9. Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win.

You're right on the money with the server costs though.

[diegof79]

> Browser JS engines are single threaded

The JS interpreter is single threaded. But, you can offload the work to a web worker, that runs another instance of the interpreter in a separate thread.

Also for rendering LaTex it’s possible to optimize the rendering algorithm using WASM.

I’m not saying that MathJax does that, or it has good performance. But, there are options to optimize the client side rendering.

[lelandfe]

Workers lack document access and have to schedule updates with the main thread. That puts us back where we started (plus the overhead of starting the web worker).

I don't know enough about the state of WASM today to say the same. Circa 2018 I know that it lacked DOM manipulation.

(In some distant year I will figure out the incantation to avoid getting sniped when talking about this stuff. I think I rewrote that line 4 times.)

[osrec]

It doesn't put you back where you started at all. One thread aggregating the results from other workers and applying them to the DOM is not at all the same as a single thread doing all that work on its own.

[lelandfe]

Let me rephrase: distributing work to web workers won’t be faster in first page load than images in this conversation.

Because we have to participate in the main thread either way, prerendered images will always paint faster. There is simply too much action in the thread during the initial GitHub page lifecycle. The 40-50ms (~one long task) cost of spinning up a new web worker just solidifies that.