On my desktop I am seeing about 6 seconds or so on reload into our #general channel.
I am only noticing 2 or so seconds of JS execution and evaluation.
There is a huge “gap” between the first evaluation (that results in a white screen) to the second evaluation that brings up the content. During the big gap no CPU work appears to be happening, it is all on the network.
In the Network Tab I see a huge number of websocket frames, worst of which is a 157K frame.
Since Web Sockets do not carry any compression AND there are a huge amount of frames sent the huge gap is likely either a result of just too much uncompressed data being sent combined with a bunch of round trips.
Additionally, a bunch of sound assets that should not have been delivered till way later and should be cached properly but are not:
Just wanted to follow up after having got back from Holiday to give a more proper look at this.
This particular frame seems to be a response back with all of the settings.
In the webapp pretty much every single thing is loaded over a websocket. This can lead to great real time communication. But also has the downside of everything coming over a single pipe.
Out of curiosity what is your latency between you there in Australia and your server?
This is definitely a good suggestion. On our Rocket.Chat+ mobile applications we’ve started using more of our rest api’s for increased compression and we hope it will help on high latency situations like 3G, but obviously distant servers it would also potentially help with.
Thoughts?
Ok this one is kind of a no-brainer for us to fix. https://github.com/RocketChat/Rocket.Chat/search?utf8=✓&q=cache-control&type= We’re hard coding these… We should at the very least allow this to be controlled. I honestly don’t imagine people re-uploading the same sound file, emoji etc over and over again. So caching this seems like a no-brainer.
