Understanding how build time really affects Jekyll workflow

Help
1

I am building a complex personal website/blog. I was working with Hugo and I am thinking to switch to Jekyll because it is much simpler. A lot of people complains about Jekyll built time. I am trying to understand how this really affect workflow. Does the slow build only happen when you are actually building a server-ready site? Or does it happen every time you save something while working on the site? (i.e. when you edit markdown or css or HTML etc.)

Any pointers how I can understand constraint of build time in Jekyll will be much appreciated.

2 Likes
2

In my experience Jekyll build times depending on the following:

  1. How optimized your layouts and includes are.
  2. Number of documents/posts/pages etc. you’re converting into HTML.
  3. If you’re using Jekyll’s built-in support for Sass or a plugin like Jekyll Assets to handle it.
  4. If you have a large amount of static files (e.g. images).
  5. Plugins.

No. 1: If you make use of Liquid’s {% for %} tag to loop over site.posts you’re build times will take a hit. You generally see this being used for related post modules or tag clouds on each post. This sort of thing can add up as it has to loop through every post, and if you have hundreds or thousands of .md files you’re going to see build times hit minutes instead of seconds.

No. 2: Generally small sites using a basic layout without anything fancy can build pretty quick… not instant like Hugo, but in a few seconds which isn’t awful.

When you get over a thousand posts/documents build times are going to slow down and could be a few minutes or longer. As an example my personal site has just over 1,000 posts, has paginated category/tag archive pages, related posts on each post page, etc. and takes about 6-8 minutes to build.

No . 3: Using Jekyll’s built-in Sass preprocessing isn’t slow per say, but any changes made to Sass files will trigger a full rebuild of your site when developing locally. So if your site takes on average 20s to build, that’s how long each Sass change will take. Which can be a real bummer for rapidly iterating on a design.

What you can do is decouple asset building and use something like Gulp or Grunt to do that for you, then pipe it in instantly with Browsersync. This doesn’t force Jekyll to rebuild the site and is a nice separation of concerns if you’re into using multiple tools to do the job.

No. 4: Having a lot of static files like images in your Jekyll source folder can bog things down too. Every build Jekyll has to copy these files, which can be I/O constraining depending on how quickly your device can move files around.

In my case I have just under a gigabyte of images, which definitely slowed things down moving files around. This was another thing I decoupled from Jekyll and move around myself using Gulp.

No. 5: Depending on what plugins you decide to use (if any) can have a negative impact on builds. Plugins that generate pagination, feeds, responsively sized images, etc. are all going to add to the build time. The leaner your setup the quicker your builds.

There are other things you can do if you’re curious… shameless promotion of my blog post on the subject.

6 Likes
3

Thanks for this comprehensive answer! Do I understand it correctly? Whenever I save thing like CSS it is not gonna rebuild my whole site. But if I touch one letter in a .md file or change anything in an html file it is gonna trigger a full rebuild?

4

It’ll rebuild if you touch any file, CSS, Markdown, YML data file, whatever. Unless you decouple asset building it will rebuild every time.

There is incremental building which can help, but I haven’t had much luck with it and it caused some issues with what it cached between builds. Your mileage may vary.

1 Like
5

ditto - use jekyll to just process the layouts/includes/markdown/html files and use gulp for everything else.
This makes something like css changes just as fast as hugo. Once you off load all the sass/images/js then jekyll’s core job is also way quicker.

Plus a good chunk of time can be spent on sass/js/images and all that goes lightning fast. So trying to build a css framework for a page/site can be painful with just jekyll, but decouple it and it is much better.

My sites are really small so for me it is just a matter of a few seconds here or there, but 2 seconds vs 6 seconds is still a nice improvement.

Shameless plug for blog post on the subject - written just about the same time as MM’s - which was funny cause I found his post right after I made my post but we both said basically the same exact thing. If in doubt follow what MM says as he actually knows what he is doing.

https://rdyar.github.io/2017/10/01/speed-up-jekyll-by-using-gulp-for-sass-and-other-assets/

2 Likes
6

In sync with the answers already posted, the one thing that can increase build times is abusing Liquid. Liquid wasn’t meant to do complex computing but its design is flexible enough to support it.
The increase in build times is primarily due to increased memory consumption from a badly written Liquid template.

For example consider the following snippet (contrived example) to generate breadcrumbs for a page:

{% assign url_parts = page.url | split: '/' %}
<ul>
{% for entry in url_parts %}
  <li>
    {% unless forloop.last %}
      {% include breadcrumb--anchor.html label = entry %}
      /
      {% else %}
      <li>{{ entry | upcase }}</li>
    {% endunless %}
  </li>
{% endfor %}
</ul>

{% for .. in .. %} is known to be slow because (it has to keep track of the current scope). But what slows it down further is:

  • nesting another {% for .. %}
    For example, the above snippet could be wired to render breadcrumbs for all pages in the current site, via {% for page in site.pages %})
  • or just using a {% include .. %} or another computation-heavy Liquid tag within the loop.