Speed up jekyll - use gulp for sass/assets

Share
1

I wrote a blog post about using gulp to process all sass files as well as JS and images - removing them from the Jekyll work load at the same time as not needing to have Jekyll rebuild the site whenever a sass file or js file or image is edited.

Gulp will compile sass files instantly more or less, so using live reload, saving a change to a sass file almost instantly refreshes the browser.

By using gulp for all of those assets has cut my build time for Jekyll down to half a second from about 6 seconds - and that is if jekyll even has to run - any sass, js or image changes don’t need jekyll at all. Course that site is pretty small, only about 50 pages.

I’ve only just finished working this out, may still be some problems with it, and I am not at all a Gulp expert so any suggestions are welcome. So far it seems to be working really well, but I have not done much with images or js. When something changes in the images folder my console scrolls a zillion blank lines between the start and finished messages for some reason, seems to work ok though.

https://rdyar.github.io/2017/10/01/speed-up-jekyll-by-using-gulp-for-sass-and-other-assets/

3 Likes
2

I’ve came to the same conclusions and wrote about it recently as well.

My site is pretty big so building thousands of posts, categories, and pagination, still takes a few minutes. But the asset compilation bit is way more speedy after letting Gulp take care of it.

3 Likes
3

huh - I was just on your site while I was struggling with gulp and didn’t see that - I just went straight to your repo to see what you were doing with gulp and didn’t notice that article.

From your article:

Decoupling the asset pipeline from Jekyll and Gulp-ifying it made the biggest splash in terms of build time.
 Along with Browsersync, any asset (CSS, JavaScript, images and icons) updates could be previewed 
almost instantly. Greatly speeding up the time it takes to develop and iterate the site’s front-end.

I really think this is worth while information for anyone actively working on their site locally, though I think it eliminates using GH pages other than pushing the site folder (same with my gulp usage).

4

This was from browsersync, I set its logging to silent and it stopped doing this - I didn’t find its other info message particularly important anyways.

5

With continous integration services this isn’t that big of a issue anymore.

You can use something like Travis CI that will fire off your Gulp tasks when you push a commit to your GitHub repo. Then use one of their many deployment scripts (of which GitHub Pages is an option) to send the files wherever you need.

1 Like