• naruaway/quickbootjs

The key idea is that around 40% of your JS code might not be needed when booting your app (YMMV). And if we can figure out which part is actually needed, we can remove "probably unused" parts out of the initial JavaScript file with fallback behavior, which uses eval() and synchronous XHR to continue the execution even the actual execution path hits the removed part of the JS file. Check out the following video (it was initially announced in this X (Twitter) post, where you can see some discussions) :

(better textual / visual explanation of things like "motivation" / "how it works" / "limitations" will come here in the future)

See the live demo

I created a simple demo using React and framer-motion. Without Quickboot.js, it's impossible to reduce the JS size smaller than react-dom.

You can compare the JS sizes loaded before the animation starts using your web browser's network inspector. Here Quickboot.js reduces the JS size needed to start the animation by more than 40%. This size is smaller than react-dom package alone.

• without Quickboot.js
• with Quickboot.js

Try Quickboot.js with your own app

So far Quickboot.js only offers CLI to try to optimize JS bundle size needed to "boot" statically deployed apps. Note that Quickboot.js is meant to be used for JS assets built by "production mode" of your bundlers such as Webpack. There are several assumptions for the optimization target:

• You can cover potential execution paths of the targeted JavaScript file when collecting runtime execution trace. Otherwise users will hit synchronous XHR (with a loading indicator using this trick) on the initial loading phase, which is a bad UX. This means you need to cover all the potential different execution paths such as "mobile vs. desktop" if the target JS file changes which code to use based on it.
• (Most likely I am missing some assumptions here, I'll update later...)

To use Quickboot.js CLI, please follow the following instructions:

1. Run npx quickbootjs trace /path/to/your/target.js and follow the instruction to save the runtime execution trace
2. Then running npx quickbootjs optimize /path/to/your/target.js should produce the optimized JavaScript file
3. Then you can test the behavior of your app (I would appreciate if you could share the result on Twitter/X if it works or it does not work)

Note that this tool is highly experimental and you should NOT use it in production since there can be bugs or non obvious tradeoffs.

For example, we know that the usage of eval() slows down the runtime execution but we are not sure how much this could impact the actual observable application performance. Also, considering this tool is to improve the "boot time" of the application for the first visitor, if you ever want to deploy this to production, probably you should implement some logic to use the original JS bundle for the revisitors with some preloading logic so that revisitors can just use the original JavaScript code, which is more performant and has predictable behavior.

However, depending on your use case, Quickboot.js could bring more benefit than its potential drawbacks. If you are interested in deploying this to production (maybe under feature flags?). I am really interested in the use case so do not hesitate to contact Naru.

Known issues and next steps

Replacing unused code with eval is not as trivial as it seems and there are several bugs already. My next step is to create test cases to reliably reproduce the issues and fix them along with other obvious issues such as error handling.