Client reload times during development > concatenation?

Continuing from this topic about load times, actually I’m noticing that client load times during development are also a huge time-sink.
I’m wondering if a simple file concat of all the JSX stuff would speed things up?

I have a simple adminUI, but breaking up all the parts into separate React classes, just the client load takes 20s

development: 179 requests / 3.9mb / 20s
production: 5 requests / 589kb / 4s

I can understand how during dev mode all the JS(x) files are separate, but the difference in file size is surprising. minified goes to ~12% (maybe react-runtime-dev and some other packages are stripped out in --production mode). In any case my guess is the latency of all those 100s of requests is more of a killer than the bandwidth to localhost. They seem to also come down sequentially:

I wonder if it’s worth running some other pre-processor to combine all the JSX files into one before meteor build? Has anyone experimented with such an approaches?

Does the new

OK well a quick experiment to put ALL the client side code concatted into one big file

 files 179    ->  118    ( 30% less )
 load  18.5s  ->  7.8s   ( 55% faster )

so reducing the number of files with a simple concat has a really huge effect on client loads. 30% less files, for 50% better load time.

I could probably get rid of some other files - splitting all client side only Collection code and concatenating that etc. but that’s more laborious. Put all the css into one file. OK meteor + grunt, what a reinvention of the wheel.

Presumably this is something the meteor build tool is doing anyway, but with a bit more smarts.
But could the ‘concat’ part of the build tool be broken out run even in dev mode?

@sashko ?


have you tried using this release?


I’ve found that this release makes rebuilds lightning fast.

yes, i’m using that release (see related thread). That does speed up server reload times, but doesn’t affect client load times at all. Having an app with hundreds of individual JS files during development will inevitably lead to slow loads, but it’s much nicer for dev than one huge file.

I guess the normal node/react world has solved this problem with webpack and things like

The meatier project has an approach where changes to server side code don’t force a client side reload at all (I think I’ve noticed that sometimes with meteor too, but not sure).

Overall as a project gets bigger both client and server reloads get waaay slower. I’m about two weeks in on this project and its already pretty tedious to work on/ wait for.

The best combo i’ve used was webpack in Meteor. My ~22sec reloads were cut down to 1.4 seconds for hot-loading. A full refresh (cmd r) takes around 3-4 seconds. It seems as webpacks reload time is fairly logarithmic as tripling the file count only slightly increases the reload time.

My new computer (4ghz i7 and a fast SSD) has cut it down further to ~0.8 seconds. Fast enough to do inline styles even.

Note, this is using the react hot loader module which allows the module that changed to update. Another perk is that your state is maintained so that’s likely to save more time if you have a complex set of steps to get into a certain state while modifying code (like a form).

Hey @SkinnyGeek1010, could you explain how you went about to make react-hot-loader work with Meteor? Am really jealous of your .8s reloads :wink:

Edit: Sorry, didn’t realise this thread was so old, lots of things have changed since January 2016!