I am writing a bachelor thesis, which broaches the issue of improving a browser game’s performance using Meteor Framework. For this I am collecting all kinds of performance best practices for web sites in general and I am trying to figure out which work good/best with Meteor.
In the book “even faster web sites” by Steve Souders I read about the “Early Buffer Flushing” method. At first I thought is it totally irrelevant for Meteor because PHP is used to achieve its benefits. However the book mentions, that “other frameworks” that don’t rely on PHP probably, also might have a way to realize this chunked encoding with a function somehow similar to “flush”.
A second thought was: Maybe that is somehow the same as what is being achieved using Fast Render, but I have my doubts, whether this is correct. As I understood it, Fast Render puts aside the waiting time for the database contents to faster render a first viewable content for the user. But using chunked encoding and flush it should be possible to load site contents while the html is being constructed.
Is this method not viable for Meteor because of the way the html is being stitched together? Or are there other reasons that disfavour this approach?
This sort of optimisation is not really applicable to Meteor at the moment since all of the HTML generation is done client side, the actual html that is sent is very small, just the head tags with links to the javascript that will actually build the page.
Its possible that when Meteor gets server side rendering this will become useful, but even then it will only apply to the initial page load, after that ever page is rendered client side anyway (compared to php where pages are all generated on the server).
Fast render and flush are trying to achieve the same goals in that they try and reduce the initial page load time. But fast render does this by sending more data to begin with rather than chunking the data. This works because when the initial request is sent to Meteor, usually it only send the html which then triggers the browser to download the actual js app and run it which then contacts the server and downloads the actual data. By sending the data along with the initial request it allows you to render a complete page instead of waiting for the client side database to be populated.
In terms of areas applicable to your research I would suggest looking at the DDP protocol that MDG developed and how it reduces the amount of data being send between the server and client.
This explanation makes sense, the different approaches of both methods are clear to me now. I figured that this will only ever improve the initial page load, which is of less importance for a Meteor App but still relevant.