AJAX request considerations

What's this "AJAX" you speak of?

For non-developers, AJAX stands for "Asynchronous JavaScript and XML", and basically means a way of updating a webpage, e.g. in response to a user clicking something, without having to reload the entire page as was common in the earlier days of the internet.

Appearance vs Performance

When loading any page on your site, pay attention to how many AJAX calls are being made to the server (especially for code that executes on every page). Each call incurs network overhead and increases server load, alongside slowing down the delivery of content to the user.

It iscan be better - or worse, depending on the specific use case in question, to have the minimum number of requests necessary to get the data you need, rather than having them split upup. -There whichare cana resultlot of considerations to bear in mind when deciding how to approach this for a kindgiven page.

Advantages of inneramalgamating conflictAJAX where code design is concerned.

Design vs performance considerations

requests

Suppose a page has the following 5 AJAX requests that are fired on every page load when a user is logged in:

• Load unread message count
• Load unread notification count
• Load first X unread messages
• Load first X unread notifications
• Load user information

From a code maintenance perspective, it's often good to have functions separated out like this, so that if one breaks the others are not also broken. The problem is that, from a performance and networking perspective, the client is making 5 requests to the server when only one was needed. This means two things:

More server requests = higher server load

Not that this should come as any surprise, but having lots of AJAX requests constantly bombarding your servers puts them under a lot of pressure, due to the increased network and request overhead.

Race conditions on page load

In certain cases, your AJAX requests are going to be updating the page when they receive a response (for instance, to show the unread message count). While for some functions that doesn't matter, for others that change the page layout or add elements to a page, it can make for a "janky" looking page - because it doesn't load consistently, owing to the fact that which order they will execute in depends on which AJAX requests finish first, and that isn't always going to be the same order.

Downsides

Disadvantages to amalgamating AJAX requests

While getting your data in as few AJAX requests as possible reduces server load, there is a potential problem with this approach as well. 

On pages where you want data to be loaded in an "as it becomes available" fashion, having everything be retrieved in one AJAX request can make for an awkward-looking frontend: the page is empty of content, and then suddenly full of content, but nothing in between. This can result in a page that looks like it takes long to load, or an uncomfortable "jerking" of the page when a load of content all appears at once.

It also has the effect of making pages feel uninteractive and unresponsive; a page that loads a few things as they become available looks as if it is "working in the background", e.g. when a user's private message or notification counts appear.

Considering cases where you might want to avoid AJAX for some specific data

In certain cases, you might even want to consider not using AJAX to load a particular piece of content, and instead render it on the backend before sending it to the user. Functionally, this doesn't change the load time - it's shifted from the user waiting for the page element to load (with AJAX) to the user waiting for the server to send them the page at all (non AJAX).

This approach can have some advantages, when for example populating website elements where you can't be sure how big the element will be, and you don't want the page to move around a lot as it loads.