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.
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.
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: - .jekyll-cache
If you don’t, jekyll become to build non-stop.
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.
you’re right @lpuerto for now
.jekyll-cache has to be excluded, especially if you use the
Thanks for your feedback Colin, on average websites like yours running
livereload options locally should offer a decent development experience.
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
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
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.
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”.
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?
We’re currently updating core plugins to allow for Jekyll v4 pre release.
Great to hear!!!
How thinks are going with the plugins update?
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.
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.
Again, thanks for your great article! <3 <3 <3