How I reduced my Jekyll build time by 61%

Share
1

I recently benchmarked Jekyll’s master branch and managed to lower my build time by more than 60%. I also wrote a detailed step by step post covering all the changes I made.

You can read the full post on the Forestry.io blog

3 Likes
2

This is really great! I was able to reduce 50% the building time. Change to commonmark is not possible for me right now, but I implemented all the rest recommendations and so far so good.

Thanks a lot.

1 Like
3

by the way… you mention in the post that you have to add .jekyll-cache to the .gitignore file. I think that .jekyll-cache should be added to the _config.yml file in the exclude: part:

exclude:
  - .jekyll-cache

If you don’t, jekyll become to build non-stop. :joy:

1 Like
4

You’re welcome. I’m glad it was helpful.

Yes CommonMark takes a bit of work. I had cluttered my posts with css classes. The solution was to style these elements directly from the stylesheet. You may also need to enable UNSAFE option.

1 Like
6

you’re right @lpuerto for now .jekyll-cache has to be excluded, especially if you use the --livereload option!

2 Likes
7

Thanks for your feedback Colin, on average websites like yours running incremental and livereload options locally should offer a decent development experience.

1 Like
8

54
Screenshot 2019-02-07 at 21.59.54.png1476×666 136 KB

Thanks for letting me know @lpuerto. I just had some time to test this out myself and I can see the issue you mentioned.

@Frank Yes, it is a massive improvement. Looking forward to V4 :star_struck:

9

By the way, Jekyll new Cache API can have an impact on existing plugins, especially those who memoize values.

If you use jekyll-seo-tag for instance, you’ll have to use the no-cache-drop branch or your page metadata will not be properly displayed.

Same goes for other core plugins like jekyll-feed or jekyll-github-metadata

Here’s my current Gemfile for the core plugins:

  gem "jekyll-seo-tag", github: "jekyll/jekyll-seo-tag", branch: "jekyll-cache"
  gem "jekyll-feed", github: "jekyll/jekyll-feed", branch: "jekyll-cache"
  gem "jekyll-github-metadata", github: "jekyll/github-metadata", branch: "no-cache-drop"

v4 might break other existing plugins. We encourage plugin developers to test their plugins with lastest master or wait for next beta release to do so.

It should be clearly emphasized that this is still beta software, the core team aims at a Jekyll v4.0.0.alpha1 release before March 31th, when support for Ruby 2.3 goes EOL.

2 Likes
10

Note:
In case there are adventurous developers using Jekyll’s master branch (mainly changes for v4.0) to use the “Cache API”, do note that, the “Cache API” refers to the use of Jekyll::Cache class and its public methods. It does not break plugins that use memoized methods.

That above behavior is due to an unrelated change which memoizes the method that parses Liquid Templates and therefore requires the resulting Liquid::Template object to receive an “un-memoized Drop data”.

2 Likes
11

I got this today:

Bundler could not find compatible versions for gem "jekyll":
  In Gemfile:
    jekyll

    jekyll-seo-tag was resolved to 2.5.0, which depends on
      jekyll (~> 3.3)

Could not find gem 'jekyll (~> 3.3)', which is required by gem 'jekyll-seo-tag', in any of the relevant sources:
  git://github.com/jekyll/jekyll.git (at master@6905c80)

Any idea how to fix it?

12

We’re currently updating core plugins to allow for Jekyll v4 pre release.

1 Like
13

Great to hear!!! :slight_smile:

14

How thinks are going with the plugins update?

15

I saw the quote

If you have a computationally expensive include (such as a sidebar or navigation), Jekyll Include Cache renders the include once, and then reuses the output any time that includes is called with the same arguments, potentially speeding up your site’s build significantly.

I would assume that nav bars (and footers) which are included from static HTML files would not be that expensive computationally?
We have a very specific look and feel / interaction on our website that I would battle to implement using Jekyll, so have stuck with what I had prior to implementing Jekyll.

Also I have front matter in the pages that drives a lot of SEO and page processing (especially in our eStore), so caching the includes probably wouldn’t work for us.

16

Hi! Thanks to the article, I have reduced building time from 7.574 to 2.148 seconds!

The details are as follows:

  • Before this PR: 7.574 seconds
  • w/ Cache API: 3.649 seconds
  • w/ liquid-c gem: 2.581 seconds
  • w/ CommonMark: 2.152 seconds <- Skipped this due to breaking many pages in my case.
  • w/ include-cache: 2.148 seconds

See this PR for more details if interested. :wink:

Again, thanks for your great article! <3 <3 <3

3 Likes