AJAX or Not?

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.

  1. Pure Django template
  2. AJAX load table with innerHTML
  3. AJAX load table with AngularJS
Optimization Attempts
  1. Content as inline javascript JSON
  2. Partial server-side, partial AJAX innerHTML
  3. AJAX load table with React
Crazy Hybrids
  1. React with Lovefield local database
  2. React with localStorage local database

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:

  1. Thin client
  2. Half-and-half client
  3. Fat client

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.

Three Different Versions

1. Load it all with the HTML template rendered on the server



2. Load a "skeleton" of HTML. Then asynchronously load in the data, in HTML, with AJAX



3. Use a Javascript framework and load all content with AJAX as JSON



Optimization Attempts

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.

1. Include the bulk data as a JSON string inside the server rendered page



2. Content "below the fold" loaded asynchronously later



Crazy Hybrids

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. E.g. localStorage or IndexedDB
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.

1. Store a local copy in Lovefield and render with React


2. Store a local copy in localStorage and render with React


Discussion, Thoughts, Conclusion

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.