Speed up Auto-reload in Meteor.js

Question

After saving a file with new changes in Meteor.js, the server will restart and the browser will window reload.

Question: Sometimes it takes longer than usual to reload after saving the file, and this appears to be random. Is there a way to trigger the auto-reload more quickly?

It appears that the server restart quickly, but the browser reload much more slowely.

After the Meteor server have restarted, the webpage becomes unresponsive for 30 sec and the Network tab shows websocket pending...

I'm using Meteor 0.7.0.1 with Meteorite 0.6.16 on Node.js v0.10.22 on Mac OSX, connecting to a remote MongoDB server.

Sammiesammons

Is it possible that the times it takes longer time to reload are when you have ran code that's crashed? – Hemia

@PeppeL-G It also takes longer to reload when the code is working fine... I've estimated the range of browser reload times from 3 sec to 10 sec. – Sammiesammons

Answer 1

The auto reload takes time if your project is big. Meteor basically has to rebuild the javascript up. There are a lot of things that can influence the time it takes.

Some basics of it are:

• The bigger the project & more js files/packages the longer it would take
• If you've disabled websockets the server will appear to take longer to restart
• If you're using --production as a flag it will take longer to rebuild but faster to load in the browser
• If you use external css/fonts via cdn and stuff it can take a bit longer sometimes to redownload these files, it depends on your connection. Try checking your Network tab in the chrome developer console to see if there is any particular file taking a while and temporarily host it locally instead.
• If you're hotcode reloading after an error there could be slight delays as meteor tries to recover from the error.

There are a couple of other things too. If you're using Meteor UI with the --release flag some builds have memory leaks and get slower and slower the more you hot code reload.

If you're developing on windows there are a few issues with hot code reloads. Meteor on windows is unofficial and you sometimes have to ctrl+c and restart it to get it to boot faster.

There isn't alot that you can do to speed it up besides beefing up your computer up or moving stuff run in Meteor.startup into a cron job. Every hot code reload would redo the tasks in your Meteor.startup.

The one that bothers me the most with hot code reloads is the fonts from Google fonts via the @import css statements. Sometimes google doesn't serve the fonts very quickly especially when I keep reloading them. I temporarily disable them/host them locally. I don't host locally in production because different browsers sometimes serve up fuzzy fonts on windows.

Hydrogeology

After the meteor server has restarted, the browser showing the meteor.js webpage will also become unresponsive for about 30 sec before doing the reload... is this normal? – Sammiesammons

Could you try keeping your debug console open when doing a hot code reload and seeing if something stays 'pending' on the Network tab? It sounds like something from a cdn thats taking too long to serve. Its definitely not normal but if it only happens on the browser it might be something external. – Hydrogeology

Updated original post with a screencap of the Network tab where the browser becomes unresponsive after the Meteor server restarts and before the page reloads. – Sammiesammons

The websocket is usually pending as its streamed, are you using Meteor 0.7? could you add Meteor.onConnection(function() {console.log("ready")}) to your server side code and see if it takes overly long to say 'ready'? Also if you scroll up do you have any other files which are pending/red (errored) out? – Hydrogeology

After the server restarts, Ready instantly appear twice, followed by >>> SmartCollection charged with MongoDB Oplog. The third Ready takes 30 more seconds to appear. The browser than reloads. – Sammiesammons

In the browser console, there are only 2 websocket pending, nothing in red. – Sammiesammons

Thats a bit confusing you only have one browser window open? There's supposed to be one 'ready' per browser window & only one websocket per browser window too I'm a bit perplexed why there would be two websocket connections. What packages are you using? If you use a local mongodb server does it behave this way? So the issue is definately something with the server side if its behaving this way. Perhaps its because its trying to use the oplog with the remote mongodb it might be a meteor bug with remote databases – Hydrogeology

Sorry I had a page open on the Mac, and a page opened on a Windows. After closing the page on the Mac, now there's a total of 2 Ready, one appears when the server restarts, the second one appears 30 seconds later. – Sammiesammons

Using a local empty mongodb server (without defining MONGO_URL and OPLOG_URL), the problem goes away! – Sammiesammons

I'm stumped the last thing I could think of is it might be that setting MONGO_URL to a remote db while using meteor run also sets the oplog to the local database and it behaves this way. This would make it a meteor bug with setting MONGO_URL, its a bit new since meteor 0.7 tries to use the oplog – Hydrogeology

I'm still using SmartCollection from the smart-collections package instead of 0.7's new Collection because I think Meteor's Collection cant do sort and limit yet? – Sammiesammons

Aaah ok I was wondering why the env variable was OPLOG_URL instead of MONGO_OPLOG_URL. Did you run mrt update as well as meteor update when you updated to 0.7 to get the newer smart collection package? Beyond that I think it would be a bug in smart collections – Hydrogeology

Yup I ran mrt update again and restarted the server but the same 30 sec delay persists. smart-collections is at v0.4.0. Thanks for the help troubleshooting! – Sammiesammons

Cool but its not solved! one last thing is your mongodb part of a replica set? – Hydrogeology

The remote mongodb server is the only one in the replica set meteor – Sammiesammons

After the first ready appears, manually reloading the browser before it becomes unresponsive allows a quick reload with no problems. The second ready message appears on the server console instantly. Maybe the problem is not with Meteor and Oplog? – Sammiesammons

+1 for the tip to run the app with meteor --production - this minifies the JS and CSS to one big file (and no *.maps!). This reduced uncached loading time of my Meteor app from 5.6 sec to 1.5 sec! Thx man! – Vishnu

Answer 2

I revived an old project which had been running fine in 2014 with a fresh install of meteor, but found startup and restarts were really slow (over 30 seconds). (Possibly updating node or meteor had triggered this.)

I noticed that the project's .meteor/release contained [email protected]

I ran:

meteor update

in the project's root folder.

My release file now contains [email protected], and many of my packages were updated. Now restarts are significantly faster (about 10 seconds)!

---

By the way, I point MONGO_URL at the mongodb on my localhost, so meteor doesn't have to spin up a new mongodb when I start the app.

Wive

Apologies, my answer noted a speed up in server restarts, but the question was actually about slow browser refresh. – Wive

Answer 3

Seems to be solved with 1.3, but for now it is in beta.

meteor update --release [email protected]

From 6-10s to 1-2s.

Plagiary