First Visit Loads are Ridiculously Slow

I’m not upgrading to 1.3 for a while until it’s stable.

“Never change a running system” :wink:

1 Like

I’ve seen solutions where you can use things like jQuery to check for a cookie, one that is set for the root domain. Then your landing page and the app on the same root domain can access the cookie. Just have the landing page check for the cookie and show the appropriate element based on it’s presence, if that makes sense?

1 Like

lazy loading does not refer to lazy fetching, the code is still fetched as one single js file. it only refers to lazy execution of the imported code.

1 Like

I’ve not tested this myself, but perhaps use FlowRouter SSR. You’ll need to convert your homepage to react (if you’re still using blaze), but this obviates the need to have 2 apps – one for your landing pages, and your primary Meteor app.

@sithmaster
I’m facing this exact problem. I am developing a marketplace in meteor. The first time load was so bad I had to do a separate landing page in the private folder and rendering from the server like this:

Router.route 'static_index',
 path: "/"
  where: 'server'
  action: ->
    contents = Assets.getText('index.html')
    this.response.setHeader("Content-Type", "text/html")
    this.response.end(contents)
` 
This create a superfast loading experience for the landing page - but going into the main app is still a very slow experience. This is affecting traction to the site.
So how were you able to achieve a 2 seconds load time. I don't really understand the technique you described. 
I am using meteor up for deployment to an AWS instance.

Has anyone experiemented with server side rendering? Wouldn’t that solve this first-time page load issue?

stop installing so many atmosphere packages

4 Likes

I’ve been taking metrics on initial page load for our production meteor app. I notice that when I run meteor run --production locally, the bundle size is ~800kb. However, when we run meteor build, and then deploy as a Node app, the bundle size is ~2.5MB. Why is this? Is there a --production flag to the meteor build command? This doesn’t seem to be very well documented.

1 Like

We recently did a clear out of our production app and managed to remove quite a few atmosphere packages, replacing them with leaner, more concise npm packages and it made a small difference to our loading times. Granted, our application has always seemed to load very quickly, making your meteor app go on a diet seems to be great way to remove unnecessary fluff.

I think a lot of people are used to just haphazardly adding packages to their apps, forgetting that meteor loads everything up front.

Such is the nature of a thick client.

Also make sure you are enabling on the fly gzip-ing and static gzip through nginx. We realized we weren’t doing this and speed is 4x faster, naturally!

Have you ever run meteor with --production option ?
My app load very fast since change meteor run with --production option
command : # meteor --production run

Note that putting something like <link href="http://fonts.googleapis.com/css?family=Lato:100,300,400" rel="stylesheet"> inside of your can BLOCK the page from further loading. At least it did it with my code…

I experienced load-times of up to 48 seconds - with a totally static meteor-website only rendering some templates. Moving the above line the the bottom of the html (before </body>) helped and now things are working fine again.

I am suffering from the same. Could you please tell how you wipe the server? I have a cluster on Digital Ocean and don’t want to start with a new cluster.

So my app is live at http://settlin.in. The biggest issues for me

  1. Too many scripts - 111 js files to be precise
  2. Too huge scripts: totalling 21mb.
    The top culprits:
    modules.js - 12mb
    app.js - 3mb
    jagi’s astronomy - 1mb
    jquery - 1mb

On opening the js, we can clearly see that the files are not minified, despite the standard-minifiers-js package installed.

Can someone kindly help me with the following questions?
Q1. Is there a way to merge all these files into one?
Q2. How to force minify the files?

How do you deploy? Are the minifier packages still installed?

I deploy through kadirahq:mup. Yes they are installed.
standard-minifier-js v1.2.0.

Can someone help please?

21MB! That’s way too huge a bundle! Apart from ensuring that they’re getting minified, are you sure you have segregated files properly as client and server? i.e. are you sure there are no files in the client bundle that will not be used in the browser? For more details, refer: https://guide.meteor.com/structure.html#special-directories

Yes I have already done that. The structure is more or less derived from the guide:
|____server
|____public
|____node_modules
|____imports
| |____conf
| |____language
| |____startup
| | |____server
| | |____both
| | |____client
| | | |____lib
| | | |____routes
| |____api
| |____client
| | |____pages
| | |____layouts
| | |____components
|____client
|____packages
|____common
| |____imports
| | |____lib
| | |____startup
| | |____api

If you see the non-minified app.js is 3mb only. It is the modules.js that’s huge. I will have to decrease the dependency on external modules.
But currently, the main problem is minification.