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]

I'm not quite sure how Metro's import/export plugin works. If you enable it (experimentalImportSupport: true and disableImportExportTransform: false), it does produce slightly bigger bundles, but still smaller than without esbuild. Tbh, it's been a while since I've looked at this code, so I don't remember all the details but I do believe the difference was significant enough for our apps.

[BrentonWheeler]

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

[tido64]

Thanks for sharing!

I'm a little curious about how this works. It looks like @babel/plugin-transform-modules-commonjs is already a part of @react-native/babel-preset:

-- https://github.com/facebook/react-native/blob/0.73-stable/packages/react-native-babel-preset/src/configs/main.js#L65-L81

And it looks like it is included as long as disableImportExportTransform is falsy. We encourage users to enable this to disable transforming import -> require as this will prevent esbuild from tree shaking.

[BrentonWheeler]

Is it somehow possible that the treeshaking is done then the remaining smaller bundle is converted?

[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.