I seem to have a habit of rewriting this blog every time I get bored, but this time I swear I didn't do it on purpose! On the plus side, rewriting the blog is a good way to try out new things and different deployment strategies. On the negative side, it often takes over a weekend and I don't get much else done!
Over time I've evolved from a custom static site generator, to a self-hosted ghost instance, then most recently to next.js.
It started with lighthouse
I posted about my CMOS analog clock the other day and on a whim I ran a lighthouse report on the site. I was surprised to see this in "mobile" mode:
The "time to interactive" in particular was a bit of a surprise. On desktop its about 1s, but here its approximately a thousand years. One of the strengths of NextJS is how easy it makes it to do server side rendering (SSR) and server side generation (SSG). I'd spent quite a lot of time messing about with SSG and built it into a custom markdown to SSG pipeline in NextJS. Lighthouse seemed to suggest that bundle size was the big issue. I ran the profiler quickly and I'm definitely not an expert, but with simulating a "Fast 3G" connection and "4x CPU slowdown" the best I could tell was it spent about 3 seconds loading the bundle and another 2 seconds rendering.
I tried a few different things to reduce bundle size, including replacing some CSS and dynamically loading components but nothing really made a dent. Using Next's image optimisation was more successful and seemed to make a huge difference to the bandwidth for more image heavy posts, but time to interactive was still fairly low.
Looking at Zola
I decided to run a quick proof-of-concept to compare to a pure static site generator. I chose zola, which is a rust-based static site generator that is quite straighforward to use. Like most rust things, speed seems to be a big consideration and builds are definitely very speedy (this site takes about 300-500ms to build from scratch).
To get started without setting up an entire pipeline, I copied the minified CSS from the NextJS production site and quickly converted a few markdown articles to the Zola format (mostly just changing the front matter to
TOML). The lighthouse report for Zola was green across the board.
|NextJS Unoptimised||NextJS Optimised||Zola|
|CMOS Clock||4.6 MB||2.1 MB||4.1 MB|
|NextJS rewrite||1 MB||1 MB||0.006 MB|
Zola absolutely smashes NextJS on text heavy pages, but gets beaten on image-heavy pages thanks to Next's image optimisation. Zola does have some support for optimising images which might be useful in closing the gap.
Did it make a difference?
Overall I think the Zola website will load and become interactive much faster, but without some serious image optimisation it might not have much benefit for more image-heavy posts. NextJS is a fantastic framework, but in this case where I don't really need interactivity and I just want to serve HTML blog pages, then I'll be migrating to Zola.