The only universal answer to this is: it varies. More detail would probably be helpful, right? Below we explain which factors affect the lengths of builds on Netlify
One key factor is the site itself. Larger sites will take longer to build than smaller ones, and things like images and video can impact this (if those assets need to be downloaded or processed during build).
Another factor is the static site generator (SSG) being used (if any). The performance of SSGs varies widely. If the site takes a long time to build locally, that will also carry over to Netlify.
Also, the systems which handle the site builds are a shared resource (amongst Netlify users). When the network is under heavy load, newly scheduled builds will be queued instead of beginning immediately. (Pro tip: Monday through Friday - US and EU business hours - are normally the busiest times.)
When the load is high on the build system, and when utilizing our our Starter or Pro team plans, it is normal for builds to queue for up to fifteen (15) minutes. Again, this is for our starter and Pro tiers only.
Also when the load is high, it is possible that your build will be competing for scarce CPU/memory resources. Your build is guaranteed only 1CPU and 3Gb of memory, though it may get more when the system is less busy. This is probably far less than you build with locally, so times will not likely match your local unless you use a very efficient SSG like hugo.
If these longer build times are causing issues, one possible solution is to upgrade to our paid Enterprise tier. The custom plans use a prioritized build network or hardware dedicated to your account, and this generally leads to less build queueing and faster builds. Depending on your contract, this potentially unlocks two advanced build configurations:
- the ability to customize resource allocation so that if you want to run a 20Gbyte build with 6 CPU’s, you can! This can be available on a normal enterprise contract
- we additionally have a high performance build network that can give you up to 36Gb/10 CPU’s.
There is more information about other plans here.
Finally, what happens in the situation where many git push actions occur in a short time window while there is queuing in the build network? (And it’s a good question!)
Answer: each push will trigger a deploy with Netlify but only the first and last actually build & deploy.
Here is a more detailed explanation. Let’s imagine you run a
git push five times in a few minutes. Let’s also pretend your build takes 10 minutes to complete, so the last 4 deploys are queued.
So, what happens? Well, all five pushes will create deploys in your deploy listings page in the Netlify admin UI, and all will show as ‘building’ in the UI. But when the first deploy completes, the intermediate builds will all change to the status ‘skipped’ and then Netlify will build the last (most recent) deploy. We don’t waste our time or yours publishing builds that will be overwritten immediately.
Three more considerations around time to deploy, rather than just build:
- once built, we must UPLOAD any changed files! The more you change, the longer it takes to upload. This article talks in detail about reducing the number of unintentional changes in your builds
- once built, we must PROCESS any changed files! You can adjust what we optimize in your
Asset Optimizationsettings on your Deploy settings tab of our admin UI for a site.
- Finally, this article runs through all the potential optimizations you could make around what you build, when you build, and how you build it.
Regardles, if you notice unusually long queuing times for builds (for example, deployments taking longer than 30 minutes), something might be wrong! Please let us know in the comments below.