Nice! A welcome addition!

Too bad they're not using KaTeX [0] instead.

It renders the maths server-side, so there's no runtime needed.

An additional bonus is that the resulting math is copy-pasteable, which in the case of disply math might not be that useful (since most equations are to complex to be meaningfully copy-pasted with unicode), but it helps from inline math dissappearing when copy pasting texts.

But, that being said, I'm sure they had their reasons to do so. For one, MathJax seems more well-known by quite a bit so maybe it's the safer option.

1: https://katex.org/

For pages with lots of mathematics markup, it is far better (in terms of download size) to send the latex markup and the katex library to the browser, and render it there. I tried rendering the mathematics server-side using katex on my own website a while ago, and the div soup generated by katex takes up loads of space.

Original page (compressed): 10 kB

Page with server-rendered Katex (compressed): 50 kB

Katex.js (compressed): 80 kB

So after two pages it’s a net win to not render the mathematics server-side.

For my blog (e.g. https://daniel.lawrence.lu/blog/y2021m09d08/ with tons of math), I render the math serverside using MathJax and serve them as SVG images (with alt text for the visually impaired). They get cached too which is nice especially since many symbols are duplicated. Seems fast enough for me.

You're being modest. This is easily the most performant option... although it means losing interactivity (right clicking equations on GitHub allows copy to clipboard, A11y features, etc).

Running the JS client side, like GitHub, means blocking the thread. You're either going to be 1. delaying other JS from running, or 2. rendering late, shifting the layout – which is what GitHub has chosen: https://imgur.com/a/y47haf9

(Sending the rendered div's is a non-starter. Large document sizes delay domContentLoaded, slow down browsers, aren't shared cacheable resources, etc.)

Your approach, then. On your page there are 178 SVGs. Total gzipped size is 490KB. SVGO[0] gets that down to 311KB – that's 1.74KB transferred per equation. These are non-blocking, immutable, cacheable assets. Brilliant.

Upgrades:

- Figure out viewbox and inline height/width values on the HTML so no layout jank (aka "Cumulative Layout Shift"/CLS) occurs. Unsure if this is possible for inline math.

- Add `loading="lazy"` afterwards. Users that don't scroll the entire length of the page won't suffer unneeded downloads, and the inlined sizes will prevent late CLS for those that do.

- Maybe re-add interactivity? Cheap option: just support copying alt-text in a context menu.

[0] https://github.com/svg/svgo