Join the Effort to Speed Up Meteor bundler

[italojs]

Join the Effort to Speed Up Meteor: Learn to Profile & Optimize!

Hello Meteor Community!

We’ve been working hard to make Meteor faster and more efficient, especially the bundling process. But we can’t do it alone.

The Meteor bundler is a complex piece of machinery that can become a significant bottleneck, especially in larger applications.

Where to get started?

By learning to profile your Meteor applications, you can:

1. Identify exactly what’s slowing down your builds
2. Find optimization opportunities in your own code
3. Contribute to the core by identifying issues in Meteor itself
4. Help test and validate performance improvements

Resources to Get You Started

We’ve published some resources to help you understand and use Meteor’s profiling tools:

• Meteor’s bundler Profiling - Learn about the new profiling tools in Meteor 3.2
• Meteor’s CPU Profiling - Comprehensive guide to CPU profiling in Meteor

What We’re Already Working On

1. Babel replacement - nachocodoner is doing an awesome working on replacing it with SWC (much faster Rust-based transpiler) in PRs #13675 and #13674

How You Can Contribute

1. Run profiling on your app: Follow the guides to profile your own Meteor applications
2. Share your findings: Post your profile results, especially if you find interesting bottlenecks
3. Suggest improvements: Based on your profiles, what could be optimized?

Let’s work together to make Meteor faster than ever! Share your findings below or in this GitHub discussion.

[harry73]

Awesome.

Does this also apply if we use meteor-vite ?

[minhna]

| Top leaves:
| Babel.compile...........................................40,653 ms (1420)
| sqlite query.............................................6,820 ms (1)
| jsAnalyze.parse..........................................4,923 ms (5281)
| other reifyCompileWithCache..............................4,299 ms (4218)
| other compileUnibuild (the app)..........................3,280 ms (3)
| files.stat...............................................3,052 ms (105340)
| files.readFile...........................................2,595 ms (97169)
| other ImportScanner#resolve..............................2,346 ms (19613)
| files.readdirWithTypes...................................1,621 ms (117414)
| other PackageSource#_findSources for os..................1,556 ms (2)
| other ImportScanner#scanImports for the app..............1,438 ms (2)
| getPrelinkedFiles toStringWithSourceMap..................1,068 ms (200)

Do you think Babel.compile took too much time?

[superfail]

@italojs Is it possible and would it help to run profiling on apps before v3?

[superfail]

@italojs Will it be possible to debug bundles? Similar to the bundle visualizer but machine readable?

[dokithonon]

Hello,

I am trying the command but the log file is empty
My command :

cd ~/rationalk; SERVER_WEBSOCKET_COMPRESSION=true METEOR_NO_DEPRECATION=true WARN_WHEN_USING_OLD_API=true METEOR_ENABLE_CLIENT_TOP_LEVEL_AWAIT=true TOOL_NODE_FLAGS="--max-old-space-size=4096 --no-expose-gc" meteor profile --settings settings.json --exclude-archs web.browser.legacy,web.cordova;

===============================              -
 Profile script
===============================
 - App path: /Users/dokithonon/rationalk
 - App port: 3000
 - Logs file: /Users/dokithonon/rationalk/logs/1743351232699-rationalk-bundle.log
===============================
===============================
 Full log details at /Users/dokithonon/rationalk/logs/1743351232699-rationalk-bundle.log
===============================
===============================              \
 Not detected entrypoint files
 Please set the environment variables METEOR_CLIENT_ENTRYPOINT and METEOR_SERVER_ENTRYPOINT
===============================

The log file is created but the file is empty.
What am I doing wrong ?

I am on meteor 3.2

I have never configured any client or server entry points… I have no idea what is it.

[italojs]

@harry73

meteor-vite

Should work for all packages

[italojs]

Just a little bit lol
nachocodoner is working on replacing it with SWC (much faster Rust-based transpiler) in PRs #13675 and #13674

[italojs]

Is it possible and would it help to run profiling on apps before v3?

Maybe, but our priority is to improve the v3 performance.

Will it be possible to debug bundles? Similar to the bundle visualizer but machine readable?

Yeap

[nachocodoner]

In Meteor 3.2, we introduced the new meteor profile command, which helps verify improvements in the Meteor 3 bundler. We encourage you to start generating profiles now so you’ll have benchmarks to compare against future releases. Remember fair comparisons will be made with the same app state, only swapping the Meteor version and using the same machine.

In the upcoming Meteor 3.3 release, we plan to introduce bundler enhancements. These changes will lay the groundwork for integrating modern bundlers later, providing a faster development experience on building your app code and access to bundler features from the broader ecosystem. Meteor will remain the Meteor dev server and tool you’re familiar with, offering its unique ability to build Meteor packages and deliver final bundles multiplatform. Our goal is to refine the Meteor tool first, improve profiling numbers, and enhance the experience without compromising what makes Meteor unique.

One key improvement in Meteor 3.3 will be the integration of SWC as the bundler transpiler. Alongside other enhancements, this change will significantly speed up common Meteor dev tasks, giving you noticeable build time improvements.

The comparison below uses the simpletasks app to illustrate the performance differences between 3.2 and the latest SWC improvements and other optimizations. While we’re still making more adjustments, this demo gives you an idea of the progress you can expect in your Meteor app.

The numbers clearly show that your app will benefit significantly from faster cold and cache starts during initial builds, with subsequent starts speeding up even more (~160% or ~2.6 times faster than 3.2 / “Build App” stage in all phases). Additionally, the development experience will improve: rebuilding client and server code will respond faster, and HMR will react more quickly (~50% or ~1,5 faster than 3.2 / “Rebuild App” stage in “Rebuild client” and “Rebuild server” phases).

Learn more about the phases in the article: Unlocking Meteor 3.2: New Profiling Tool to Track Bundler Performance and Size.

We hope this provides a clear picture of what we aim to achieve and how significant Meteor remains to us, along with the opportunities it presents on optimize the existing system. By migrating to Meteor 3, we want everyone to see it as a framework that’s not only optimized and feature-rich but also still relevant in the dev ecosystem, with its standout features like real-time capabilities and multiplatform experience.

[nachocodoner]

It’s likely that many Meteor applications will still lack clearly defined entry points for client and server code. In other words, the meteor.mainModule keys in the package.json may not specify the initial files to load for both the client and server. If you create a new Meteor app using meteor create, you’ll see an example of how this configuration should look in the package.json.

The first step in improving performance is to define these entry points. By doing so, the Meteor bundler skip eagerly loading JavaScript modules, so identifying all modules used in the app, even those not directly referenced.

If you’re unable to modify the entry points or just want to compare performance without them first, you can use the METEOR_CLIENT_ENTRYPOINT and METEOR_SERVER_ENTRYPOINT environment variables. These variables should point to the initial client and server files or any other client-only and server-only files you wish to test. The profiling script then makes a change to these files, adding and removing a line, to simulate changes and trigger a rebuild for the time to be measured.

Let me know if you’ve tried profiling using these environment variables and whether defining entry points improves performance.

[minhna]

@nachocodoner

~60% faster / “Build App”

I think it’s not 60% faster. It’s 3 times faster or 200% faster than the original (3.2)

[nachocodoner]

You’re absolutely right! I refer instead on the percentage of execution time decreased. Let me update that quickly. Thanks!

[dokithonon]

Thank you.
I created an empty main.js on the client and one on the server.

Result :

===============================
 Meteor version - METEOR@3.2
===============================
 Meteor options - --settings settings.json --exclude-archs web.browser.legacy,web.cordova
===============================
===============================
Metrics - Cold start
===============================
 - Meteor(resolveConstraints): 3788 ms       |
 - Meteor(prepareProjectForBuild): 30741 ms
 - Meteor(Build App): 70443 ms
 - Meteor(Server startup): 4647 ms
 * Total(Meteor): 109619 ms
===============================
Metrics - Cache start
===============================
 - Meteor(resolveConstraints): 921 ms        /
 - Meteor(prepareProjectForBuild): 4411 ms
 - Meteor(Build App): 36184 ms
 - Meteor(Server startup): 4260 ms
 * Total(Meteor): 45776 ms                   -
===============================
Metrics - Rebuild client
===============================
 - Meteor(resolveConstraints): 908 ms        |
 - Meteor(prepareProjectForBuild): 4659 ms
 - Meteor(Build App): 34327 ms
 - Meteor(Server startup): 4138 ms
 - Meteor(Rebuild App): 3781 ms
 - Meteor(Rebuild App)#2: 3340 ms
 * Total(Meteor): 51153 ms                   /
===============================
Metrics - Rebuild server
===============================
 - Meteor(resolveConstraints): 908 ms        \
 - Meteor(prepareProjectForBuild): 4477 ms
 - Meteor(Build App): 34393 ms
 - Meteor(Server startup): 4081 ms
 - Meteor(Rebuild App): 5459 ms
 - Meteor(Rebuild App)#2: 5164 ms
 * Total(Meteor): 54482 ms                   /

And il the log file :

| Top leaves:
| Babel.compile...........................................38,930 ms (3188)
| jsAnalyze.parse..........................................6,429 ms (9750)
| other plugin templating-compiler.........................5,473 ms (1)
| getPrelinkedFiles toStringWithSourceMap..................2,446 ms (354)
| linker File#getPrelinkedOutput...........................1,857 ms (6993)
| other linker File#computeAssignedVariables...............1,206 ms (7008)
| files.readFile...........................................1,114 ms (10730)
| files.writeFile..........................................1,066 ms (9014)
| other reifyCompileWithCache................................958 ms (688)
| other linker Module#getPrelinkedFiles......................755 ms (354)
| other PackageSourceBatch#_linkJS...........................644 ms (354)
| files.readdirWithTypes.....................................589 ms (13156)
| files.stat.................................................581 ms (19667)
| sha1.......................................................447 ms (43644)
| other ImportScanner#resolve................................396 ms (6784)
| other ImportScanner#findImportedModuleIdentifiers..........381 ms (5537)
| other Target#_emitResources................................335 ms (2)
| other ClientTarget#write...................................290 ms (1)
| files.rm_recursive.........................................290 ms (357)
| other ImportScanner#scanImports for webapp.................282 ms (2)
| other ImportScanner#scanImports for universe:i18n..........255 ms (2)
| findImportedModuleIdentifiersVisitor.......................249 ms (3729)
| other ImportScanner#realPath...............................225 ms (9022)
| files.rename...............................................212 ms (2746)
| other JsImage#write........................................212 ms (1)
| other ImportScanner#scanImports for rationalk:erp..........202 ms (2)
| files.watchFile............................................201 ms (19187)
| other linker.fullLink......................................193 ms (354)
| other PackageSource#_findSources for os....................192 ms (1)
| files.lstat................................................191 ms (16310)
| other PackageSourceBatch.computeJsOutputFilesMap...........168 ms (2)
| other bundler writeSiteArchive.............................156 ms (1)
| sha512.....................................................139 ms (5176)
| other Builder#copyNodeModulesDirectory.....................126 ms (39)
| other safeWatcher.watch....................................121 ms (42737)
| other compileUnibuild (the app)............................109 ms (3)
| other bundler writeFile....................................100 ms (3274)
| 
| (#3) Total: 70,443 ms (Build App)

[nachocodoner]

Thanks for sharing your profiles. I’m curious about the main entry points for meteor.mainModule in your app. For example, a configuration in package.json might look like this:

{
  ...
  "meteor": {
    "mainModule": {
      "client": "ui/main.jsx",
      "server": "api/main.js"
    }
  }
  ...
}

These entry points act as the files that load all the other modules for the client and server. Using these entry points ensures only the “tree” files that are actually imported by these files get loaded, rather than eagerly loading every JS file in your project folder. Setting this up could be a helpful improvement, and I’d like to know if it makes any difference in the profiles. Could you try this and get again the profiles? Or is there a particular limitation preventing you from configuring it this way?

[dokithonon]

Hello,
Our app is very large and I do not know how to convert our actual structure to the one you describe using entry files

How we do it now :

EDIT : I have just realized that creating empty entry points break our apps… I will revert to NO entry points

[permb]

I tried running meteor profile XXX instead of meteor run XXX for our app, but it crashed after a while. Is there any additional diagnostic output I can enable?

The error in the log file is:
/…/node_modules/.cache/meteor/performance/scripts/monitor-bundler.sh: line 189: 59655 Killed: 9 METEOR_PROFILE=“${METEOR_PROFILE:-1}}” METEOR_PACKAGE_DIRS=“${METEOR_PACKAGE_DIRS}” ${meteorCmd} run ${meteorOptions}

The output on the command line (slightly redacted):

===============================               
 Profile script
===============================
 - App path: /PATH
 - App port: 3000
 - Logs file: /PATH/logs/1743447797259-refapp-bundle.log
===============================
===============================
 Full log details at /PATH/logs/1743447797259-refapp-bundle.log
===============================
 * Profiling "Cold start"...                 |
===============================              -
 An error occurred when profiling. For more details, check at /PATH/logs/1743447797259-refapp-bundle.log
===============================
zsh: killed     yarn debug:nointegrations:profile

[storyteller]

From cold start the profiler crashes on me:

| (#3) Profiling: Build App
/home/storyteller/Web/Literary-Universe/app/node_modules/.cache/meteor/performance/scripts/monitor-bundler.sh: line 189: 1051493 Killed 

[nachocodoner]

Entrypoints should be files that serve as the starting point for importing the rest of the project. Due to the nature of the project (possibly related to Blaze or FlowRouter), it might not support entrypoints. Since I’m not familiar with that stack, I can’t confirm. Perhaps @jkuester or @harry97 could provide more insight. Have you seen any Blaze projects defining “meteor.mainModule” entrypoints?

[victor]

Thanks for adding this feature, the profiler works well in this 2019 app upgraded all the way to Meteor 3.2 with the entrypoints in package.json

[Edit] updating the relevant parts here :

| Top leaves:
| other bundler.bundle....................................27,707 ms (1)
| Babel.compile...........................................14,734 ms (1646)
| other ImportScanner#scanImports for the app..............2,117 ms (3)
| other sqlite query.......................................1,902 ms (6)
| jsAnalyze.parse..........................................1,744 ms (6317)
| files.readFile...........................................1,263 ms (19076)
| getPrelinkedFiles toStringWithSourceMap..................1,079 ms (343)
| other ImportScanner#scanImports for allohouston:ys-crossfilter.700 ms (2).  <- custom package
| other plugin templating-compiler...........................647 ms (2)
| linker File#getPrelinkedOutput.............................558 ms (6890)
| files.writeFile............................................510 ms (3672)
| files.readdirWithTypes.....................................508 ms (24876)
| other linker File#computeAssignedVariables.................478 ms (5663)
| other ImportScanner#scanImports for allohouston:general....430 ms (3) <- custom package
| other ImportScanner#resolve................................420 ms (11854)
| files.stat.................................................313 ms (19709)
| other reifyCompileWithCache................................301 ms (2319)
| other PackageSourceBatch#_linkJS...........................278 ms (343)
| files.rename...............................................215 ms (2783)
| other compileUnibuild (the app)............................205 ms (3)
| CssTools.stringifyCss......................................201 ms (664)
| other ImportScanner#scanImports for universe:i18n..........156 ms (3)
| other ImportScanner#scanImports for base64.................147 ms (3)
| other ImportScanner#findImportedModuleIdentifiers..........140 ms (5426)
| other ImportScanner#realPath...............................133 ms (6061)
| files.watchFile............................................121 ms (20717)
| other PackageSource#_findSources for os....................109 ms (2)
| files.rm_recursive.........................................108 ms (347)
| 
| (#3) Total: 29,823 ms (Build App)



===============================
Metrics - Cold start
===============================
 - Meteor(resolveConstraints): 2111 ms
 - Meteor(prepareProjectForBuild): 8703 ms
 - Meteor(Build App): 32479 ms
 - Meteor(Server startup): 1760 ms
 * Total(Meteor): 45053 ms
===============================
Metrics - Cache start
===============================
 - Meteor(resolveConstraints): 376 ms
 - Meteor(prepareProjectForBuild): 1292 ms
 - Meteor(Build App): 11219 ms
 - Meteor(Server startup): 852 ms
 * Total(Meteor): 13739 ms
===============================
Metrics - Rebuild client
===============================
 - Meteor(resolveConstraints): 285 ms
 - Meteor(prepareProjectForBuild): 624 ms
 - Meteor(Build App): 8632 ms
 - Meteor(Server startup): 815 ms
 - Meteor(prepareProjectForBuild #1): 39 ms
 - Meteor(Rebuild App #1): 1128 ms
 - Meteor(prepareProjectForBuild #2): 42 ms
 - Meteor(Rebuild App #2): 874 ms
 * Total(Meteor): 12439 ms
===============================
Metrics - Rebuild server
===============================
 - Meteor(resolveConstraints): 371 ms
 - Meteor(prepareProjectForBuild): 1151 ms
 - Meteor(Build App): 9272 ms
 - Meteor(Server startup): 1154 ms
 - Meteor(prepareProjectForBuild #1): 32 ms
 - Meteor(Rebuild App #1): 1505 ms
 - Meteor(Server startup #1): 826 ms
 - Meteor(prepareProjectForBuild #2): 29 ms
 - Meteor(Rebuild App #2): 1298 ms
 - Meteor(Server startup #2): 805 ms
 * Total(Meteor): 16443 ms