Shaving Off 33% of Build Times on GitHub Workflow

Every Second Counts

Switching from ‘npm’ to ‘pnpm’ in the GitHub workflow reduced build time, enhancing productivity and efficiency by a third. It’s significant with implementation with headless git-based CMS.

The Original Workflow

The original workflow, found here, was based on the ‘npm’ package manager. The total runtime for this workflow was approximately 80 seconds, with the dependency installation process taking up about 45 seconds.

The New Workflow

The new workflow, available here, has switched to the ‘pnpm’ package manager. This change has significantly reduced the total runtime and the time taken for dependency installation. The total runtime is around 50 seconds, while the dependency installation process takes just 10 seconds.

Both workflows utilize caching, which helps to speed up the build process by storing and reusing specific data instead of recreating it each time.

The Impact of the Change

The switch from ‘npm’ to ‘pnpm’ has resulted in around a 30-second reduction in build time for each deployment. This might seem like a little, but the time savings can quickly add up when you consider the frequency of deployments in a typical development cycle.

Moreover, the reduction in time taken for dependency installation — from 45 seconds to just 10 — means that developers can iterate faster, making changes and seeing their effects more quickly. This can lead to a more efficient development process and a better end product.

To better illustrate the changes, here’s a comparative table of the steps in the old (npm) and new (pnpm) workflows. Data are from run with the cache, demonstrating the same impact and savings.

┌──────────────────────────┬──────────────┬──────────────┐
│ Step                     │ Old Workflow │ New Workflow │
╞══════════════════════════╪══════════════╪══════════════╡
│ Set up job               │           2s │          3s  │
│ Checkout                 │           1s │          1s  │
│ Setup PNPM               │            - │          1s  │
│ Setup Node.js            │            - │          4s  │
│ Cache dependencies       │           0s │          0s  │
│ Install dependencies     │          47s │          8s  │
│ Build project            │          10s │          8s  │
│ Inspect build output     │            - │          0s  │
│ Setup Pages              │            - │          0s  │
│ Upload artifact          │            - │          0s  │
│ Deploy to GitHub Pages   │           2s │          5s  │
│ Post Cache dependencies  │           5s │          4s  │
│ Post Setup Node.js       │            - │          1s  │
│ Post Setup PNPM          │            - │          0s  │
│ Post Checkout            │           0s │          0s  │
│ Complete job             │           0s │          0s  │
├──────────────────────────┼──────────────┼──────────────┤
│ Total                    │          67s │          35s │
└──────────────────────────┴──────────────┴──────────────┘

As you can see, despite the increase in the number of steps in the new workflow, the overall efficiency has improved, proving that it’s not always about the number of steps but their effectiveness and efficiency.

Conclusion

This case study demonstrates the potential benefits of continually reviewing and optimizing your deployment pipelines, especially with git-based CMS. Like switching package managers, base modification can save time. As developers, we should always look for ways to improve our processes and tools, and this example serves as a great reminder of the impact such improvements can have.