Optimizing Netlify
Tags: javascript, performance
Published: 2021-09-06 20:30:02

---
title: Optimizing Netlify
published: true
date: 2021-09-06 18:23:39 UTC
tags: javascript, performance
canonical_url: https://atfzl.com/optimizing-netlify
---

I don’t work at netlify but I’ll show how their Single Page Application load time can be improved.

Log in to [https://netlify.com](https://netlify.com).

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/2c1d9195-c287-4dd0-a8e9-c091a90385a6.png)

You’ll be redirected to [https://app.netlify.com](https://app.netlify.com) after logging in. This is the SPA we’ll be optimizing.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/f137516e-7d80-4b64-ad8a-0c8ca5f81487.png)

Open Chrome DevTools (cmd + options + i)  
Select `Performance` Panel

Make sure `Screenshot` option selected (useful to check when app was loaded)

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/a26c050a-8ca5-47c9-9249-f41a56d80dde.png)

Start recording and refresh the page. Stop the recording when the page has loaded. We have the DevTools open in detached mode to view the timeline.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/111e10b7-ca15-4349-82c1-3baadc933630.png)

On closer look in the network section, it looks like the network call `api.netlify.com/api/v1/user` is duplicated. `api.segment.io/v1/p` is also duplicated but that doesn’t look much interesting.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/0fca616a-5007-4cc2-968f-ca58346745e2.png)

We go to the Network panel of DevTools to check the details about this `user` api.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/122b4e82-2097-4ad0-b0de-0538e5e8dda5.png)

Now we check the call stack for both these calls.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/a820bc29-ef17-4d96-b9a5-23e336ded248.png)

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/c125f121-5b54-4ed7-8202-629f6961214e.png)

Both call stack look pretty similar with one difference.

```
- App.js:432
+ App.js:459
```

Different lines in the same file:

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/fd1e6d5c-707c-4ac9-89bd-b048bb661d72.png)

We’re lucky Netlify has source-maps enabled in public, otherwise we’d see minify code.

The first `useEffect` is meant to run when the app loads for first time, at this time `userId` is not defined.

The second `useEffect` is running again when `userId` is not defined. It should be:

```
useEffect(() => {
  if (userId) {
    load(props);
  }
}, [userId]);
```

**This will fix the api call being made twice.**

Now back to the timeline, I see an opportunity for improving the app load time.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/28530f9b-596c-4427-9d11-dc49935aca89.png)

Looks like the main thread is not doing much while the network calls are being made. The current process is in series: the JavaScript runs and this code makes some network calls. We can do these in parallel because the network calls are handled by browser in a separate thread.

To do this we’d normally need the source to build the code but we’ll be using [Chrome Local Overrides](https://developer.chrome.com/blog/new-in-devtools-65/#overrides).

I have the main html file `overview` and main js file `app.bundle.js` overridden with my local copy.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/0092f1ed-6ae0-4bc5-907d-a59ef751323c.png)

I found a place where I’ll short-circuit the api call for `user`:

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/db8f5341-1c43-44a5-9151-fa8569db82ce.png)

Updating this to

```
  user() {
    return window.userPromise || this.request('/user');
  }
```

Now we’ll define `window.userPromise` in the main HTML file because we want this api call made ASAP. We’ll add a new `<script>` tag and add our `/user` api call with the correct access token from the local storage.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/32f3318a-6d9e-4b23-a7a6-4aaab08cf674.png)

And it works, we now have an api call at the start of page, in parallel as the main JavaScript code runs.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/4ebb7afe-64c5-4490-a991-a15fa732452c.png)

But there are 2 more network calls which are blocking the app render, let’s optimize them in the same way.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/61866cba-07bf-4bbc-aa03-4545934d1cf1.png)

We now have a busy main thread, networks calls and JavaScript code are being run in parallel.

![](https://blotcdn.com/blog_b4fa49aeb5e8474db144c0adb7862258/_image_cache/891b1b3b-683c-4e4a-817a-75e2932a80e2.png)

For my system and network, I could see around **40% reduction in app load time from 2000ms to 1200ms**.

This is a common scenario in SPA using bundling systems like Webpack, API calls are made after the code is run. Early API calls is a simple method to improve app load time for a lot of web apps.