OP says “as little JS as possible”. I’m seeing 830KB of JavaScript (254KB over the wire) on that page (plus another 14KB of JSON inside the HTML, of __NEXT_DATA__ bloat), spread across more than 20 files, when the only effects I can see are the scroll progress bar in the header (<1KB of value), the subscribe button (perhaps just barely 1KB of value), and SPA loading of other links; and loading /@PapyrusBlog and / via such SPA links fetches another 156KB (48KB wire) of JavaScript.
These figures are in no way light (even if they’re lighter than far too many sites). Given the positioning and the statement “as little JS as possible”, I was definitely expecting less than 5KB of JavaScript, perhaps even nothing beyond Plausible; having seen SPA functionality I’d be willing to increase that expectation to 25KB.
I’m with topicseed: Svelte would be a much more sensible starting point when seeking to use such a framework; SvelteKit can give you the same style of SPA stuff.
One last batch of remarks: most of the stuff in the “optimise images” step of that article is counterproductive. General content should not attempt to use lazy loading, it tends to make the experience worse, especially for distant visitors with higher latency but normally it doesn’t even help things for low-latency viewers. (next/image is wrong and foolish to enable lazy loading by default.) In the case of the logo specifically, if that’s the quill, that looks like it should be SVG—smaller and faster. And <code node="[object Object]">…</code> as the translation of the Markdown `…` is probably a bug.
These figures are in no way light (even if they’re lighter than far too many sites). Given the positioning and the statement “as little JS as possible”, I was definitely expecting less than 5KB of JavaScript, perhaps even nothing beyond Plausible; having seen SPA functionality I’d be willing to increase that expectation to 25KB.
I’m with topicseed: Svelte would be a much more sensible starting point when seeking to use such a framework; SvelteKit can give you the same style of SPA stuff.
One last batch of remarks: most of the stuff in the “optimise images” step of that article is counterproductive. General content should not attempt to use lazy loading, it tends to make the experience worse, especially for distant visitors with higher latency but normally it doesn’t even help things for low-latency viewers. (next/image is wrong and foolish to enable lazy loading by default.) In the case of the logo specifically, if that’s the quill, that looks like it should be SVG—smaller and faster. And <code node="[object Object]">…</code> as the translation of the Markdown `…` is probably a bug.