If you are interested in learning more about how our bots approach building sites, these three articles are a great place to start:
- How our Build Bots build sites
- The last major upgrade to our build environment
- and perhaps least-loved but most useful, how to debug your builds
So you might think, it’s great that Netlify builds every commit from my repos…but isn’t that a bit wasteful? The answer is, it depends, but we can at least give you some best practices for limiting waste. Maybe you’ll save a tree this month!
This article is in 3 parts: Optimizing what you build, Optimizing how you build, and Optimizing your site changes. Each offers opportunities to reduce build times or eliminate unnecessary builds.
Optimizing what you build
Netlify will happily build as many branches from your repository as you like - including known-broken branches, or branches that you don’t intend to browse or care if we build. So, our #1 recommendation to cut down on Build Minutes used is to check your configuration:
- Near the top of the Build & Deploy settings page for each site, you’ll see a card titled Deploy Contexts. In it you can choose which branches we build, and whether we build PR’s, or just commits. Consider switching off deploy previews for some branches if you do not follow a one-branch-per-feature model. There’s no wrong way to do build branches but we do suggest you consider the settings.
- You can tell us to skip any build by including the characters
[skip ci]in your commit message.
- If you run local tests, complete your testing before committing. No need for us to rediscover what your unit tests or Jenkins server already knows and waste some CPU while doing it!
- If you know exactly when you want to build and are willing to trigger it yourself through our UI or via an incoming webhook, our Support team can enable a flag for your site(s) to skip all automatic builds from git, and use only the ones from your own custom webhooks which will still pull your code from git and perform a normal build.
- If you deploy manually using the CLI and have no intention of having us build, let us help you switch off continuous integration. It’s not possible to unlink by yourself, from our UI but once again you can comment in this thread with some site ID’s you’d like this configuration applied to. You can find your site ID on the General Settings page for the site.
- Be careful with your webhook configuration. Some folks have Contentful set up to save with every keystroke, and trigger a build too. Don’t do that :). Try to prevent unnecessary builds triggered via incoming webhook from services like your CMS or CI by configuring their auto-save or auto-commit features appropriately.
Optimizing how you build
There are as many tips and tricks for this as there are ways of building Netlify sites, but here are a few:
Let us cache your dependencies. We automatically try to cache your gems and npm/yarn modules. We generally don’t reinstall them all unless you use the “clear build cache” checkbox in our UI when triggering a build. Note that any change to your
Gemfile.lockwill result in us re-running the installation during next build, but it should still take advantange of the cache to some degree.
Watch your dependencies. There are some packages that take a long time to install - cypress is a good example. If you don’t need some dependencies on Netlify, consider setting your
$NODE_ENVenvironment variable to
productionand making them
- Not all build tools are created equal. Hugo is faster than most other build tools, for example. This isn’t to say you should port your site to a different static site generator, but if you are planning a large site and have not yet chosen a generator, consider build time as a factor.
- Configure your tools appropriately. Some SSGs use plugins that use a lot of memory and run slowly - they can even cause builds to fail with a timeout. This article, for example, has more details on some best practices for Gatsby + Netlify.
Optimizing your site changes
No matter how fast your build goes, we still have to store your files after build. If your build process changes many files with every deploy, every one of those files must be stored. If it instead changes only a single file, there is only one file to save, and one is always faster to save than many.
Look to optimize your build process so that it doesn’t change many unrelated files (or filenames) with each build. Changing fewer files with each build also allows your repeat visitors to browse your site faster, since they can leverage browser caching.
This article talks about the situation in depth, with some suggestions around how to avoid it.
Do you have other tips and tricks about how you’ve sped up your build? Share them with us below!