does this mean we can add static files (images) to the cordova build and have them therefore be inside the bundled app installed on the phone, and NOT trigger them to reload every time there a code push?
If referring to image URLs locally /assets/file.png does the cordova build process somehow look locally first, and only then go out to the web to get the files?
Im not sure how that will work, my feeling is that it will be bundled with the source code and will reload with a hot code push. Will have a look later on.
Other option is to store the files on the device itself with https://github.com/apache/cordova-plugin-file . Im busy creating a azure file handler package that will include a circular cache for cordova. So the first time the user see the image/video its saved to the device. Then every time the asset needs to display you first check the circular cache if the asset is there and the etag is still the same otherwise download it again to the circular cahce and display it or something like that 
I gave this some thought at some point but never tried it since I didnt think it would work with HCR. At least CloudFront has a ~15min invalidation time which really slows down the deployment. It would also get your server (thatâs already updated) out of sync with the clients who are 15 min behind, no? Did you try it? Would love to use it if it works nicely.
maybe if there was a way of splitting your own app code from framework code? meteor itself, jquery etc doesnât update so often and could be CDNâd? tho, that may lead to even more ugly mismatch problemsâŚ
This is called incremental loading and is not supported by Meteor as of today :sad:
Hello there.
I am a Meteor programmer in a startup company where this problem has become critical. After a 5 months, 6 full time people team effort (22101 lines of code in 143 modules), we have a web system in production. As far as we know, we have tried every idea posted in this thread, and we are still taking up to 16 seconds waiting for a first time load in to end user screen.
Those times are unacceptable for landing pages, which are entry point links published on marketing campaigns and ⌠we are loosing user traction. ¿Is anyone here available as consultant and willing to help us in how to mitigate this? We are willing to publish our case conclusions here, and share gained knowledge.
If you have a somewhat larger application I would advise against serving your marketing pages with meteor. Youâre sending data that is completely unnecessary for non-users of the app. If possible, just make a static version hosted on a separate server or s3. If you canât make it into static, then a 2nd meteor app that only serves marketing purposes might be a way to go, so your marketing page would become a microservice of sorts.
There are numerous things you can do to optimize your app, but weâd need more info to actually point to the problem. E.g whatâs your initial payload size as a new user, how are you serving image files, how is the infrastructure implemented, etc.
It may be a solution to balance distribute assets in server and client. We have some images over size 1.5mB then we compress them to 300K.
Shouldnât it technically be possible to move files over to the public folder to manually split/load scripts and css? I know, this is a messy solution but probably the only one that would work for load optimizations.
Man, you should never make landing page as same meteor instance with your app IMO.
Landing page is usually full of contents and animations that are never further used in your app.
You should dfntly optimize your app. Another meteor instance is quite common practice for things like landing page, admin panel, business-boards and ect. Simple non-meteor instance fine too, but first way allows you to configure DDP, so if you need any of your data on your landing page, it will be easy to get it.
So you wrote your code in a single file instead of spreading the templates and names in different folder?
No, Meteor makes it for you. Try meteor run --production and youâll see how your app looks in production. Meteor is smart enought to glue and minify all the sources
Finally, our best solution was:
meteor add standard-minifiers ecmascript ecmascript-runtime
and after that, run meteor as this:
meteor --production run
This implies packaging , compressing and obfuscating CSS + JS code in to a single .gz (you can see the difference in âview sourceâ browser option). Network loading time improves dramatically (from 30 seconds to 2 seconds).
Using meteor build with old nodejs v0.10.40 and running as a binary NodeJS application helps eating less server resources.
Yeah but I have like 327 files in meteor for js and template. how do I lazy load them to make it quick?
Tried your suggestion, got following message:
=> Errors while adding packages:
While selecting package versions:
error: unknown package: isobuild:compiler-plugin
Required by: ecmascript 0.1.3-plugins.1
Required by: ecmascript 0.1.3-plugins.1
unknown package: isobuild:minifier-plugin
Required by: standard-minifiers 1.0.2
I am using Meteor 1.1.0.2.
Correct me if I was wrong, your approach is to build single gz file, and use nodejs v0.10.40 to run this Meteor Application, right ?
Josh, that chrome extension is a great tip! I was looking through it and was shocked that I load 7.5 MB just from packages alone. Worst is jQuery with 1.2 MB in that package alone.
Any tips on how I could reduce this amount of data?
Is that solved now with the 1.3 update?
We usually have the useraccounts package on the landing page as well, unless you want to direct the user to a specific URL away from the landing page to keep it small and clean.
Any suggestion on the useraccount problem?
Not really, no. . . .
Have you moved files that you donât want to be eagerly loaded into an imports folder.
Files in a directory named imports/ will no longer load eagerly. (You should probably rename such a directory as it the basis of our new module system).
1.3 Breaking Changes
I donât have a large Meteor app that I can test how this will affect performance.
Iâd be interested to see how the lazy loading of imports correlates to site performance.