iamakulov

Fun fact: the current JS-specific metric (which is being fazed out) is First Input Delay, and it was explicitly designed to avoid this gaming:

INP is the time between you click/press a key/etc and the moment the next paint happens. It’s only measured for on-page interactions, not for navigations.

AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).

This fall, I was lucky to help Causal (a web spreadsheet for forecasting) with speeding up their frontend app. Here are some of my favorite findings:

- Turns out when React DevTools tell you “the component rerenderd because hook no. 2 changed”, it doesn’t mean that it’s hook no. 2 that actually changed! That’s because a) `useContext` hooks aren’t counted, b) only native hooks are counted – so if you use one `useSelector`, but it has 8 native hooks inside, you’ll see something like “hook no. 7 changed”. You need to go to the Components pane and look for hook numbers there.

- Web workers are cool but hard to make use of :/ In this case, we tried moving an operation into a web worker but weren’t able to because copying data between threads took longer than the actual op. And one doc I’ve read earlier still fascinates me – in 2018, Google explored moving frameworks into web workers but stumbled upon many limitations [1].

- React (unfortunately) still causes a lot of performance issues. It’s too easy to rerender something unnecessarily; and in a large app, many cheap components easily add up into an expensive render. I’m looking forward to React Forget [2], hopefully, solving this (at least partially?)

- This was a v fun (and challenging, due to Causal's scale!) project to do

- Most optimizations we’ve implemented were (very effective) one-off fixes. But we were also glad to find some rules of thumb that help to keep the app faster by default [1]

- My most interesting discovery was how ineffective Web Workers are. Causal, sometimes, has to do some expensive client-side data parsing. We tried to move data parsing to a web worker (= a separate thread) – but ended up reverting the optimization because it made the app slower. In JS, you can’t just pass a pointer to a data structure between threads; the browser has to clone the data structure [2] (with limited exceptions [3]). In our case, cloning the data between threads ended up being several times slower than parsing it in the main thread.

TL;DR:

* Notion has a large startup time because they serve a lot of JavaScript. This JS has to be parsed, compiled, and executed – and this takes time. This is especially slow on Android phones [1].

* The obvious solution to this is code splitting. But in case of Notion, there’re a few other low-hanging fruits. For example, if you switch to CommonJS, you can (surprisingly) speed up the startup by deferring unnecessary modules [2]. Or, there’s a bunch of unnecessary libraries in the bundle (including 3 duplicates of CoreJS).

* Apart from JS execution, there’re also a few other issues. Analytics is loaded early – and it defers loading and execution of other, more important resources [3]. And page resources don’t have `Cache-Control` headers being set, which could lead to different caching behavior in different browsers.

Overall, based on my measurements and some guesses, I think Notion can cut around 30% off their initialization time – simply by tuning some configs and deferring some loading.

Would be happy to hear your feedback :)