Jekyll 4 is here! It's been a long time coming but the wait was worth it. Let's get down to the details.
Build speed has always been a major pain point for Jekyll developers. We've seen large websites on CloudCannon take minutes to build. Slow builds are painful to work on as you have to wait every time you make a change.
Jekyll 4 makes huge strides in speeding up builds. It's fantastic to see Jekyll make this a priority, a trend we hope continues into the future!
You can't improve what you can't measure.
In the past, Jekyll had no way of knowing the performance impact of new features and changes. We felt the first step to making Jekyll builds faster was to build a performance testing suite to see the performance impact of Pull Requests.
We sponsored Pat Hawks on the Jekyll Core team to work on this idea. A few months later, Pat launched Utterson, a tool which compares the build time of a suite of sites between different versions of Jekyll (or even specific PRs/commits).
Utterson has been a huge help in identifying performance issues and testing the performance of fixes. We hope Utterson continues to help improve Jekyll performance into the future.
While working with Pat, we identified parts of the Jekyll build which could be saved between builds. Processing Liquid templates and converting Markdown files don't change between builds (unless underlying code has changed), so they're a perfect candidate for caching.
Pat created the Cache API so Jekyll and Jekyll Plugins can cache data between builds. Caching Liquid templates and converted Markdown files resulted in a 20%-30% performance increase in testing. Since adding this feature, Ashwin Maroli has cached other parts of the Jekyll build resulting in more performance gains.
Jekyll plugins have been left to their own devices for caching. We're looking forward to seeing plugins use the cache API so they're not reinventing the wheel.
Memoization is a form of caching where you save the return value of a function for future calls to that function. Ashwin has been on a storm finding areas all over Jekyll which can take advantage of this caching strategy.
The team at Shopify released Liquid 4 at the end of 2016 which introduced performance increases and bug fixes in Liquid processing. Unfortunately for Jekyll users this didn't make it to the liquid-c gem (the Liquid gem Jekyll uses) until the end of 2018. Long story short, this new version should bring a 10% increase in Liquid processing.
The easiest way to increase your build performance is to make sure you're using the latest version of Ruby. The Jekyll team has dropped support for Ruby 2.3 and below in Jekyll 4 which will force developers to use a faster version of Ruby.
Sass processing has moved from the sass gem to sassc. sassc is maintained by the Sass team so we should see better support here in the long run. It also claims to be 4000% faster than sass so faster builds too!
Jekyll 4 is mostly about build performance but there are a few new goodies to get your hands on:
render_with_liquid: false in the front matterand and or operations with where_explink tag understands Liquid variableslink and post_url tags no longer need site.baseurl prepended every time they’re usedJekyll 4 is a massive improvement over previous versions. We want to thank all the hard work Ashwin, Frank, Matt and Pat on the core team have put in to get Jekyll 4 released. We’re big fans of the build performance focus and are excited to see what comes next.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。