16

The current beta version of MathJax 2.6 implements a new renderer that is faster and can be rendered on the server side:

Improved CommonHTML output. The CommonHTML output now provides the same layout quality and MathML support as the HTML-CSS and SVG output. It is on average 40% faster than the other outputs and the markup it produces are identical on all browsers and thus can also be pre-generated on the server via MathJax-node.

MathJax is great if you need to display any Math in a post, and pretty useful for some other things like chemical formulas as well. But it is a pretty large javascript library that needs to be loaded, and the amount of processing it does is very noticeable on any math-heavy page. Just the javascript alone adds ~115KB out of ~600KB in total for a MathJax enabled SE frontpage.

Using server-side rendering of MathJax it wouldn't be necessary to load the js library and do all the processing on the client just to view MathJax, it would only be necessary if you actually edit or interact with the formulas. Visitors that simply view a few pages would never even need to load the MathJax library.

This would also allow for question titles with MathJax to be displayed correctly on sites that don't have MathJax enabled, which is a problem with the hot questions list.

Server-side rendering would also provide the option to allow sites the use of MathJax where it was previously too expensive compared to the small amount of posts that actually needed it.

I know that this is likely a pretty large project, but as SE tends to value site performance highly I think it might be worth it. There are currently 29 sites that use MathJax on the network, so this would affect a large part of the entire network.

Improve this question
3
  • 1
    One thing to keep in mind: the MathJax menu that allows you to access the TeX code or the MathML translation would not be available when the math is processed server side. There would need to be at least some javascript loaded in order to make that work (and that still had to be implemented in server-side MathJax). Also note that the pages themselves would be larger since the MathJax output is far larger than the original TeX code, so some of the gain in not loading MathJax is lost in loading larger pages.
    – Davide Cervone
    Commented Oct 23, 2015 at 10:07
  • @DavideCervone I did think about the context menu, lazily loading it on right click might work and most visitors would probably not use it anyway. The size of the HTML and CSS is a problem I didn't consider, and it looks like I vastly underestimated it (~200kb for the Math.SE frontpage, ~3MB for a question with lots of formulas). But at least it seems to compress well, the gzipped version is less than a 10th of the size.
    – Mad Scientist
    Commented Oct 23, 2015 at 10:20
  • related on mathoverflow: stackoverflow.com/questions/39269611/…
    – Ciro Santilli OurBigBook.com
    Commented Jun 12, 2019 at 13:29

1 Answer 1

Reset to default
2

Well, there are currently two things which aren't pre-cooked:

  1. Titles, as the only transformations done on them are trivial (aside from letting MathJax at them on enabled sites).
  2. Comments, there aren't any transformations on them at all (aside from letting MathJax at them on enabled sites, again).

The moment those are also precooked including use of offline-MathJax, read-only interaction would no longer need MathJax at all.
It might make sense to look into doing syntax-highlighting server-side as well... though there the savings in processing and dependencies client-side will probably be overshadowed by the additional bandwidth-cost in serving each individual post.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .