Eight minutes!? That’s over 100ms of CPU time per page. I’m baffled and more than a little horrified that you would call that highly optimised. I would honestly expect anything calling itself highly optimised to be doing that in closer to 8 seconds. 1.7̅ms is ample for something carefully put together, probably even in JavaScript and with a database (fetch everything up front in one or so queries), though it’ll certainly be easier in a language like Rust. I admit I’d be decidedly impressed by a reasonably-featured JavaScript SSG doing 18,000 pages in 8 seconds; but more practically, in a JavaScript ecosystem, I’d be targeting definitely under a minute.

I will admit I’ve grown used to Rust code and code that’s been designed to be fast. (Zola’s not that, by the way; it makes many decisions in favour of subjective ergonomics and flexibility at enormous runtime cost, as well as doing a lot of theoretically-unnecessary cloning and such all over the place, which could speed things up a lot if it were sorted out somehow (I haven’t contemplated the matter). For my own website with some admittedly very complex templates, and that’s probably Zola’s slowest part, it’s scaling at about 2ms per page with a warm disk cache. Actually, it does some multithreading, but much of the most expensive stuff in the process isn’t parallelised, so repeated runs average using almost a quarter of my 16-thread laptop. I feel I should multiply that 2ms by something, but I’m not sure quite what!)

Edit: Later on the page: “As of October 2020, ElderGuide.com has ~20k pages and builds in 1 minute 22 seconds.” 4ms wall time (16ms if still operating on four cores) is much more encouraging. I guess the page could do with revision. Later still, “Build times on our ~20k page site are routinely less than 10 minutes on a modest VM.” which seems to be the first set of figures again.