[Support Guide] Build Performance Pro-tips

Support Support Guides
, , ,
1

Last Reviewed By Netlify Support Staff: May 2023

You’ve gotten your site to build, perhaps via our Support Guide on debugging site builds. Congrats! What’s next?

Now is a great time to make your build FASTER! While there is no “one size fits all” for how long your build should take, less is more here. The faster you can deploy a site, the faster you can work on the next version. This guide will review some best practices and offer some guidance on speeding up your builds.There are three high level pieces of advice that you should start off with:

  1. Make sure your build doesn’t use too much memory or run using parallel workers, as this will likely cause your build to fail. This article describes what is allocated to your build, so you can fit within it. Note that we do have a higher performance build option with over 10x the memory and 8 CPU’s, in case your site is really big - this page has some more details and a form to contact our sales team for a demo.

  2. Adjust the time it takes us to upload your assets. How you build your site can have real implications on how long it takes to upload after building- and it can’t be published on the web until the uploads are finished. If you see a long time spent between Post processing - HTML and Site is live in your build logs then this article outlining how our CDN cache works is relevant to you. Adjusting this will have a bigger impact on larger site builds rather than smaller sites. Also, if you don’t use our form handling service on an older site (created before late April 2023), you should turn off form processing in the Form Settings section of our UI, as that will speed up your upload! In case you have a newer site, we should disable this setting automatically, by default as announced here: Forms detection now off by default - and you have to turn it on if you later implement a form, so we detect it and accept and store its submissions.

Screenshot_5_5_23__13_25

  1. Control what we cache! We attempt to cache your dependencies after building them, so we don’t need to rebuild your node_modules directory or your Ruby gems over and over again. (We’ll still update or rebuild your dependencies if you change your config file like Gemfile.lock or package-lock.json!) However, this only works perfectly for builds using a fairly straightforward repo layout with only one dependency file - if you have to use a build command like cd directory && npm i && <do the rest of your build> - it is very likely our dependency caching will not work well for you by default and we’d be happy to try to advise you in better practices so we can improve dependency caching and thus increase build speeds.

    If you visit your build plugins page and search for cache you can see that there are many ways to manipulate cache handling. In particular, we see folks have a lot of success with the general build cache debugging plugin and with gatsby cache persisting. To manipulate the cache to your precise specifications, the best npm package is cache-me-outside - npm. Please note that this is not a build plugin though, so you use this in package.json or yarn.lock!

A few more things to consider as part of your build performance:

  1. Do you need to build every commit? This article talks about many methods to reduce your number of builds: [Support Guide] How can I optimize my Netlify build time? including limiting builds to specific branches, limiting which builds start at all (versus one for every commit), and how to use our ignore script to prematurely end a build that you don’t want so you can unblock the next build that does matter!

  2. Do you refetch some asset(s) with each build that could be stored somewhere instead - in git, or in our build cache? While API calls work well from the build container - the containers are well connected to the internet - nonetheless, refetching unchanged assets instead of caching them will slow down your build.

  3. Could your builds be different per context? With deploy contexts you can choose to for instance run tests only on PR’s (or builds targeting production), or choose to short circuit sourcemap generation during builds on feature branches, by providing different commands per context as demonstrated in this article: [Support Guide] Conditional build/deploy behavior for context / branch on Netlify

Those are some reasonable starting points to self-serve on optimizing your build performance - but of course this is “one size fits many”, not universally applicable, so share your performance optimizations below to inspire your fellow Netlifans :slight_smile: