Rspack: Speed & Bundle Size Improvements

[vikr00001]

This is just for my app only. All build times are with --production set true. RSPack tests were done via Meteor 3.4 beta 11.

[minhna]

the reduction of client bundle size is a game changer.

[nachocodoner]

Hey @vikr00001!

Great to see your changes, especially the bundle size improvements.

Regarding HMR and builds, how did you gather the data? Did you use meteor profile on the app in both Meteor 3.3 and 3.4-beta.12? It’s odd I don’t see gains in HMR client. Did you revise the numbers?

I recently adapted a real-world app showing:

Client bundle size

Client bundle size dropped from 8.56 MB to 2.51 MB (~70.68% dropped), with a few optimizations still pending.

These metrics are easy to read in your Galaxy dashboard or in the browser.

Build times

For build times, see the attached meteor profile example for that app:

Scenario	Original (ms)	Improved (ms)	% Reduction	Times Faster
Cold start	26 486	8 304	68.64%	3.19×
Cache start	15 562	5 970	61.64%	2.61×
Rebuild client #1	1 764	431	75.57%	4.09×
Rebuild client #2	1 704	431	74.71%	3.95×
Rebuild server #1	7 561	2 390	68.38%	3.16×
Rebuild server #2	6 900	1 846	73.24%	3.74×

Meteor 3.4-beta.12 for this app shows around 70% faster build and rebuild times, including both client and server HMR/rebuild. I applied other optimizations I will talk about in the future for some phases, but gains should show just by adopting Rspack in all phases.

---

I’ve seen this pattern in many apps I’ve migrated, so I’m curious how you measured the client rebuild data. It should show gains as now Rspack dev server and HMR strategy takes place.

[vikr00001]

I had no idea those stats were available on Galaxy!

For client change HMR I just used a stopwatch and waited for changes on the client.

For server change updates while the client is live, I used a stopwatch and waited for the console log saying “App is now running on http://localhost:3000/”,

I got the numbers for the client bundle from bundle-visualizer.

Amazing improvements!