First Visit Loads are Ridiculously Slow

Ever since one of the last few new versions of Meteor.JS, my application is ridiculously slow for first time visitors. I’m talking 10 to 20+ seconds for first time loads.

However after I visit the application, all loads are fast and normal, even if I hit the refresh button. But once I clear cache and refresh again, first load is ridiculously slow again.

Why is this happening? And what can I do to improve the first visit load time?

6 Likes

Add fast render. It will send the data that you need on first render and make your views faster overall. Also, remove autopublish if you haven’t. If you have done both of these things then you will have to fix your publications.

1 Like

Sounds like your application is getting large.

Meteor is a javascript application that is downloaded by the client browser when the user accesses the site.

So if your app is 5mb, you need to download a 5mb app on your first visit.

Once you reach this point you want to start looking at things like where you are serving static content from, such as from a CDN.

The there is time until the first render which can be improved using various techniques. Server side rendering is probably the best solution, but requires quite a bit of overhead at the moment. Next in line is Fast Render, which injects data into the initial http request, this will improve speed because the application can be rendered without waiting for publications.

You still have to download that initial javascript application though. You can’t really get around that, but you can make your app feel a lot faster by adding a css3 preloader. You do this by injecting css and html that makes a loading animation into the initial request, which can be shown while the js application is downloading.

5 Likes

I have about 5+ MB of Static images in my app’s public folder. Would this slow the application? My assumption is no, right?

Also I noticed recently that when I added Cordova to my application, it increased the size of my .meteor folder to about 2 GB+. Uninstalling Cordova didn’t get rid of those files so I literally had to recreate my app and reinstall every package to finally get rid of it.

I’m wondering if the Cordova files are still in the server. But I can’t find where in my server the files are located. If I use “mup deploy”, where would my Meteor files be?

I just checked my application files. Minus the .meteor folder and the public folder, my application is only about 1.25 MB. That doesn’t sound like it would take 20 seconds to load.

Also when I observe the application, after I visit the URL, the page is blank (white) and in the source I can see the Meteor code. So clearly this isn’t anything to do with server response.

1 Like

Meteor serves static assets very poorly. Move the images to S3 and that should increase performance by at least a little bit.

2 Likes

Thanks. I didn’t know.

If that’s the case, what do you use the public folder for? I kind of don’t see the point of a public folder if I shouldn’t put images in it. What do you put in it?

I don’t think anyone has answered your question yet. Can you link to your app so we can test how it loads? What does the Chrome inspector Network tab show you?

Files in the public folder are publicly accessible and can be linked to. They don’t automatically load when the page loads unless you link to them.

Where are you hosting your app?

3 Likes

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.

1 Like

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…

1 Like

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)

2 Likes

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.

4 Likes

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/.

14 Likes

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:

1 Like

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

5 Likes

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.

1 Like