> Anything to make static website builds faster is welcome
Genuine question, but why? My assumption here is that builds are infrequent and static sites gravitate towards being smaller in size, and that in most situations you’re building as an automated action following the addition/modification of a page. Does it matter if the build takes 1s vs 20s?
Even dynamically building during authoring, I rarely run into situations where ruby/js static site builders feel overly slow. Curious if my assumptions of how people are using these are wrong however so would love to hear your take.
I have 450 posts and about 300 more drafts with Jekyll.
In development it takes Jekyll 32 seconds[0] to do a full build and I've done my best to eliminate as many performance killing nested loops as possible. If I use --incremental it takes about 3 seconds, so my normal writing flow is to split my browser and code editor and I see real-time live reloaded feedback in 3 seconds.
It's pretty good, but some changes require a full build and waiting 30 seconds stinks. If I could snap my fingers and have a fully compatible Go solution that built it in 3 seconds all the time I'd switch without thinking.
Gojekyll isn't compatible with a few plugins I use and switching ~700 posts, a bunch of templates and a few custom plugins to Hugo isn't worth it for my use case.
On the other hand I'm locked into Jekyll 3.X because I can't get Jekyll-Assets to work with any other version so at some point I'll switch but I'm not looking forward to porting that many templates and posts. If it comes down to it I'd probably end up writing a custom tool to convert everything especially since I do custom'ish things with front matter like create a table of contents for each post. It'll require a bunch of string parsing.
[0]: This is on a 9 year old quad core i5 3.2ghz workstation with an SSD.
My team manages several static sites. They're each hundreds/thousands of pages in size. Here's why we like faster builds.
* Fast builds are way more pleasant during development. "Incremental" per-article builds help, but not in all scenarios. Nothing kills my motivation faster than having to wait 30 seconds to preview a fix.
* Fast builds help us avoid jams in our automated push-live systems. Sometimes we have many editors updating pages during a big event. You could consider many different trade-offs when deciding how to manage these queues. But a fast build time erases a lot of those conversations.
We use 11ty on most of our sites. We've found 11ty itself to be fairly performant. The slugs tend to be everything related to processing assets: JavaScript bundles, Sass builds, image manipulation, etc. By streamlining those activities, we can usually get a site build down to just a few seconds.
That said, "instant build" is the dream that animates the best conversations on our team, and we've started building our own static site generator. Our SSG can run both on the server and in the browser. We want our editors in our CMS to be able to get instant, true previews of the page they're editing. Then we want to be able to push single-article builds live, instead of always rebuilding the whole site. It's early days yet. Maybe you'll see it on a "Show HN" some day.
Genuine question, but why? My assumption here is that builds are infrequent and static sites gravitate towards being smaller in size, and that in most situations you’re building as an automated action following the addition/modification of a page. Does it matter if the build takes 1s vs 20s?
Even dynamically building during authoring, I rarely run into situations where ruby/js static site builders feel overly slow. Curious if my assumptions of how people are using these are wrong however so would love to hear your take.