Network tab shows nothing for a long time while the view source shows Meteor JS code with fast render.
Then when the app is ready it almost instantaneously shows whole bunch of stuff that has to do with my app all showing 200 OK.
After this initial load, everything is fast, even refreshing.
App is hosted on Digital Ocean, I kind of not want to share my app URL right now.
Perhaps your Digital Ocean instance is asleep and needs to be loaded up in memory before it can respond to web requests?
I really don’t think so… I’m only using 10% of my memory.
Not sure how to check if its asleep. But it’s not like Heroku where they auto-sleep your server… Plus I’m a paid customer.
You could private message a link to your app to some of the people in this thread if you don’t want to share it to the open world. I have found the meteor community to be quite willing to help and I doubt you would find that sharing a link to your app would have any negative effects…
Put a static file into the public folder and then try to access it with direct url. You can make the file over 5 Mb and note a response time via Network Tab. This way you can find how your static resources (js and css sources) are managed with Meteor backend. If its ok, then your problem is about initial data fetch (including Meteor’s service and login subscribtion)
Thanks everyone. Yes the static file was always in public folder.
Turns out it was an issue with MUP.
I think I cancelled the deploy process while the deploy was happening one too many times. I’m not sure exactly what that did but deploying & cancelling mid-deploy too many times caused my initial load to be extremely slow.
When I wiped the server and started completely anew with the same code, everything worked perfectly fine again.
I am glad you solved it. For others that read this thread and wonder about performance, I would recommend checking out the ySlow extension for Chrome or Firefox.
As you can see from the screenshot below (based on https://crater.io), turning on file caching is very important if you are looking for speedy results. That will help second page load.
Another way to speed up first page load would be to move those as many of your static assets to s3 as you can, or at least have something like Nginx serve them up instead of Meteor. Here is a good post that talks about the how of why of using Nginx to serve up some of those files: https://www.yauh.de/do-i-really-need-nginx-with-my-meteornode-js-app/.
I’m using github pages to serve up static files for now, its super convenient til i need a CDN.
I always heard S3 was not that fast or designed for static file serving but many seem to use it …
Amazon S3 supports multi-part uploads to help maximize network throughput and resiliency, and lets you choose the AWS region to store your data close to the end user and minimize network latency. And Amazon S3 is integrated with Amazon CloudFront, a content delivery web service that distributes content to end users with low latency, high data transfer speeds, and no minimum usage commitments.
guess I heard wrong.
There’s a backlogged ticket on the trello board about splitting things up a bit. As an app gets bigger its not just the JS but also all the templates that need to come down… before anything shows up.
note that sticking lots of files in /public/ also causes terrible experience on phonegap apps as ALL the images get re-downloaded every time you do a code push.
you mean on nginx or other front-end? or some type of header to add to tell the client? is there a meteor config option to see things like cache TTL on files?
Aren’t templates JS-files too? In a production I have only one CSS and one JS files comes on client. It is a pretty big app (it is optimized with reusable templates, usage of CDN instead of public folder) and I get just:
Hi,
One more thing that might also help speed up the initial load. I see that you have added cordova to your app recently. Move all your cordova specific resources/templates/helpers to a package and only include them for the cordova architecture. This will reduce your resources sent to the browser. You can also do this for your web view to reduce the resources sent to your cordova app and thus improving mobile speed/performance. See http://docs.meteor.com/#/full/pack_addFiles
Example:
api.use([‘myMobileView.html’,‘myMobileView.js’] ‘web.cordova’); // And all the rest
Regards,
Riaan
Yeah, I mean like Nginx. I am talking about expire headers. If you set an expires header of at least a year, people will have a zippy load experience the next time they hit your site.
I also think moving your initial js and css to a CDN could make a big impact.
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.