Shorten page generation time for local jekyll server

Question

When running jekyll --server, the entire site is rebuilt. On a large enough site, this takes an exceedingly long time. Even with the --auto flag, which should prevent whole-site regeneration, the time to completion is rather lengthy (10+ seconds for me, reportedly in the minutes for some). This is inconvenient when editing and previewing a single page. I'm looking to cut that time down.

Is there a means of determining why Jekyll takes as long as it does to rebuild a page?

Alternatively, are there recommendations for editing workflow which allow for a short(er) feedback loop with Jekyll?

Answer 1

I can't solve the time it takes for a full site build, but I've come up with a way to dramatically speed up drafting documents and making layout changes. All of this assumes you work on a local machine for editing and then deploy to a production server. Your mileage may vary if you have a different process.

The core idea is to use multiple jekyll source directories that each point to the same output location. In my case, I use three. One for drafting and editing posts (called '_drafts'), one for layout, design and functionality changes (called '_dev') and the final one that contains the contents of the full site (called '_main').

The top level directory structure looks like this:

./_drafts
./_dev
./_main
./html

The _config.yml file for each jekyll source is setup with the follow to point the jekyll generated output to the 'html' directory:

destination: ../html

The '_drafts' and '_dev' directories contain the minimum number of files necessary to make them mimic the design and functionality of the '_main' site. I do all my work in those two directories with jekyll running in whichever is being worked on. My local web server is setup to point a local domain (e.g. http://jekyll-test/) to the 'html' directory so I can see what's going on while I'm making changes.

When I'm finished editing, I copy the newly updated files from '_dev' or '_drafts' to their corresponding location in '_main'. Once the files are in place, I do one final jekyll run in '_main'. With this approach, you only have to wait through the long site generation time once before deploying the site to production. I've been using this approach for some time and find it makes a huge difference.

There are some other ways to optimize the workflow:

• Use symbolic links to help keep the design and functionality of '_drafts' and '_main' in sync.

  If you are on a Mac or linux machine, setup symbolic links to point ./_drafts/_config.yml to ./main/_config.yml and ./_drafts/_layouts to ./main/_layouts (Similar functionality probably exist on Windows, but I can't speak to it). For some reason, jekyll won't work well with some directories symbolically linked. For example, on my install, I have a root level 'css' directory that doesn't work as a sym link. I have to have an actual copy of it in all locations.

• Create a deployment script.

  When I'm ready to deploy, I don't run jekyll directly. I've written a little script the calls jekyll in the '_main' directory, rsyncs the output to my production server and then notifies me when it's complete. Not only does this save having to wait on jekyll, it reduces the number of steps required to deploy the site.

• Build additional scripts and tools.

  Copying the files from the '_dev' and '_drafts' directory isn't a big deal, but it's a prime place to add some automation. For example, I have a command line script that copies the '_config.yml' file and the '_layouts' and 'css' directories from '_dev' to both '_drafts' and '_main' (as necessary).

  Another tool on the docket is a local web app that will move posts from '_drafts' into '_main'. Anything that makes the movement of files easier and reduces the friction of creating and publishing is good.

• Use LiveReload

  Running locally, jekyll --auto is great for automatically generating your changes while working on files. The natural companion to this is an app called LiveReload. It watches your local 'html' directory and triggers an automatic reload of your browser when the contents change. The net of this is that you can keep your browser window beside your text editor and see changes happen automatically when you save a file. It's a little flaky from time to time, but after using it, you won't know how you lived without it.

Answer 2

This is a recurrent subject in Jekyll's issue tracker on Github. Unfortunately, it isn't one of the objectives. For example:

• Make jekyll --auto specific
• generate a site with about 60K posts, take forever

Just search for the words "compile" and "time" and you'll be able to find more. It's a bit harder than it looks because there's the possibility of broken links.

Also, if you're using LSI, use the latest version, because there was a fix related to it that makes it much faster.

My only advice to you is to see if you really need all these posts (I know, I know), because it's probably the only answer you'd get from the issue tracker right now -- something that we all want to address, but no one wants to start.

P.S.: Please post your problem on the issue tracker -- with more people complaining, it's much more possible for it to get fixed.