metro-serializer-esbuild causing slower app TTI (TTFD)

[BrentonWheeler]

I'm finding that when using metro-serializer-esbuild instead of just metro-serializer that, while my app JS bundle is reduced by 40% (awesome BTW), my app launch time has gone from ~5s to ~9s (on a slow device) and a similar almost doubling of launch time on faster devices (only tested Android so far). Tested via the "Fully drawn" logcat log value (which can be added via use of https://www.npmjs.com/package/react-native-startup-time)

Let me know if you see this too otherwise I can look into making a reproduction example.

EDIT: Reproduction example: https://github.com/BrentonWheeler/esbuild-tti-test-app

yarn bundle:install (usingmetro-serializer):

yarn bundle:install+esbuild (using metro-serializer-esbuild):

[tido64]

Hi @BrentonWheeler, I think the difference you're seeing is due to inlineRequires: true in metro.config.js. If you disable it, what times do you see?

If I understand it correctly, inlineRequires basically moves your require() statements inline so that:

const fs = require("fs");

function read(p) {
  return fs.readFile("package.json", "utf-8");
}

Becomes:

function read(p) {
  return require("fs").readFile("package.json", "utf-8");
}

This can have a positive impact on your TTI because parts of your bundle is not executed until it is needed. However, we've disabled this in our apps because it assumes none of your dependencies have any side effects. We've experienced crashes because of this flag, so we always disable it now. This is also why we haven't seen this perf difference.

That said, the reason inlineRequires is disabled when you use metro-serializer-esbuild is because tree shaking only works when your code is in ESM. inlineRequires currently does not work on ESM, so it wouldn't have had any effect even if it was enabled. If you know which parts of your code is causing the slow down, you can manually inline import() those parts. Otherwise, I'm not aware of any good workarounds for this.

[tido64]

Unless something has changed recently, tree shaking is the very last step, just before writing to disk. That's why it's so important to preserve import/export statements till the very end. Both Babel and Metro configs are there to ensure this. We also had to make changes in Metro itself to make this possible.

[chang-ke]

FWIW I've largely resolved this issue via using @babel/plugin-transform-modules-commonjs and returning true from lazy for everything (ATM) eg:

plugins: [
        [
          '@babel/plugin-transform-modules-commonjs',
          {
            lazy: (source) => {
              return true;
            },
          },
        ],
...

It has allowed use of esbuild treeshaking for smaller bundle size, while maintaining the old TTI

Hey @BrentonWheeler , would you mind to share the whole configuration? as I'm facing the same issue, thanks!

[BrentonWheeler]

Hey @chang-ke, it's just the reproduction repo but with that change to the babel.config.js shown above, eg: https://github.com/BrentonWheeler/esbuild-tti-test-app/pull/1/files

[chang-ke]

@BrentonWheeler this plugin indeed make the TTI faster, but the bundle size also increased.. causing tree shaking failed

[BrentonWheeler]

Hmm, that is inline with what @tido64 has said so you both may be right, but on the reproduction repo I'm getting the same bundle size with and without the plugin:

yarn bundle:analyse = Bundle is 46.55 MB in size
yarn bundle:analyse+esbuild (without the plugin) = Bundle is 34.7 MB in size 
yarn bundle:analyse+esbuild (with the plugin) = Bundle is 34.7 MB in size