We are looking for volunteers you to test some branches of our latest optimizations experiments.
If you have a large jekyll website (1000+ pages) , help us ship Jekyll v3.8.0 by testing the latest version in your Gemfile:
gem 'jekyll", "3.8.0.pre.rc2"
To get an average build time, you can run a few builds with a simple script like:
#! /bin/bash
set -ex
bundle exec jekyll clean
for i in {1..5}
do
bundle exec jekyll build
sleep 2
done
Thank you for posting the benchmark data for your site @mmistakes!
I had no idea Jekyll would take ~130s to build a site with 1006 posts and 52 documents on a macOSā¦!!
(I dread to wonder how long it wouldāve taken on a Windows platformā¦ )
Couple of questions:
Are these regular build times or build times with the --verbose switch ( or verbose: true)? (--verbose switch or verbose: true in v3.8.0 adds absolute_paths to be written to the disk as wellā¦ so thatāll add a few seconds to the overall build time as wellā¦)
How large are your static filesā¦? Thatās one area where there hasnāt been much of an optimizing because its fairly just copy-paste-to-dest-verbatim
Iām not using the --verbose switch or verbose: true, just vanilla bundle exec jekyll build. The build times on Windows are pretty close to macOSā¦ 10-20 seconds slower.
A big part of these ~140s times is due to the Jekyll Paginate v2 plugin. It spends about 70s generating 118 tag archive pages that are all paginated. Disabling it cuts the build time in half.
Iāve also done quite a bit of testing/experimenting to lower my build times.These numbers are from awhile ago but most of it is still valid. Yes I have a fairly large amount of static image files (~1GB). As you mentioned above itās IO intensive for Jekyll to move these from the source to _site.
What I ended up doing was reducing Jekyll to ājust creating HTMLā files. Everything else I use Gulp to do, which is much faster at. My build process goes something like this now
Gulp builds CSS, JS assets, puts them in a temp folder that Jekyll canāt see. This has the benefit of being able to edit them without triggering a build when developing locally.
Gulp copies only the files needed to build the actual HTML to a temp folder (_layouts, _includes, .md documents, etc.)
Jekyll builds this temp folder in HTML.
Gulp moves the built HTML to dist folder where production CSS/JS and images are.
I go into this with greater detail on my site if itās of interest:
Thanks for the informative response.
So, the crux of the performance sink lies within a 3rd-party plugin which somehow got worse with my attempts at optimizing Jekyll.
Guess, Iāll have to dig into Jekyllās master and see what is adding those extra 20secs (in comparison to v3.7.3)
Are you able to discern the difference (as to which file(s)) in the --profile outputā¦?
So I ran a build with 3.7.3 and master using --profile and hereās what I got. Biggest change I notice is the post.html layout took longer with master.
The other strange thing is jekyll-paginate-v2 paginates 118 tag pages with 3.7.3, but the master branch version of Jekyll has it doing 120. I wonder if something there is adding the extra time as it seems to be creating more pages.
its more than just the pagination pluginā¦ If you look at the time used by _includes/related.html, youāll see that it has increased by ~12s (meaning jekyll:master probably sees more related posts, /cc @parkr )
But yes, _layouts/autopage_tags.html with jekyll:master has been used 348 times in comparison to 346 times with jekyll-3.7.3, which is probably related to https://github.com/jekyll/jekyll/commit/f8a66ca76c1dcc0ce79aed2655f5660527aa7d60 because of which two documents ignored earlier are now available, and the remaining increased build time is probably related to these two documents.
Also Iām using this ārelated postsā pluginā¦
This is an interesting developmentā¦
The following PR added related_posts to the SiteDrop so that a documentās ārelated-postsā are calculated only if and when its asked for in the Liquid Templates. (Thatās how Liquid::Drop and its subclasses, of which is SiteDrop, worksā¦)
While the above PR also memoized the built-in method (the use of @related_posts ||=ā¦), making it more efficient by having to run just once for a given document irrespective of how many times the method is calledā¦, the pluginās method run the full code for each call to the method.
So, @toshimaru will now have to memoize his method definition for the pluginās users to efficiently use Jekyll 3.8.0
You can get the ball rolling on this by opening an issue ticket at the pluginās repo informing the author about the developments upstream.
Thanks to the people that took the time to share their build times.
3.8.0 has been published but feel free to continue to share benkmarks, especially if you have a very large website, and if your repo is public, share it, as we might use it for our tests.
For those who want to follow closely with the latest addition on the performance front, we suggest you to subscribe to opened PRs with optimization label.
Weāre still working on improving Jekyllās performance.
For people who suffer from slow builds, weād be interested in testing:
refactor your includes with jekyll-include-cache when possible
use liquid-c gem to speed up Liquid parsing
use jekyll-commonmark to speed up Markdown rendering
test current jekyll master (make sure to exclude .jekyll-cache folder from Git)
Your Gemfile should therefore contain:
gem "jekyll", github: "jekyll/jekyll"
gem "liquid-c"
group :jekyll_plugins do
gem "jekyll-include-cache"
gem "jekyll-commonmark"
end
Then publish you site on a Netlify branch or any CI where you can use these gems (you canāt on GitHub Pages) and share the result.
I advised those to a friend of mine and its build went from 931s to 59s. The build outuput is exactly the same.
I tested on Kong Documentation and build shrinked from 54s to 8.3s. Didnāt test the output.
This might conflict with existing plugins, if you encounter errors, weāre interested to know which plugins would benefit a fix to use our new cache API.
Hereās some documentation on what has already changed for plugins authors:
Hi! This might be too late to share, but I have tried Jekyll 4.0.0 (pre.alpha1) to improve building time by following this article: Forestry.io CMS | Tina
And the result is 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 works! Iām looking forward to seeing Jekyll 4.0.0 released. <3 <3 <3
Jekyll community,
)
<3 <3 <3