closed as off-topic by quid♦, Surb, Shailesh, Thomas, achille hui Jun 28 '16 at 14:39
- This question does not appear to be about Mathematics Stack Exchange or the software that powers the Stack Exchange network within the scope defined in the help center.
Mathjax performance depends on several factors, like:
- the browser you use
- the hardware in your computer
- your internet connection/latency
If you want to improve the performance of mathjax, you think of a couple of things:
Use a better computer. I did a short test, and if run a page with much mathjax at my 5 year old laptop, it takes around 4 times longer, then if I run the page at my newest computer.
Download local fonts. There are two options. You can either download the STIX fonts locally, or download the TeX fonts locally. For the TeX fonts, download mathjax 2.2 from this page: http://www.mathjax.org/download/. Once downloaded, go to this map:
fonts\HTML-CSS\TeX\otfand install all the fonts in this map. If you prefer the look of the STIX fonts, you can download them from here: http://www.stixfonts.org/
Use Firefox in combination with MathML rendering I just found this out, and I'm amazed by how much faster MathML rendering is compared with HTML-CSS rendering. This only works in firefox. You can turn the MathML rendering on by right clicking on a math formula:
Math Settings -> Math Renderer -> MathML
Here is more information about MathML rendering:
The NativeMML output processor uses the browser’s internal MathML support (if any) to render the mathematics. Currently, Firefox has native support for MathML, and IE has the MathPlayer plugin for rendering MathML. Opera has some built-in support for MathML that works well with simple equations, but fails with more complex formulas, so we don’t recommend using the NativeMML output processor with Opera. Safari has some support for MathML since version 5.1, but the quality is not as high as either Firefox’s implementation or IE with MathPlayer. Chrome, Konqueror, and most other browsers don’t support MathML natively, but this may change in the future, since MathML is part of the HTML5 specification.
The advantage of the NativeMML output Processor is its speed, since native MathML support is much faster than using complicated HTML and CSS to typeset mathematics, as the HTML-CSS output processor does. The disadvantage is that you are dependent on the browser’s MathML implementation for your rendering, and these vary in quality of output and completeness of implementation. MathJax relies on features that are not available in some renderers (for example, Firefox’s MathML support does not implement the features needed for labeled equations). The results using the NativeMML output processor may have spacing or other rendering problems that are outside of MathJax’s control.
I don't think it is MathJax that is the problem, but rather the nature of the way web pages are formatted. MathJax has to generate a bunch of
span blocks, which takes time for a browser to render. While we're writing posts, these get (re)rendered all the time.
The solution to this problem might be implementation of one or more of the feature requests:
Make a better SE parser of what formulas need rerendering, so that MathJax has less rerendering to do.
I expect this to be very hard to implement, and would probably be buggy.
Make a delay in rendering, as it is with the syntax highlighting.
In other words, formulas get displayed as a source (
$formula$), until the poster has stopped typing for a short period of time, let's say 3 or 5 seconds. After such a delay, post's formulas would get rendered as we're used to.
Add a "Don't process formulas while I'm typing" checkbox.
This would go either somewhere near the post-writing area, or in the profile (or, preferably, both, with the one in the profile being the default state), and could mean either "don't process at all" or "behave as I've described in the item 2 above".
Some kind of delay as described in 2 and, implicitly, in 3, but with the delay time growing with the post size (up to a limit of, IMO, no more than 30 seconds).
This way, shorter posts (which are not troublesome) would not be affected, while the longer ones would be so hard on our computers. I leave the definition of "length" here opened. It might be the number of characters, which implements trivially, but could also be the number of formulas (which in itself takes some parsing).
I think that this (as well as, maybe, item 3) would warrant a "Process now" button to do a single rendering when the poster requests it, so that (s)he doesn't have to wait unnecessarily.
The way things are now, I type my longer posts in gvim, and then copy/paste them here. It's not ideal, but for me it is an acceptable workaround.