speeding up MathJax considerably by using localStorage

[Pomax]

It would be nice if MathJax took advantage of localStorage by, when converting math blocks, storing the conversion result keyed on the original text in it. That way, when a page is reloaded, it won't need to run the conversion again, it can simply grab the fragment it already computed last time, and inject that directly into the page. For blocks that don't change (which is most page content) this would considerably speed up page load on reloads as well as revisits (my page, http://processingjs.nihongoresources.com/bezierinfo, would greatly benefit from this. It spends a long time in the MathJax conversion simply because it has a lot of separate blocks of math).

[dpvc]

Yes, this is an idea we have been considering (though there are some issues that would need to be worked out in order to make this work properly, e.g., the output includes id's that would have to be changed, the internal format would have to be recreated, and line breaking might have to be redone depending on the size of the enclosing container). But it is something we would like to do.

[Pomax]

For all the bits that get styled with HTML/CSS rather than MathML, there's the excellent and often overlooked <wbr> element that you can insert liberally. It's the "if you absolutely need to break the line, you can do it here". A bit like \linebreak[0] in LaTeX

[qbolec]

From reading https://github.com/mathjax/MathJax/wiki/Understanding-mathjax-performance I understand that one of the slowest parts of the process is measuring text as it by definition requires reflows. How about caching only that part: that is: what are the dimensions of a particular subexpression given font/size (and other things that affect the measurement).

[pkra]

That document is outdated (last edit Aug 2013). Especially the CommonHTML output requires very few measurements and the HTML-CSS output has significantly reduced its measurements. Caching those would not have been very effective though as the CSS of the context can influence them too much.

[dpvc]

With v3's increased rendering speed, and the lazy-typesetting extension, it is unlikely that a caching mechanism like this will be implemented.

[Pomax]

it's also an eight year old request, closing it out is good triaging =D

[dpvc]

I've been going through all the old issues and closing what I can. I know it has been a long time.