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