Jekyll Build Time

I wonder what website build performance will be like when he gets to 4,000 posts. Slow build times are why I have ruled out converting my website to Jekyll or Hugo. I’ve got over 4,000 active posts (and many with images) on my 14-year-old website. I create about one to three new posts per day. I can’t imagine writing a post, waiting several minutes for the website to build, and then copying the files over to a server each and every time.

He made a lot of customizations to make things work faster. If he changes themes at some point In the future, he’ll need to redo the customizations.

I think the challenge for static site generators is that they were designed to be used for sites that don’t change often; e.g. corporate web sites. In other words, ststaic content. But now we have people, trying to shoehorn it for use with sites that update more often; e.g. blogs. Hence, the need to hack together work arounds. It’s klugely.

Best to use a system designed for dynamic web sites that have frequently updated content: e.g blogs. Ghost, WordPress, etc. do that well.


  1. I found this comment on this article which I think gets across my point more clearly.

    Learning programming languages is like reading the instruction manual of an IKEA desk. Solving problems is like building the actual desk.

    Ideally, you want to do both. Just don’t forget that actually building the darn thing is all that matters.

  2. I broadly agree with what you’re saying. One correction, though: Hugo builds sites really quickly (in my experience less than a second for thousands of pages).

    Also, you’d be crazy not to use a host like Netlify and github/bitbucket integration (another thing to learn, of course, but worth it if you’re building any software anyway.)

    I’ve run a fairly large (~2000 pages, 3,000 visits a day) work site for just under 3 years using Jekyll. I’ve been thinking a lot about the pros and cons of this lately and, overall, would recommend it. The main advantages are speed and security. Running a secure, fast WordPress install is a PITA, especially if you’re a small team.

    It’s also a lot easier to create custom themes and data in Jekyll.

    Downsides are buildtimes (although YMMV: the same site takes ~6m to build on a 2014 Macbook Air, ~50s on a Mac Mini with Ubuntu installed on it, and ~3s with an –incremental build switch) and Jekyll’s obtuseness when it comes to things like generating a menu from a list of pages in a folder automatically. It’s just really dumb when it comes to basics like this.

    Used Jekyll on my personal site for 6 years. Tried WP again for a week. It was horrible: Jekyll is so much cleaner, simpler and more transparent.

    Still, you’re right, I think. Static site generators are best for… static sites. It’s legitimate to use APIs to access updated data, but only if you’re happy updating this data in the front end when you build the site. Once you try wrangling dynamic features out of a static site, it defeats the purpose. As I’d rather eat my hands than use something like React to build a website, I think I’d go for a simple dynamic site generator, possibly Kirby (which just uses text files — no database) for anything apart from a simple blog.

    1. I disagree that I’d “be crazy not to use a host like Netlify and github/bitbucket integration (another thing to learn, of course, but worth it if you’re building any software anyway.).

      All of that “junk” has nothing to do with publising content. It’s like arguing that I need to learn about rack and pinion steering and be able to do my own oil changes to drive my car to work or to get to go see my family.

      I agree that Hugo is fast but 3000 visit a day doesn’t impact my wordpress blog — 15 years now — in the least bit. Hugo would give me a negligible increase in performance. So small that the trade offs are not worth the effort of all learning to be a plumber of the stuff you wrote above.

      I really get pissed off with technoratic idea that everythign needs to be as hard as possible because you know “learning.” It’s arrogant.

  3. I agree, even though I’m using Jekyll myself (with Netlify so I don’t have to copy things to a server every time) for my linkblog. I am no where close to even the 800 posts he’s got, let alone your 4000. I do think that if I get to that point I’ll just move to WP, coz it’s so much simpler to manage posts on there.

    On the other hand, my main frustration with WP (and Jekyll for that matter) is that 99% of my older posts will never change, so why display them dynamically? They should be built into HTML, cached, and forgotten.

    I do have heavy caching on one of my WP sites, but not for my personal blog. I wish WP had this static HTML functionality built into its core. That would be the perfect combo and the killer blog, frankly. What do you think about that? What do you use for older posts? Do you W3Cache them?

    1. On the other hand, my main frustration with WP (and Jekyll for that matter) is that 99% of my older posts will never change, so why display them dynamically? They should be built into HTML, cached, and forgotten.

      That’s the most logical “complaint” I’ve heard about WordPress. I wish it could do that as well. But … I know that I often go back and fix older post (spell and grammar check, image size too small, broken links, etc.).

      There are plugins that allow the operator to generate static pages from WordPress posts. WordPress then just becomes a front end to a static site generator. However, then you wouldn’t be able to leave a comment.

      I have tried Grav, a flat file CMS that produces static site content. It has a usable front-end web UI for creating and managing posts and images. If I remember correctly, post are saved as Markdown text with Front Matter; similar to Jekyll and Hugo.

      I used it in test mode for a bit but did not find an easy way to port my existing post and images. I spent a week correcting mistakes in the importer. After correcting about 50 posts, I gave up. Maybe I should have stuck with it.

      I would gladly use Jekyll if:

      • The site rebuild problem was solved without hacks
      • I could use a Web UI on my own server to create/edit/manage posts and images. Jekyll content creation isn’t mobile friendly.
      • There was an open source comment system I could easily integrate on my own server. I don’t trust Disqus.

      I don’t do any caching yet. I have am old Cloud Flare account that I may dust off to see what caching can provide.

      1. I don’t know the solution to the site rebuild issue. I’ll see if Netlify starts failing me at some point.

        As for the web UI – you’ve got one! Well, I’ve got one. Since I use Netlify linked with GitHub, all I have to do is edit the file in github. Now, I can do that using github’s interface, which isn’t jekyll friendly, or I can use, which has a beautiful interface and hides the metadata so you can focus on the text and can easily fix mistakes or add content to existing posts. (it even let’s you edit the metadata separately, which is a pretty complete editor!)

        What do I do for creating new content? Take a look at this file –

        It’s a hack from a guy named Vrypan that uses a JS library to talk to github.

        The interface looks like this –

        His initial blog post about it sits here –

        As you can see, it requires your github username and password, but it’s using SSL (and you can too, if you host using netlify), so it’s somewhat secure.

        His version takes post title, text and tags, while I’ve modified it to take link URL as well. The cms page is rather mobile friendly and I’ve used it in a situation or two.

        I don’t know about comment system. I’ve seen so many come and go, first with and then some in its aftermath. But if people don’t find any, they just replace those with a comment on twitter or m.b

        Cloudflare caching is nice and helpful, but in the case of WP, I’ve not seen them save me more than, say, 35% traffic at any time, by their own measure. But that’s better than nothing!

What do you want to say about this post?

This site uses Akismet to reduce spam. Learn how your comment data is processed.