[joppy]

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.

[dllu]

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.

[lelandfe]

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

[dllu]

> 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.

That's a great idea, I should do that. Right now I apply the height and offsets from the SVG file (via vertical-align and height) so that it flows nicely but I should add width too. It is trivially doable since the SVG does contain the width.

e.g.

    <img src="//daniel.lawrence.lu/texcache/683524188b1547a2a4466541ff07f2d6f83f599bi.svg" alt="\mathbf R(\mathbf T)" style="vertical-align: -0.838ex;height:2.843ex;">

[hegemon8]

Did you open-source the source code for trie DS visualization in your Aho-Corasick string matching algorithm blog?

[dllu]

Feel free to right click and view source and use it for whatever. I'll release it on Github with an MIT license when I get to my computer later...