Meteor 1.5’s code splitting is technologically awesome achievement by @Benjamin for big apps. But there are still ways Meteor could reduce bundle size & parsing time that I’d love to see.
Remove jQuery, as a dependency of any core package, so React apps can fully exclude it (95kb) (EDIT: Already done in Meteor. Jquery was a dependency of one of Flow Router’s deps. Solution to remove it: Meteor speed wishlist (bundle size improvements) - #50 by viejo)
Remove es5-shim as a dep of any core package so it can actually be removed for devs who don’t want to support IE8. Removing via meteor doesn’t remove it from the project, it must be a dependency of another package.
Use one of either lodash or underscore. IIRC both lodash and underscore used in core packages as a holdover from the past.
When it’s production ready, evaluate https://prepack.io/ in the build chain because it can reduce JS evaluation time which is currently a significant portion of app load time.
1 and 2 are the biggest.
What else is on your wish list? Any time estimates for any of these, if a core dev is reading?
@sashko That’d be awesome if that were the case regarding Jquery. But I’ve never been able to get rid of it in a react app. I suppose it’s in a hard to find place from one of my meteor packages, if that’s the case.
Running “npm ls” doesn’t show any packages with jquery as a dependency.
I also ran this command to view Meteor package dependencies and still don’t see Jquery (results below). But this must not be going deep enough given Jquery is still included. for p in meteor list | grep ‘[1]’ | awk ‘{ print $1"@"$2 }’; do echo "$p"; meteor show "$p" | grep -E '^ [a-z]'; echo; done
Was hoping to see a couple of these in 1.5 (Jquery removal…but maybe that was done…TBD + tree shaking). JS bundle size and evaluation has been a big painpoint in my meteor app and I’ve been anxiously awaiting 1.5 and it didn’t decrease my app size at all. So I want to start a discussion about remaining ideas for this, understand the roadmap better, mention some things like PrePack.io which are new and developers may not come across yet, and hopefully get other ideas from community members…or snarky comments, whichever.
A lot of these things were on our mind, but we wanted to ship the current features ASAP! Tree shaking and more dependency removal and analysis is still on the table.
Code splitting seems to be a biggest benefit to those who have apps which can be split based on different routes or app sections.
I have basically a SPA that can’t be split, it’s one page with MVP features, and anything that can be delayed is too small to not matter. But it has pretty strict speed goals based on the type of users that will use it (last minute type of thing). It’s not huge (300kb), but still ~2.4s to start render and 4.4s to visually complete on webpagetest.org. Goal is 2s - 2.5s to visually complete above fold. My non-SPA sites used to be 1.2s.
My two biggest offenders are Jquery (which I don’t use, but frustratingly can’t get rid of) and React currently. Considering switching from React (45kb) > Inferno (9kb) to get this down.
Speed is a discussion I enjoy. I still hope to hear more ideas here. Outside of meteor, speed has been an area of my specialty. I enjoy talking about this stuff and learning how to improve meteor apps.
I guess I would be investigating SSR then? Also, I would expect to see subsequent load times on your page drop if you use the 1.5 import model to cache your modules. Although that still wouldn’t help on the initial load…
That is totally done/do-able. I have been running meteor without jquery for a while, but it’s hard to uncover all the places it can be. Try removing kadira.
I know MDG is working on removing underscore. Most of your client code could probably omit it if you’re using react and not blaze.
Also, bonus, if you import the dot notated individual packages like lodash.clone you can get by with only that one slice of lodash.
If you import lodash/clone you still get the whole bundle.
I’ve been working on a post about this topic, for anyone interested in it… not sure if my article is any better than the meteor blog and this thread, but at least it’s a new take and perhaps covers a slightly different angle:
Hope this helps, and let me know if I need to correct anything. I plan on making a few more posts from different angles.
Thank you! Good to hear confirmation that it’s possible to remove jquery. I think it’s a dep of a dep’s dep Will have to keep searching.
Your blog post is fantastic! That will be really good for people to understand dynamic imports. I don’t notice any errors but I think it would be useful to explain why/why not to dynamically load react specifically. I wouldn’t because it is needed for the 1st load, but it’s something that I think would be useful for people. Very very good post!
@benjamn@sashko One more speed idea: meteor could use HTTP2’s server push by including Meteor’s CSS and initial JS bundle in the http header. This would eliminate the wait for the HTML page and let CSS and JS download and be parsed at the same time:
I’m also very curious because I also think importing from lodash/clone will result in a bundle size improvement, actually better than importing from lodash.clone.
Well - one of my other tests was off, so I suspect this could be too. I tried to make a micro test for it, but something was still importing all of lodash… so I’m going to make a super-micro focused test and I’ll let you know once and for all… (WIP)
importing from lodash/* should result in smaller bundle size.
There is a babel-plugin which rewrites your lodash imports so that it always uses cherry-picking:
however, I still found the whole lodash-lib in my bundle, so i am not sure if this works with meteor, because meteor also fumbles on the import-statements
