As my Jekyll site has been growing exponentially, it’s become increasing difficult for me to work on it due to the long build time - even with incremental: true (I have several thousand pages in my _pages directory now, and often need to work on layouts related to these pages).
What I’m looking for is way for my dev environment to only use a small subset of the pages that I have in production. Is there a way I can point my dev environment to a _pages-dev folder for example ?
Hello @splotsh,
I’m one of the core team that maintains Jekyll, and am sorry that your dev workflow has been impacted by long build times.
Is your site’s source code public? If yes, I’d like to play around with it and see I can detect bottlenecks that could be fixed at our end.
(Disclaimer: Jekyll delegates majority of the workload to third-party dependencies: Liquid and kramdown. So Jekyll can only be truly sped up if those dependencies get sped up…)
I’m definitely not using Jekyll in the standard way - so no apologies necessary
The code is unfortunately not public, but I’ve just shared it with you on Github so you can take a look.
The issue just really boils down to me having several thousand pages in my _pages directory. By changing the source location at run-time I would pretty much need to duplicate the site into a second directory (with a limited set of pages), which would make development difficult when making changes to core layout files etc… if I understand correctly how --source works.
Just found the --config option - I’m specifying both a prod and a dev config file when launching Jekyll, where the dev config overwrites the include path of my _pages directory to one that only has a small subset of my pages.
Thank you for the access to your repository.
From what I see, the major reason for slow builds is the following code in one of the layouts:
{% assign results = false %}
{% for ... %}
{% if ... %}
{% if ... or ... %}
{% if ... or ... %}
{% assign results = true %}
...
{% if ... %}
{% include ... %}
{% endif %}
...
{% endif %}
{% endif %}
{% endif %}
{% endfor %}
Nested Liquid constructs such as above is a guaranteed perf drain.
Moreover accessing front matter data values inside such constructs further compounds the perf drain.
Optimizing the above code chunk will improve the build times for your dev builds.