
At my home system, I run a simple stock market analysis everyday, using a node app. I download the [end of day market data](http://www.eoddata.com/download.aspx), put it into the local postgres, and then calculate stats and indicators on every stock symbol. I track only the NYSE and NASDAQ exchanges which comes close to 6100 symbols.

The problem is the **processing time**.

While 6100 may seem a small number, it takes around **30 to 45 minutes** to calculate the indicators (_sma20, sma50, sma200, stochastic, bollinger bands and MACD_) on all the symbols and then update the results to database. It takes long time because the calculation is heavily CPU/IO bound and my laptop could only haul so much at given time. :)

Earlier, I used a simple `for` loop to go through all the symbols sequentially.

```javascript
// sequential processing of symbols
const numOfSymbols = symbols.length; // 6100
for (let i=0; i < numOfSymbols; i++) {
    const sma20 = calculateSMA(symbols[i], 20);
    // other indicators sma50, sma200, stochastic, macd and bollinger band
    uploadToDatabase(sma20);
}
// takes around 45 minutes to finish  🐢 😢
```

But,it can be better. Each symbol's indicators can be calculated independent of each other, so I could use some form of parallelism to speed up the processing time. Enter `child_process.fork()` method.

## fork()

[fork](https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options) takes in a module path and spawns a new Node.js process that runs the given module code, in parallel to the parent / other forked processes.

So I extracted the indicator calculation code into `daily-indicators.js` file and then forked this module for a set of symbols. I just had to implement a communication logic to determine if I had processed all the symbols and then clean up the forked process.

```javascript
// parent.js
const runIndicators = () =>
  new Promise(async resolve => {
    const allSymbols = await db.getAllSymbols();
    const totalSymbols = allSymbols.length;
    const chunks = [];
    while (allSymbols.length) {
      chunks.push(allSymbols.splice(0, 1000));
    }
    let chunksDone = 0;
    for (let i = 0; i < chunks.length; i++) {
      const chunkProcessor = fork(path.join(__dirname, "daily-indicators.js"));
      chunkProcessor.on("message", msg => {
        if (msg.status === "done") {
          chunksDone += 1;
          chunkProcessor.kill();
          if (chunksDone >= chunks.length) {
            resolve();
          }
        }
      });
      chunkProcessor.send({ symbols: chunks[i] });
    }
  });
  await runIndicators();

  // --------------------------- //

  // daily-indicators.js
  process.on("message", async msg => {
    const { symbols } = msg;
    for (let i = 0; i < symbols.length; i++) {
      await calculateIndicators(symbols[i]);
    }
    process.send({ status: "done" });
  });
```

With this improved implementation, the whole process takes less than 10 minutes to finish! 🚀
```


Using Node fork() to speed up processing time


Some time back, I built [Gauge Generator](https://veerasundar.com/gauge-generator/) as a weekend project. This app helps to create custom gauges and export them as SVGs to be used in a dashboard design projects. It was built using React framework and create-react-app tool.

[![Gauge Generator](https://camo.githubusercontent.com/af4950bea23bb576ecd36bb60a1a8cdf6414a1c3/68747470733a2f2f692e696d6775722e636f6d2f7664484a42464d2e706e67)](https://veerasundar.com/gauge-generator/)

Since it was a fun little weekend project, I did not spend much time on optimizing it. As the app now complete, I thought it's a good time to take another look at its performance and optimize it if necessary.

## Measuring React app performance

"If you can't measure it, you can't improve it". So, we need to first see where the issue is in order to fix it.

Measuring React app performace is not difficult. React uses [User timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API) to log performance metrics which we can easily look into via browser's developer tools.

Additionally, we can use [React Developer tools](https://github.com/facebook/react-devtools) _Higlight Updates_ feature to visually see which React components are rendered as the app state changes thus figuring out which components are rendered unnecessarily.

### 1. Finding wasted renders

First enable "Highlight Updates" in React Developer tools preference. Now interact with your app and you will see the components are highlighted.

![Highlight updates of React app](https://i.imgur.com/noeyRQe.gif)

In the above recording, you can see lots of boxes displayed around components as I increase the slider value. You can also notice that even though I only make change in one React component, it triggers updates in all other react components as well. Ideally, as I change Gauge value, I want only the Gauge and the Gauge value component to get updated, not the whole app.

### 2. Measuring wasted renders

Now we know that our app renders components unnecessarily, lets measure how much CPU cycles are getting wasted.

Open Chrome Dev tool's Performance tab and record the app as you increase the slider value. But before doing this, disable any React addons in the browser, as they may impact our measurements. Record the measurements for less than 10 seconds, else the Chrome might hang. For our case, recording for 3 seconds is more than enough. After the recording stopped, Chrome will open the detailed report (click to enlarge).

[![React app performance metrics](https://i.imgur.com/Os0VaVe.png)](https://i.imgur.com/Os0VaVe.png)

When you focus on one single render cycle, we can see that the component `InputColor` and `InputField` are getting updated and taking almost 90ms for each render cycle. This render is unnecessary and can be optimized.

## Optimizing the React app performance

Now we know where the bottleneck is. We need to avoid rendering components unless it is _really_ needed. In our case, the problem lies on these two components - `InputColor` and `InputField`. We can go about fixing these components in two ways.

1. Using `shouldComponentUpdate` method, you can determine if a component needs to be updated/rendered as its state/prop changes. You can manually compare React component's next state/props with currect state/props and return either `true` or `false` to let React know to update or not.
2. Or, by Using `PureComponent`, you can let React to do the shallow comparison of state/props values. This is a recommended approach as it saves us from doing manual comparison.

So, I updated both `InputColor` and `InputFields` components to extend from `PureComponent` instead of `Component`.

```javascript
import React, { PureComponent } from "react";

class InputColor extends PureComponent {
  /*  code here */
}

class InputField extends PureComponent {
  /*  code here */
}
```

Below is how the application rendered after making the above change. If you see, now there are no unnecessary renders as I slide the Gauge value. Only the top level components are re-rendered.

![using PureComponent of Reat helps improve performance](https://i.imgur.com/Dddziqp.gif)

Perfect! With a simple fix, we were able to reduce the number of rendered components to a minumum. To confirm the improvment, lets measure the metrics and see (click to enlarge).

[![React app improved performance metrics](https://i.imgur.com/fFn559t.png)](https://i.imgur.com/fFn559t.png)

If you compare the above results with the previous measurement, you can clearely see we have no calls to `InputColor` or `InputField` is made, thus saving around 90ms for each render cycle.

## Conclusion

In most cases, switching to use `PureComponent` or manually defining `shouldComponentUpdate` will always result in performance improvment. But you need to make sure that when a state changes, you don't mutate the object, but instead you always return a new object. This is because the `PureComponent` does a shallow comparision, so if you mutate a nested property, it won't be able to detect the change, hence it won't re-render your component. So, just be sure not to mutate state.

Apart from using `PureComponent`, breaking large component into small components and passing the state as props to them will also help in saving wasted renders. Just make sure you only pass the props that is specifically needed by the small components. This way, `PureComponent` will get to compare the prop change and avoid rendering if necessary.




```


Optimizing performance of a React app


Loading time is one of the key metric for any web application these days. There are several optimization techniques exist to help with reducing page load time. If you are using [Webpack](https://webpack.js.org/), you can make use of tools that come in-built to improve page loading time.

In this article, we are going to see how to do code splitting using webpack. Let's start!

## What we are building?

We are building an imaginary web application, with a landing page and button. When the user clicks on the button, we are going to load a dynamic form. In real word, this form could be your big application.

![Loading a dynamic form](https://i.imgur.com/eXVVswt.gif)

The problem here is, the form we are loading could be huge. We need to show this form only when the user clicks on the button.

But, Without code splitting, we are loading the entire bundle, even for the user's who may not even click the button. That's bad!

![Bundle size without optimization is huge](https://i.imgur.com/8qGUM9P.png)

So, let's optimize this: let's split landing page bundle and form bundle, and load the form bundle only when the user clicks on the button.

## Setting up Webpack

First, we need a project and a working webpack setup. To do this, run the below commands in one of your working directory.

```text
$ mkdir codepslit
$ cd codesplit
$ npm init
$ npm install lodash
$ npm install webpack webpack-dev-server -D
```

Once the dependencies are installed, open this project in any of your favorite IDE (I used IntelliJ). Now create folders `src` and `dist` that will be our source and output folders. Also, create a file named `webpack.config.js` in the root of your project. Finally, your structure will look something like this:

![Directory Structure](https://i.imgur.com/l5jQvHo.png)

Now, use the following webpack configuration to get our project built through webpack.

### webpack.config.js

```javascript
const path = require('path');

module.exports = {
    entry: "./src/index.js",
    output: {
        path: path.resolve(__dirname, 'dist/'),
        filename: 'bundle.js'
    },
    devServer: {
        contentBase: 'dist'
    }
};
```

With this simple configuration, webpack takes the source files from `./src/index.js` and outputs them to `dist` folder. Now, lets create two files: `index.js` - our landing page and `form.js` - our dynamically loaded form.

### src/index.js

```javascript
// statically import form module.
import form from "./form";

window.onload = function () {
    let btn = document.getElementById('load');
    btn.addEventListener('click', function () {
        document.getElementById('form').appendChild(form.render());
    });
};
```

In our landing page, we are statically importing `form.js` on load itself and attaching an event to the button. When the button is clicked, we are rendering the form contents to our page (Note: for simplicity, I am using methods like `appendChild` to create dynamic elements on page. For production, you should consider frameworks such as React, Vue which are really good at UI construction).

### src/form.js

```javascript
import _ from "lodash";

export default {
    render: function () {
        let form = document.createElement('form');
        _.map(['Name', 'Email', 'Contact'], function (field) {
            let lbl = document.createElement('label');
            lbl.innerHTML = field;
            let txt = document.createElement('input');
            txt.type = 'text';
            let container = document.createElement('div');
            container.className = 'field';
            container.appendChild(lbl);
            container.appendChild(txt);
            form.appendChild(container);
        });
        return form;
    }
};
```

Our imaginary application `form.js` is very simple: It constructs three form fields dynamically and returns them. Again, don't use `appendChild` or `createElement` to construct dynamic UI in production code. Use any frameworks.

### dist/index.html

```html
<body>
    <div class="app-loader">
        <h1>User Registration Form</h1>
        <button id="load">Load Form</button>
    </div>
    <div id="form"></div>
    <script src="/bundle.js"></script>
</body>
```

Above is the HTML file that houses our application. For brevity, the style part is stripped out.

With all the above files created, the final directory structure will look like this:

![Final Directory Structure](https://i.imgur.com/AJUxx6x.png)

## Bundling our project

Now when you run `webpack`, you will webpack is emitting one single bundle that has both our `index.js` and `form.js`. And this single bundle weighs **545 KB** which is bad and webpack itself complains about it via the comment **[big]**.

![Pre bundle size](https://i.imgur.com/qk6VqMQ.png)

## Code splitting using Dynamic imports

Webpack supports dynamic imports via `import()`. With this, webpack will be able to dynamically load a bundle at run time. But in order to use this, we need to setup [babel](https://babeljs.io/) first, as dynamic imports syntax is not supported out of the box now. We also need [Syntax Dynamic Import](http://babeljs.io/docs/plugins/syntax-dynamic-import/) babel plugin.

### 1. Install Babel and Configure webpack to use babel loader for JS files.

```text
npm install --save-dev babel-loader babel-core babel-plugin-syntax-dynamic-import
```

```javascript
/* add to webpack.config.js */
module: {
  rules: [
    { test: /\.js$/, exclude: /node_modules/, loader: "babel-loader" }
  ]
}
```
### 2. Configure Babel to use Syntax Dynamic Import

Add a `.babelrc` file at the root of your project.

```javascript
{
  "plugins" : ["syntax-dynamic-import"]
}
```

Once you have babel setup, now it's time to setup webpack to use dynamic imports. To do this, let tell webpack to emit named chunks. Modify the `entry` and `output` options in `webpack.config.js` as below:

```javascript
entry: {
    index: "./src/index.js"
},
output: {
    path: path.resolve(__dirname, 'dist/'),
    filename: '[name].bundle.js',
    chunkFilename: '[name].bundle.js',
},
```

And modify our landing page `index.js` to use dynamic imports instead of static import.

```javascript
window.onload = function () {
    let btn = document.getElementById('load');
    btn.addEventListener('click', function () {
        // dynamically import form module at run time.
        import(/* webpackChunkName: "form" */ './form').then(function (form) {
            document.getElementById('form').appendChild(form.default.render());
        });
    });
};
```

Notice that we have removed `import form from "./form.js"` line and moved it inside the event handler function of our button. We dynamically import this module via `import(/* webpackChunkName: "form" */ './form')` statement. This will return a `Promise` which will receive the dynamically loaded module as its param once its resolved. Inside the Promise callback, you can use the dynamically loaded module anyway you want.

> Note: You need to access your exported values from the dynamically loaded module as `module.default` (earlier, it was just `module`). Also, in `index.html`, load your modules as `/index.bundle.js`, instead of `/bundle.js`.

With this setup, now if you run `webpack`, you will see webpack generated two modules `index.bundle.js` and `form.bundle.js`.

![Code split bundles](https://i.imgur.com/GKmZFz9.png)

And, if you notice, now our landing page `index.bundle.js` size is only **6.14 KB**, which is a great reduction from the original size of **546 KB**. Since we will load only the `index.bundle.js` upon page load, our app will be very fast on the initial load. Hurrah!

To prove this, let's measure our app performance with [Lighthous](https://developers.google.com/web/tools/lighthouse/) for both pre and post optimization.

![Comparing page load time](https://i.imgur.com/M136MaD.png)

As you can see, with this simple setup, we are saving around **700ms** of page load time. Our site loads and become interactive faster, which is a win! 🎉


Webpack code splitting example


This blog is [built on Jekyll](https://veerasundar.com/blog/moving-from-wordpress-to-jekyll/) and served by Nginx. I chose Jekyll so that I could gain some performance boost from the static, pre-generated blog content rather than serving every blog request from a database. Nginx was the obvious choice because it's the efficient HTTP server out there.

However, every time I [check my pages in Pagespeed](https://developers.google.com/speed/pagespeed/insights/?url=veerasundar.com%2Fblog&tab=desktop), it complains that the static assets are not optimized and I should **Leverage browser caching**. This is because I missed to set Expires header in my Nginx configuration. Turns out it is very simple to do.

## Nginx configuration to set Expires header for images and static assets

Assuming you are using a Unix flavoured operating system (Ubuntu, in my case);

1. Go to `/etc/nginx/sites-available`.
2. Open your site configuration in an editor. For example, `vi veerasundar.com` (Use sudo if necessary).
3. In the server configuration, add the code to set Expires header if an request is made to a static file. Here's my complete configuration for this server.

```text
server {

        listen   80;
        server_name veerasundar.com;

        access_log /location/of/access.log;
        error_log /location/of/error.log;

        location / {

                        root   /location/of/www;
                        index  index.html index.htm;

                        if ($request_uri ~* ".(ico|css|js|gif|jpe?g|png)$") {
                                        expires 30d;
                                        access_log off;
                                        add_header Pragma public;
                                        add_header Cache-Control "public";
                                        break;
                                }

                        }

            }

```

After making the changes, save the file and restart nginx - `sudo /etc/init.d/nginx restart`.

Now your static files are served with **Expires** header and will be cached by the browser.


#performance (4)