DEV Community: Atif Afzal

Optimizing Netlify

Atif Afzal — Mon, 06 Sep 2021 18:23:39 +0000

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

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

Open Chrome DevTools (cmd + options + i)

Select Performance Panel

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

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.

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.

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

Now we check the call stack for both these calls.

Both call stack look pretty similar with one difference.

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

Different lines in the same file:

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.

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.

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

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

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.

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

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

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

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.

Don’t attach tooltips to document.body

Atif Afzal — Wed, 10 Mar 2021 00:00:00 +0000

TL;DR

Instead of attaching tooltips directly to document.body, attach them to a predefined div in document.body.

BAD

<body>
    <!-- temporary div, vanishes when tooltips vanishes -->
    <div>my tooltip</div>
<body>

GOOD

<body>
    <!-- this div stays forever, just for attaching tooltips -->
    <div id="tooltips-container">
        <!-- temporary div, vanishes when tooltips vanishes -->
        <div>my tooltip</div>
    </div>
<body>

Introduction

Tooltips in our app were taking >80ms. And during this time, the main thread was blocked, you couldn’t interact with anything.

Other components like modal, popover, dropdown had similar performance issues. In some cases, a modal took more than 1 second to appear while making the UI unresponsive.

The main reason for the slowness of Tooltip was Recalculate Style being called at the end of mouseover event call stack which takes a lot of time.

I noticed the tooltip performance was inversely proportional to number of DOM nodes currently in document.

Before diving deep into the investigation, we’ll talk about some prerequisites.

How browser works at page load

The browser creates a DOM tree from the HTML string.

You can see it as Parse HTML in the performance timeline in Chrome DevTools.

Then the CSS is parsed and browser creates the CSSOM (CSS Object Model).

Then the browser combines the DOM and CSSOM to create the render tree.

Render tree consists of elements currently visible on the page. Elements with property like display: none are not part of the render tree. If we have a pseudo element in CSS like after, then it is part of the render tree although it is not a part of the DOM. The creation/modification of the render tree is called Recalculate Style in the performance timeline.

Important: render tree is invalidated when we modify DOM or change styles of any element.

Next step is layout. Layout is calculating the size and positions of elements of the render tree, to know where we have to draw exactly. This is referred to as Layout in the performance timeline.

Layout may need to be done again whenever there is a change in size/position of an element which affects the position of all the elements in the page. Layout is also known as Reflow.

Next steps are paint and composting but we won’t talk about them here as they are not important for explanation of this topic.

How browser handles rendering during runtime

To render a frame in a browser, we go in this order: JavaScript runs, then there are style calculation, then layout. Ignore Paint and Composite for now.

When we access any layout property like offsetWidth, offsetParent, width etc, the browser returns the value from previously calculated layout calculations, which is not expensive as the calculation was done earlier in the previous frame and now we are just reading it.

But what happens when we change a style on an element or modify the DOM? Then the browser has its own heuristics and is smart enough to know if the browser needs to Recalculate Style/Layout in the current frame or defer it for later.

You can see it as Schedule Style Recalculation in timeline.

The problem happens when we try to access a layout property just after we change style/modify DOM. Then the browser has to force Recalculate Style/Layout because browser has to return the current value, it cannot give you a stale value from the previous frame. This causes the problem known as Layout Thrashing.

Example:

BAD

Here we are first changing the style and then immediately reading offsetHeight property which causes a Synchronous Forced Layout.

You’ll see this warning in browser when this happens:

GOOD

This is fine because we are first reading the layout property offsetHeight which is not expensive as we are just reading the value from the previous frame’s layout calculation. Then we change the style later which is ok, the layout might still happen but it is up to browser when to do it, it is not forced.

Investigation

Here we can see a lot of elements (807) are affected by the Recalculate Style event which is the reason this event takes a lot of time.

The Call Stacks detail gives us important information to debug this issue. The field Recalculation Forced shows the value getOffsetParent @ popper.js:188 which is this code in popper.js@1.15.0:

var offsetPArent = element.offsetParent;

The next field is First Invalidation with value Tooltip._this.handleEnter @ Tooltip.js:165 in @material-ui/core@3.9.3

_this.childrenRef.setAttribute('title', '');

The First Invalidation shows where in code, the render tree was first invalidated which later caused Forced Reflow because of Recalculation Forced code.

Doing setAttribute on an element in DOM is invalidating the render tree, and then accessing the offsetParent causes a Forced Synchronous Layout.

Had this been done in the opposite direction it wouldn’t be a problem.

I tried commenting the setAttribute code and again ran the performance timeline. But the issue was still there but the invalidation was happening somewhere else.

The invalidation is now happening when the tooltip is added to the body, which invalidates the render tree.

Popper accessing the offsetParent property after attaching the tooltip to the body is causing Forced Reflow. If this property access was done before attaching the tooltip to body, the reflow would not have happened.

But all this is not in our control as the code is in the third party library popper.js.

Now, what can we do?

Next, I created a separate container in the body where the tooltip would always be attached.

<body>
    <div id="tooltips-container"></div>
    <div id="myapp">...</div>
</body>

And instructed the popper to be rendered in this container.

const popperProps = {
    container: () => document.getElementById('tooltips-container'),
};

Now, the performance was greatly improved, the Recalculate Style still happened but its cost was less than before. 0.79ms down from 66.57ms:

What happened here? The tooltip was attached to the tooltip container and not to the body. This invalidated a much smaller subtree, which was the tooltip container. The tooltip container is not visible in the page, so modifying it doesn’t invalidate the complete page render tree. If the tooltip container would have been visible in the page, then the complete render tree would be invalidated but in this case only an independent subtree was invalidated. Recalculating Style for a small subtree of 3 doesn’t take a lot of time and hence is faster.

The Element Affected is 3 which is the number of nodes inside our tooltip container.

<div id="tooltips-container">
    <div role="tooltip" ...>
        <div class="MuiTooltip-tooltip-66 ..." ...>
            <span class="tooltipContent__..">
                Tooltip Text
            </span>
        </div>
    </div>
</div>

The ideal case would be to not access the offsetParent property in DOM after attaching it, but it is needed for popper.js to calculate where to render the tooltip.

Popper.js first attaches the tooltip to the body and then moves it to the correct position. If popper.js calculated the position first and then attached the tooltip to the body later, then we wouldn’t have this problem of Recalculate Style. We are using an older version of @material-ui/core@3.9.3 which is using an old version of popper.js@1.15.0.

Result

The mouseover event in our tooltip finishes much quickly and does not cause jank in the experience.

8ms from 80ms

Tooltips are now 10x faster.

References

Website Performance Optimization - Udacity (App load optimization)
Browser Rendering Optimization - Udacity (App runtime optimization)
Avoid forced synchronous layouts - Web Fundamentals Google
What DOM element property access forces layout / reflow

Understanding Solid: JSX

Atif Afzal — Mon, 25 Nov 2019 20:28:56 +0000

JSX was introduced by Facebook for complementing React in javascript. It is a common misconception that JSX is somehow coupled with React or its siblings like React Native, Preact, Inferno etc. But JSX is an extension to javascript and can be used in other places beside React.

Solid uses JSX to render vanilla DOM elements. In React the <div /> compiles to React.createElement('div') but in Solid you could say it compiles to document.createElement('div') (actually it uses HTML templates, more on this ahead).

Hello World component:

function HelloWorld() {
  return (
    <div>
      Hello World
    </div>
  );
}

This will (conceptually) compile to:

function HelloWorld() {
  const el$ = document.createElement('div');

  el$.innerText = 'Hello World';

  return el$;
}

Actually solid uses HTML template element because it is more performant for creating new instances from same template.

So it actually compiles to this:

function _$template(str) {
  const t = document.createElement('template');
  t.innerHTML = str;
  return t.content.firstChild;
}

const _tmpl$ = _$template(`<div>Hello World</div>`);

function HelloWorld() {
  return _tmpl$.cloneNode(true);
}

From the previous post we know how solid is tracking dependencies. We’ll use it here now by creating a counter.

function Counter() {
  const [state, setState] = createState({ counter: 0 });

  setInterval(() => {
    setState({ counter: state.counter + 1 });
  });

  return (
    <div>
      {state.counter}
    </div>
  );
}

This will compile to:

const _tmpl$ = _$template(`<div></div>`);

function Counter() {
  const [state, setState] = createState({
    counter: 0
  });
  setInterval(() => {
    setState({
      counter: state.counter + 1
    });
  });
  return function () {
    const _el$ = _tmpl$.cloneNode(true);

    createEffect(() => {
      _el$.innerText = state.counter;
    });

    return _el$;
  }(); // NOTE: this is an iife!
}

Note that the string passed to _$template does not have the part where we had the dynamic value {state.counter}. It will be added later in createEffect.

Now whenever we update the counter, the createEffect block runs which updates the innerText of _el$.

JSX with nesting:

function Counter() {
  const [state, setState] = createState({ counter: 0 });

  setInterval(() => {
    setState({ counter: state.counter + 1 });
  });

  return (
    <div>
      <div>Counter:</div>
      <div>{state.counter}</div>
    </div>
  );
}

Compiles to:

const _tmpl$ = _$template(`<div><div>Counter:</div><div></div></div>`);

function Counter() {
  const [state, setState] = createState({
    counter: 0
  });
  setInterval(() => {
    setState({
      counter: state.counter + 1
    });
  });
  return function () {
    const _el$ = _tmpl$.cloneNode(true),
          _el$2 = _el$.firstChild,
          _el$3 = _el$2.nextSibling;

    createEffect(() => {
      _el$3.innerText = state.counter;
    });

    return _el$;
  }();
}

Note that the static part string: Counter: is left inside the template string passed to _$template We refer to the nested elements by using combination of firstChild, nextSibling etc.

And this is in short how Solid works. Effectively these two parts: dependency tracking and JSX provide the best of both worlds. We get the best performance by executing only the minimal code which is needed and with JSX we get to keep the mental model introduced by React which keeps us more productive.

Using iTerm triggers

Atif Afzal — Tue, 19 Nov 2019 18:17:38 +0000

iTerm triggers can be used for converting text in your terminal to URLs and make them clickable. This is useful for creating JIRA issue links whenever there is a JIRA-1234 like pattern.

Steps:

Go to iTerm -> Preferences -> Profiles -> Advanced -> Triggers Edit

Add an entry in the table

Regular Expression: (?i)JIRA-\d+
Action: Make Hyperlink
Parameters: https://jira.yourhost.com/jira/browse/\0¯

Now whenever there is a pattern with JIRA-1234, it will become a clickable hyperlink.

Use emacs key bindings everywhere

Atif Afzal — Tue, 12 Nov 2019 13:06:26 +0000

I am used to emacs keybinding.

My caps lock is mapped to ctrl to avoid emacs pinky.

I am also used to making movements the emacs way , i.e.,

ctrl+f: right arrow
ctrl+b: left arrow
ctrl+p: up arrow
ctrl+n: down arrow

I have also remapped Ctrl+g to escape because I despise the escape key in the MacBook Pro touch bar.

Mac supports this keybinding in most applications but these do not work for all applications. Like in my case it was Notability. For any kind of text editing, easy movement is a must.

After a lot of googling I found out about Karabiner-Elements which modifies the key bindings in the most stable and reliable way. It also has some nice customisations like ignoring keybindings for some set of applications. I am ignoring emacs because it already has the correct keybinding and using the modified keybindings messes it up.

After installing, open up the config ~/.config/karabiner/karabiner.json

This is my Karabiner configurations for above mentioned modifications:

profiles[0].simple_modifications =

[
  {
    "from": {
      "key_code": "caps_lock"
    },
    "to": {
      "key_code": "left_control"
    }
  }
]

profiles[0].complex_modifications.rules =

[
  {
    "description": "Ctrl+F to right_arrow",
    "manipulators": [
      {
        "description": "emacs like movement",
        "from": {
          "key_code": "f",
          "modifiers": {
            "mandatory": [
              "left_control"
            ]
          }
        },
        "to": [
          {
            "key_code": "right_arrow"
          }
        ],
        "conditions": [
          {
            "type": "frontmost_application_unless",
            "bundle_identifiers": [
              "^org\\.gnu\\.Emacs"
            ]
          }
        ],
        "type": "basic"
      }
    ]
  },
  {
    "description": "Ctrl+B to left_arrow",
    "manipulators": [
      {
        "description": "emacs like movement",
        "from": {
          "key_code": "b",
          "modifiers": {
            "mandatory": [
              "left_control"
            ]
          }
        },
        "to": [
          {
            "key_code": "left_arrow"
          }
        ],
        "conditions": [
          {
            "type": "frontmost_application_unless",
            "bundle_identifiers": [
              "^org\\.gnu\\.Emacs"
            ]
          }
        ],
        "type": "basic"
      }
    ]
  },
  {
    "description": "Ctrl+P to up_arrow",
    "manipulators": [
      {
        "description": "emacs like movement",
        "from": {
          "key_code": "p",
          "modifiers": {
            "mandatory": [
              "left_control"
            ]
          }
        },
        "to": [
          {
            "key_code": "up_arrow"
          }
        ],
        "conditions": [
          {
            "type": "frontmost_application_unless",
            "bundle_identifiers": [
              "^org\\.gnu\\.Emacs"
            ]
          }
        ],
        "type": "basic"
      }
    ]
  },
  {
    "description": "Ctrl+N to down_arrow",
    "manipulators": [
      {
        "description": "emacs like movement",
        "from": {
          "key_code": "n",
          "modifiers": {
            "mandatory": [
              "left_control"
            ]
          }
        },
        "to": [
          {
            "key_code": "down_arrow"
          }
        ],
        "conditions": [
          {
            "type": "frontmost_application_unless",
            "bundle_identifiers": [
              "^org\\.gnu\\.Emacs"
            ]
          }
        ],
        "type": "basic"
      }
    ]
  },
  {
    "description": "Ctrl+G to Escape",
    "manipulators": [
      {
        "description": "emacs like escape",
        "from": {
          "key_code": "g",
          "modifiers": {
            "mandatory": [
              "left_control"
            ]
          }
        },
        "to": [
          {
            "key_code": "escape"
          }
        ],
        "conditions": [
          {
            "type": "frontmost_application_unless",
            "bundle_identifiers": [
              "^org\\.gnu\\.Emacs"
            ]
          }
        ],
        "type": "basic"
      }
    ]
  }
]

Understanding Solid: Reactivity Basics

Atif Afzal — Thu, 10 Oct 2019 16:20:47 +0000

Solid is a Reactive library for creating user interfaces. Solid updates the DOM only where it is required, without using Virtual DOM. Solid is fast.

To understand Solid, first we have to understand its Reactive ideology.

Let’s take an example of a simple auto updating counter to show how the code looks like and explain how it works under the hood.

First a counter without a UI: Solid Counter - CodeSandbox

import { createState, createEffect } from 'solid-js';

const [state, setState] = createState({ count: 0 });

setInterval(() => {
  setState({ count: state.count + 1 });
}, 1000);

createEffect(() => {
  console.log(state.count);
});

This code looks too much similar to React hooks and it is actually inspired from React hooks. But there is a major difference, contrary to React, this code will not run again and again top to down like in a React component. Instead we have code blocks which are run whenever their dependencies are updated.

createEffect

Whenever the value of state.count is updated the code block passed to createEffect is called which in turn will call console.log every 1 second.

0
1
2
3
4
...

How does createEffect knows when to call this function whenever state.count changes ?

The answer lies in Javascript Proxy.

The state returned by createState is actually a proxy object, it has setter and getter traps for all properties on the original object.

Whenever a value is updated on this object, the setter is called. And whenever a value is accessed, the getter is called.

Let’s try to have a feel with some rough pseudocode:

let activeBlock;

// not real code, rough estimation
state.count = {
  _blocks: [],
  getter() {
    if (activeBlock) {
      this._blocks.push(activeBlock);
    }
    ...
  }
  setter() {
    if (this._blocks.length) {
      this._blocks.forEach(block => block());
    }
    ...
  }
}

function createEffect(f) {
  activeBlock = f;
  f();
  activeBlock = undefined;
}

...

createEffect(() => {
  console.log(state.count);
});

Let’s call the function passed to createEffect as f.

When we call createEffect, first we save f in activeBlock variable and then run f. Then whenever a getter is hit, we save activeBlock with the current property so that the dependent blocks can be run, when there is a hit to its setter.

In our counter example, f is the block with console.log(state.count) in it. For the first time when createEffect calls f, it saves f in activeBlock variable. Then it runs f.

Now when f runs, it encounters state.count and its getter is executed,. Then f is pushed to this._blocks.

If we also had some other block with state.count, its reference would also be pushed in the this._blocks array.

createEffect(() => {
  console.log('2 x Counter = ', state.count * 2);
});

If in the future state.count is updated, its setter will be triggered and it will execute all its saved blocks.

In this way we do not need to explicitly define what we have to track, and the blocks would be run whenever anything in the block changes.

setState instead of setter

Solid emphasises uni-directional data flow like React. So instead of directly updating the value of state, setState must be used to trigger the setter.

Reactive html element with solid

Now that we know the basics of createEffect and how its works, let's use createEffect to update an HTML element.

Counter with a UI element: Solid Counter - CodeSandbox

const [state, setState] = createState({ count: 0 });

setInterval(() => {
  setState({ count: state.count + 1 });
}, 1000);

const el = document.createElement('div');

document.body.appendChild(el);

createEffect(() => {
  el.innerText = state.count;
});

So we are using createEffect to update the DOM text.

Similarly we can update className, style and other attributes reactively:

className

createEffect(() => {
  el.className = state.count % 2 === 0 ? "even" : "odd";
});

style

we are using Object.assign because = does not work with style attribute.

createEffect(() => {
  Object.assign(
    el.style,
    { color: state.count % 2 === 0 ? "black" : "white" }
  );
});

data-*

createEffect(() => {
  el.setAttribute(
    "data-test", 
    state.count % 2 === 0 ? "even" : "odd"
  );
});

These were the basic reactive ideas needed to understand how solid works under the hood. Next post will cover jsx in solid.

This is the first blog post of series: Understanding Solid. Next post: Understanding Solid: JSX

Using flow and eslint in Emacs

Atif Afzal — Sun, 06 Nov 2016 00:00:00 +0000

(require 'company)
(require 'web-mode)
(require 'flycheck)
(require 'flycheck-flow)

;; flow auto complete
;; skip this if you don't use company-mode
(eval-after-load 'company
  '(add-to-list 'company-backends 'company-flow))

;; add eslint and flow checkers to flycheck
(flycheck-add-mode 'javascript-eslint 'web-mode)
(flycheck-add-mode 'javascript-flow 'web-mode)

;;disable jshint since we prefer eslint checking
(setq-default flycheck-disabled-checkers
  (append flycheck-disabled-checkers
    '(javascript-jshint)))

(defun jsWithEslint ()
  "eslint for js files"
  (interactive)
  (web-mode)
  (web-mode-set-content-type "jsx")
  (flycheck-disable-checker 'javascript-flow)
  (flycheck-select-checker 'javascript-eslint)
  (flycheck-mode))

(defun jsWithEslintFlow ()
  "flow and eslint for js files"
  (interactive)
  (web-mode)
  (web-mode-set-content-type "jsx")
  (flycheck-select-checker 'javascript-eslint)
  (flycheck-add-next-checker 'javascript-eslint 'javascript-flow)
  (flycheck-mode))

;; set key shortcuts if you want
;; (global-set-key (kbd "C-c j") 'jsWithEslint)
;; (global-set-key (kbd "C-c f") 'jsWithEslintFlow)

(add-to-list 'auto-mode-alist '("\\.js\\'" . jsWithEslint))
(add-to-list 'magic-mode-alist '("/\\* @flow \\*/" . jsWithEslintFlow))

Now all the .js files will use eslint.

But if you have /\* @flow \*/ comment at the first line, flow will also be used.

To use local eslint and flow-bin from your node_modules, check out this package: add-node-modules-path.