Understanding the cost and disadvantages and benefits of loading the bulk data of a web page with AJAX.
Please see this blog post for an overview and introduction.
This site is an experiment with 3 different versions of displaying a bunch of content. Ideally as fast as possible.
Performance is a mix of actual rendering speed (which very much depends on
"quirks" in the browser) and perceived speed.
Generally, you have a choice between generating a blob of HTML on the server and sending that, or using the server just to send a skeleton framework and data in some pure format (e.g. JSON).
This experiment does NOT recommend a particular approach over another. Having these different versions helps to make you aware of the characteristics of performance and what it means when you make a realistic choice in how you develop your site.
We can alternatively call the three versions:
All content (HTML, JSON) is served straight out of memcache, with a tiny
shim of Python in Django to make that happen.
All this code is on GitHub.
If you care about performance, it wouldn't be fair to leave the techniques completely un-optimized. Let's compare some different approaches that are realistic options of optimization.
Here we have examples where we want to experiment. Considering that
generally the objective is to show data to the user as soon as follows,
one pattern is to store the data in the browser's persistent memory.
This has the advantage, that for repeated visits you can draw from something much physically nearer and show that instead of having to wait for the network. Obviously, data gets old in the browser so you'll have to combine this such that you show the "cached" stuff first until the network request has finished.
In these experiments, when you load them the very first time it just populates
the local storage mechanism, whatever that might be, and asks you
to refresh the page. In a production application, you'd want to
"fail gracefully" and be patient that first time and render once the
network request has finished.
Also, in a production application, you probably want to first and foremost display what you have in your local storage mechanism immediately and once the network request finishes, you update the page with the latest and greatest data from the server.
Remember, this is an experimental playground. The point is to get a feel for how fast it can render with various techniques.
IndexedDB) so you can later do more advanced queries and you can do writes without updating one enormous big blob.
localStorageis fast but inefficient if you intend to do many inserts, queries, updates etc on the data.
Clearly, by clicking around on these versions it's apparent that the more HTML you generate on the server the better. In terms of performance.
Websites that are useful and easy to use can be perceived to be faster. A "fat client" web page with fancy features that can load more content/functionality almost instantly is more useful.
If your site has a high bounce rate and you want happy once-in-a-while
visitors, then render as much as you possibly can on the server.
If you expect your users to stick around and perform multiple tasks, pay the upfront cost and go for a fat client.
Everything has a "It depends" label on it.