Meteor speed wishlist (bundle size improvements)

performance
33

Have you tried the bundle visualizer yet? Basically it shows you up front what is taking up space in your app.

34

Thanks for answering. No, I have not. How do I get to that, is that in Chrome?

35

@aadams this is explained in the docs for Meteor 1.5, in the bundle-visualizer section. :slight_smile:

1 Like
36

Thanks. This the bundle-visualizer is only available in 1.5 or can I use it now in 1.3.5.1? It looks like there is no version requirement from the docs.

37

Sorry, I based on that on this context you used here previously when asking how to use it. It’s only for 1.5 and it will not work on older versions of Meteor.

2 Likes
38

Looking at your package list, I know offhand that meteorhacks:inject-data contains a dependency on jquery. This was a gotcha for me earlier.

To get rid of it, I had to do a quick and dirty fix where I cloned it locally to remove the dependency myself.

1 Like
39

That’s awesome! Thank you so much! I see there are old unmerged PRs to remove jquery as a dep from meteorhacks:inject-data.

How did you get your edited meteorhacks:inject-data used in your app, given it’s a dep of a meteor package? (If it were an NPM package, it’d be clear, but it’s a dep of a meteor package.)

40

Check the Meteor Guide

1 Like
41

Why not use prerender.io? Works fine for me and I’m using flowrouter.

42

I just cloned it and put it in the packages directory. Those will get precedent over everything else.

The “fix” is pretty much what is in https://github.com/meteorhacks/inject-data/pull/12/commits/dc8bf0cd55ae00832e9f8b5a3da0b024a8a9dc0e, but your needs may be different.

I haven’t looked at this in awhile, so I have lost a lot of context on it.

1 Like
43

I may be mistaken, but I thought prerender was primarily for SEO.

For me, the big win of SSR is entirely performance related; sending the html from the server with the necessary data to display immediately.

44

Honestly in today’s times I don’t really get the point of SSR anymore. A modern app should load at the most within 2 seconds with the first paint, PWAs should load in less than a second once loaded at least once. Do we really still need SSR for this? I admit, there’s probably still a minor speed improvement but still.

1 Like
45

We live in a world where it’s totally cool that Facebooks mobile app is over 200 MB and requires a new update every week while we complain about a 20 KB JQuery dependency.

So that’s the difference! Today I learned.

46

That’s the difference between a mobile app and a website.

A mobile app can be downloaded when convenient, but a website is downloaded, and a user must wait for it, before they can view the content the first time.

In this case, especially if your app doesn’t require jquery (esp react apps), it’s a double whammy because your user is both waiting for the 30kb download time and the JS parsing time, which for the entire bundle, is significant 800ms-1.2s on my app, more on larger apps, so every bit helps. Removing an unused jquery is a pretty big win imo. It all adds up.

If an app has SSR, then the visitor has useful content to view while the JS bundle downloads and parses and the bundle size doesn’t matter quite as much.

47

That worked!! Finally found and removed jquery! So happy. It was a dep of flow router’s dep. Thank you @moberegger and @robfallows Hopefully this helps others too!

1 Like
48

You can get a gauge of how much difference SSR would make for your app. Run it through webpagetest.org and then compare time to the first images loading, since in most cases that is when a useful render has occurred for the user:

html + JS download & parse + websocket connect & data download (if not using fast render) + first images
vs
html + first images

For my app, it would remove 1.6-2s for JS download and parse, making it load in less than half the time. So it’s a big win for me, but it depends whether your users visit your page less frequently and with a clean cache (more like a website) or more like an app that is used regularly for long durations. First load time won’t be as important if it’s the latter. (Edit: JS download and parse + websocket connect and download take 3s in my most recent test. Would be a big win.)

49

Parse time is something I hadn’t considered. Great point. Also, how did you refactor FlowRouter to work without the JQuery dependency? I’m in the exact same situation as you.

50
  1. Create a ‘packages’ directory in your project
  2. Change into it and run: git clone https://github.com/meteorhacks/inject-data.git
  3. Open these files and make the following changes https://github.com/meteorhacks/inject-data/pull/12/commits/dc8bf0cd55ae00832e9f8b5a3da0b024a8a9dc0e
  4. Restart your app. Your inject-data package will take precedence over the offending dependency.
    Credit to @moberegger for the solution.

Removing Jquery was an even bigger win than expected for my app. Enjoy!

1 Like
51

Thanks! Crossing my fingers this gets rid jquery once and for all.

52

I would also look at the fork made here: https://github.com/abecks/meteor-inject-data/

There was an issue introduced somewhere in 1.4.x that caused fast render to stop working (inject-data being a dependency of fast-render). I can’t remember specifically what it was, but you can take a peak at the commit history and see if those changes are relevant to you.