How to speed up Netlify build, twice

… and check why 5600+ Rails engineers read also this

How to speed up Netlify build, twice

Netlify is a platform to build and deploy static sites (i.e. nanoc or jekyll). We use it extensively for many of our sites at Arkency, like this blog.

The platform acts both as a Continuous Deployment pipeline and a hosting for generated HTML files, with Content Delivery Network. That is a quite convenient combination of features.

The workflow to publish changes on a site starts from a push into a git repository. That triggers the build process for a given revision of the repository. That build process runs within a sort of stateless container. That is pretty typical model if you’ve ever had anything to do with a CI/CD in a cloud.

The container is stateless itself, but it needs some state in order to make build process quicker. That state is cache, which can be:

  • restored before starting such build process
  • saved when build process completes

Netlify is smart enough to figure out that our Nanoc or Jekyll sites have runtime dependencies:

  • Ruby gems as defined in Gemfile
  • npm packages as defined in package.json

Those dependencies are automatically cached in order to save us much time fetching them over and over again on each build. That is pretty typical too, when setting up CI/CD and it is great to have it working out of the box.

Netlify as a platform goes “wide”, to attract many developers and provide great initial experience for most of us (there’s far more “jamstacks” than just Nanoc or Jekyll).

In order to squeeze performance to the very last drop, you have to go “deep” instead. For example nanoc is very good at avoiding unnecessary recompilation and will only recompile an item if it is deemed to be outdated. For this to work, it maintains a set of files:

blog.arkency.com master [1] tree -L 2 tmp/nanoc/
tmp/nanoc/
└── df597f7007938
    ├── binary_content
    ├── binary_content_data
    ├── checksums
    ├── compiled_content
    ├── dependencies
    ├── outdatedness
    └── rule_memory

Netlify has no idea that these, along with generated output from previous builds, are crucial for nanoc to work its best.

Same goes with parceljs — a very pleasant-to-work-with asset bundler with blazing fast bundle rebuilds. In order to achieve it, this tool maintains its own cache in .cache directory of the project. Again, it is too niche and specific for Netlify to optimize for, they go “wide”.

Luckily Netlify left the door open for developers to augment their build process and let them go “deep”. This is done with build plugins.

Building such plugin is rather straightforward:

  • there is a starter repository, which acts as a template to fork with test suite and linter
  • the plugin is event-driven, you handle only the events relevant to you
  • plugin has access to site configuration, input parameters and some bits of environment
  • you’re able to interrupt the build, interact with cache, retrieve changes from git and finally run commands and processes

Pretty sweet balance of possibilities yet without an overly verbose API. Here’s an overview of build events:

hook description
onPreBuild runs before the build command is executed
onBuild runs directly after the build command is executed
onPostBuild runs after the build command completes, can be used to prevent a build from being deployed
onError runs when an error occurs in the build or deploy stage, failing the build
onSuccess runs when the deploy succeeds
onEnd runs after completion of the deploy stage, regardless of build error or success

It turned out that plugins to take the most of nanoc and parceljs were quite simplistic:

const NANOC_TMP = 'tmp/nanoc'

module.exports = {
  async onPreBuild({ constants, utils: { cache } }) {
    await cache.restore([constants.PUBLISH_DIR, NANOC_TMP])
  },
  async onPostBuild({ constants, utils: { cache } }) {
    await cache.save([constants.PUBLISH_DIR, NANOC_TMP])
  },
}
const PARCEL_CACHE = '.cache'

module.exports = {
  async onPreBuild({ utils: { cache } }) {
    await cache.restore(PARCEL_CACHE)
  },
  async onPostBuild({ utils: { cache } }) {
    await cache.save(PARCEL_CACHE)
  },
}

Don’t be mistaken — those several lines of code were quite powerful and have cut the build time in half.

If you’re on nanoc or parceljs, perhaps with a starter-kit for static sites that we use in arkency, check these out:

Now, a plug 🔌. This post is a part of #5days5blogposts challenge on ARKADEMY.DEV. In this challenge we encourage you to publish five blogposts in five subsequent days. We help you generate topics to write about, structure the content and review the final effect. You get the support from our community of teachers and learners on Discord.

Join ARKADEMY.DEV now to start your blogging journey!

You might also like