• 5 Strategies to Reduce Frontend Build Time with CI/CD
• Bhagya Vithana
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Zz Zhaojin
• Proofread by: Kimhooo, KimYangOfCat

Five strategies for optimizing front-end builds with CI/CD

Using CI/CD tools is a requirement for web application development today. Building systems faster as part of a critical development path is critical to increasing developer productivity.

So in this article, we’ll walk you through five different strategies for optimizing front-end build times using CI/CD.

1. Use Parallel network package parallel-WebPack

Parallel-webpack lets you build your application as you run it, reducing application build time.

You can easily get started with parallel-webpack by using the following NPM command:

NPM install the parallel - webpack - - save - devCopy the code

To better understand the configuration of Parallel-WebPack, let’s take a look at a simple example.

var path = require('path');
module.exports = [{
  entry: './firstjob.js'.output: {
    path: path.resolve(__dirname, './dist'),
   filename: 'task1.bundle.js'}}, {entry: './secondjob.js'.output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'task2.bundle.js'}}];Copy the code

The above configuration consists of two separate build tasks, firstJob and SecondJob. Parallel-webpack will run both build tasks at the same time, and you’ll find task1.bundle.js and task2.bundle.js built at the same time.

Parallel-webpack allows you to control parallelism, including common Webpack features such as Watcher and Retry limit.

Control parallelism

Sometimes, you may want to limit the number of CPU cores available for parallel-Webpack. In this case, you can specify the number of CPU cores available using the parallel-webpack -p=2 command.

Running observer

One of the features that makes Webpack so influential is its observer, which can continuously rebuild your application. You can use the same functionality in parallel-WebPack effortlessly, simply by adding the Watch flag to the command.

parallel-webpack --watch
Copy the code

Similarly, parallel-WebPack has a lot of exciting features that can be integrated into your CI/CD pipeline to speed it up. You can also find out more about it in the documentation.

2. Break the application into microfronts

Consider traditional monolithic front-end systems, most of which have only one build pipeline and one release pipeline. Therefore, if there is a bug fix or new feature update, it is possible to break the entire build phase in the CI/CD pipeline.

However, if we use a microfront end, we can split the functionality of the application and maintain the build and release pipeline of the application independently so that updates and bug fixes are constantly submitted.

Often, you can integrate and deploy each application independently, allowing you to fix important functionality more quickly. So this really helps speed up the CI/CD process.

3. Component driven CI: Ripple CI

Component-driven CI is a CI that runs only on modified components and all their dependencies (that is, affected components) and does not treat the entire project as a single entity. A typical example of Ripple CI is Bit.

4. Optimize Webpack performance

We usually use the default Settings for Webpack. However, do you know how to further optimize it by using plug-ins and custom configurations?

useuglifyjs-webpack-plugin v1The plug-in

Compression is the process of compressing code, markup, and script files in your web pages. It is one of the main ways to reduce build time.

However, as the project grows in size, the modification process itself can take considerable time.

If the project is being built, the uglifyjs-webpack-plugin v1 can be used to optimize the build time. This plug-in provides the ability to run multiple processes in parallel and cache support, greatly improving build efficiency.

Use loaders during compression of modules

Webpack uses loaders to convert other types of files into valid modules. These modules are then received by the application and added to the dependency diagram.

Therefore, relevant file directories must be specified to reduce unnecessary module loading.

In a Webpack configuration, you can easily specify file directories with the include option.

const path = require('path');

module.exports = {
  / /...
  module: {
    rules: [{test: /\.js$/,
        include: path.resolve(__dirname, 'src'),
        loader: 'css-loader',},],},};Copy the code

5. Pipeline cache installed by NPM module

As we all know, installing node modules takes time. We found this to be a problem, especially in pipes that take more time because they install node modules every time they run.

NPM caching is a simple caching mechanism that we can use in our build pipeline to avoid running an NPM installation every time.

This caching mechanism will make your build pipeline similar to your local development environment. You only need to install the node module once, and the same module will be used for subsequent builds.

For example, let’s look at the Azure DevOps pipeline for a NodeJS project.

The most recommended way to cache NPM modules for NodeJs projects is to use NPM’s shared cache directory. This directory contains cached versions of all downloaded modules. Whenever we run the NPM install command, NPM first checks this directory and gets stored packages there.

The sample code

variables: 
npm_config_cache: $(Pipeline.Workspace)/.npm 

steps: 
- task: Cache@2 
  inputs: 
    key: 'the NPM | "$(Agent. OS)" | Package - lock. Json ' 
    restoreKeys: | NPM | "$(Agent. OS)"    path: $(npm_config_cache) 
  displayName: Cache npm

- script: npm ci
Copy the code

This paper summarizes

As you’ve already learned, there are five techniques that can speed up front-end application build times. In addition, there are many other technologies that may be appropriate for technology development and workflows. You should choose the method that fits the use case.

In the meantime, I hope the discussion here has helped you understand the above strategies to speed up the front end build time of the CI/CD process.

Thanks for reading!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.