A few months ago, I published a post that covered how to achieve single page tabbed navigation in WordPress. In the post, I mentioned the following:

In some cases, it may be best to load pages via Ajax, in some cases, it’s better to load things up all in the first page load.

Generally speaking, I stand by this statement. I know Ajax is fun and I know that it’s gotten incredibly easy to implement, but there are times where it makes sense to load all information with the page and times when said loading should be done asynchronously.

In the comments, someone asked:

I am also very interested and awaiting post regarding your take on when to use ajax and when to load it all.

Though this could have been answered in the comments, it seems as if this is an ongoing discussion among those who build things for the web, so I thought I’d take the time to answer it in the form of a post. If nothing else, perhaps it will spark you to share some of your opinions on it, as well.

When Should I Use Ajax?

To be clear, I don’t have a hard and fast rule for this. I know – developer-types like that kind of thinking because it makes it really easy to make decisions, right?

“Under these conditions, we use Ajax, but under these conditions we don’t.”

Sure, there are some conditions that definitely warrant it (like when something needs to be displayed based on some information that’s, say, provided by the user), but others aren’t so clear. Here are two ideas that I use to help guide my on whether or not I should be using Ajax in a given project.

1. Page Weight

I probably should have titled this particular section “fragment weight” or “partial weight” or something like that, but the point is that how heavy a page and/or a piece of page is greatly influences whether or not it’s worth using Ajax.

If you were to place your data on a scale, how much would it weigh?

If you were to place your data on a scale, how much would it weigh?

To be clear, this factor is not one that should be made on its own. I mean, there are plenty of pages out there that are heavy and just because a page is heavy is not an argument all its own for why something should be loaded asynchronously.

Instead, I think of it like this:

If I’m working with a page that has some content that’s hidden and that may never be seen (such as information located on a hidden tab), and the page is already heavy (and thus takes a significant time to load), then I may opt to delay the loading the hidden content until the user requests it.

This lightens up the page and retrieves content only on demand. Then again, I think it’s worth asking how much these hidden pieces of information really cost. That is, is there a significant amount of time saved by not loading it?

Similarly, there are other strategies – such as caching – that are beyond the point of this point. In short, if the data is static and it will only cost a single user a little bit of time to load all of the information so that it hits the cache, is it worth allowing the user to experience that?

I don’t have a clear answer – this is why I’ve said these are general guidelines that I use and not direct principles.

2. It’s About The Data

When it comes to using Ajax, perhaps the overarching question that touches on all of the major points is a question of contextual information.

For example, let’s assume that you’re loading a page and the page has a fixed amount of information. That is, there’s nothing particular interactive or contextually relevant to the data that needs to be loaded, and the information is generally composed of text (along with, perhaps, some lightweight media).

In this case, using Ajax to pull the content at a certain point in the page’s lifecycle or based on a certain event may be over-engineering the problem. That is, if the information is going to be the same for all users and it’s not going to change, then why retrieve it asynchronously?

"Oh really, Scott? It's all about the data?"

“Oh really, Scott? It’s all about the data?”

On the other hand, if the page’s data is largely based on some type of environmental variables or input as provided by the user (such as account information after they’ve initiated a session), then it might make sense. Even then, you have to ask yourself if the information that’s part of the session is dynamic and can be retrieved in the initial trip to the cache or to the database.

If the information changes, it’s not always displayed, and is less likely to be seen with each visit by the user, then perhaps it’s not worth retrieving asynchronously. Then again, if the information is related to, say, the person’s location, where they last visited, information based on their age, their account, or something that’s changed on the side of the server, then perhaps it make sense to load it separately from the rest of the content.

There Are More

Like I said at the beginning, I don’t have a hard and fast rule for this because I don’t think that one can be made; however, these are my general rules – each of which have their own exceptions) for when I opt to use Ajax in my projects and when I don’t.

And it case it isn’t clear, the short answer (which seems appropriate to share here at the end of the post) is: It depends.

Because it does – on a number of things.

And yes, there are more reasons than what’s above and there are probably even better reasons for why you should or you shouldn’t use it throughout your work (and I’m all ears!), but these are mine and they’ve worked pretty well over the past few years.

Category:
Articles

Join the conversation! 1 Comment

  1. This raises something that I might as well ask about: when we’re making an ajax call to WP, the entire framework gets reloaded server-side, right? Or do those special WP ajax calls we have to define somehow do a lightweight load?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.