What's wrong appcache and meteor in general?

Today I wanted to give appcache a try on one of the apps I’m currently developing. I had never used it before.

My whole app at the time weighs in at around 750kb and this includes both client and server files, including everything in public as well.

So there I do meteor add appcache and right that instant, I get this on my prompt:

You are using the appcache package but the total size of the
cached resources is 6.0MB.

This is over the recommended maximum of 5 MB and may break your
app in some browsers! See http://docs.meteor.com/#appcache
for more information and fixes.

Alright, so what takes up more than 5MB and needs to be delivered to the client???

The packages that I’ve yet included are:

accounts-google
audit-argument-checks
awatson1978:browser-detection
dburles:collection-helpers
dburles:google-maps
email
fastclick
gadicohen:headers
gadicohen:sitemaps
iron:router
matb33:collection-hooks
meteorhacks:sikka
meteorhacks:unblock
meteor-platform
mizzao:timesync
momentjs:moment
okgrow:iron-router-autoscroll
percolate:synced-cron
reywood:iron-router-ga
rzymek:moment-locale-tr
service-configuration
spiderable
todda00:collection-revisions
underscorestring:underscore.string

Chrome console’s network tab reports a transfer around 967kb in total. Of course that is gzipped. Inspecting further, those assets, uncompressed, may actually be more than 5MB, of which, 1.2MB is jquery alone. DDP, minimongo and blaze take up something like 1.5MB. Iron router and a very select few essential packages take another 1MB.

So there actually is no headroom left for any application code!

So I’m wondering, am I doing something inherently wrong here or is appcache just not applicable to meteor projects the way they are?

1 Like

It would be cool if atmosphere calculated “size on client” or something for packages automatically so we could be smart shoppers.

Does Meteor use Google Closure compiler or some other code minimization approach? Is that only invoked in production mode or via a build command?

I think meteor uses uglifyjs and it does a fairly good job.

I believe the problem is mostly with meteor itself. Barebones meteor takes up more than 3MB.

I agree on your atmosphere comment and I also do believe that there is huge room for improvement with everything atmosphere. I believe there has been some discussion around that earlier.

Regarding what goes into appcache, I wish we could actually exclude things like jquery and even ddp, blaze and get the opportunity to load them over from a CDN. Come to think of it, every single meteor app out there share at least 3MB of common client code! If that’s not what a CDN is for, then what is?

2 Likes

Their plan for Galaxy includes automagic CDN distro for everything. So maybe it’s a “patience, grasshopper” thing.

Haha, well right, I guess :smile:

By the way, I deployed the app to check what actually gets into the client and interestingly, the whole bundle gzipped weight is 230kb and uncompressed storage takes around 800KB.

This makes me wonder now. Perhaps appcache was complaining way prematurely.

I’m confused…

1 Like

UPDATE:

  1. It seems this issue is already reported at https://github.com/meteor/meteor/issues/1323

  2. There currently is no way to actually know the size before deploying. So the best practice is deploy the app, check the size in your broser console, if all is good, include the appcache package in your app and redeploy

  3. Evidently, the 5MB limit should not be a concern since modern desktop/mobile browser limits are waaay higher https://github.com/meteor/meteor/issues/3738

So, dear future reader, if you’ve come this far in this thread, go back to your app and install appcache

Cheers from 2015!

3 Likes

Pls note, that appcache doesn’t work in conjunction with FastRender!

1 Like

What was the issue with appcache and fastrender? Is it still an issue?