Using Ajax in WordPress: Loading Pages

About a month ago, I wrote a post about single page tabbed navigation in WordPress. In the post, I made the following statement:

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. This particular post is about the best strategies for that (that’s a debate for another post).

And I then I received the following comment:

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

Without context, this is a really broad question and it’s that I don’t think can be answered in a prescriptive way. When you’re trying to paint a solution for web development with broad strokes when each problem is a bit more unique, it’s not easy to provide advice that’s applicable across the board.

But this comment was about a very specific example and a very specific use case.

Using Ajax in WordPress to Load Pages

When thinking through the scenarios in which I think it’s worth using Ajax and when it’s worth loading everything, two factors kept coming to mind:

  1. Weight
  2. Fragments

Gibberish or something, isn’t it? Specifically, I kept think about page weight and page fragments. You’ve likely seen the latter when using Jetpack’s Infinite Scroll feature.

That is, when you reach the bottom of the viewport, WordPress will fetch the next n-number of posts (where n is whatever you have configured) and append them to the content of the current page. I think of these as page fragments: They include content that fit within the broader context of the page they are on, but tend to be loaded on demand.

Ajax Cleaner
This image is basically obligatory at this point, isn’t it?

And they are loaded on demand for a number of reasons one of which is page weight. Most web developers understand that if a page is “heavy” or full of a number of elements that contribute to its weight, then it loads slowly. While the visitor waits for the page to load and the JavaScript to process, they are likely to see a lot of things “flash” on the screen before everything has been kicked off.

Yes, there are some workarounds given CSS, but when you start throwing Ajax, JavaScript, and page weight into the mix, things can get more complicated.

1. Page Weight

Whenever I’m working on a site or application that is going to be using something like single page tabbed navigation and I have to decide whether or not I’m going to load every page from the outset or on demand, I generally weigh the options as to how much a given page will affect the overall page weight.

For example, if I’m loading four or five pages that are most text (with perhaps a couple of images each) and are hidden until a certain tab has been clicked, then I’m likely to go ahead and do it.

The demand that is placed on the request is nominal – think about loading up the homepage of a blog and the, say, seven most recent posts. There’s not much of a difference.

But if I were to be loading an indeterminate amount of pages each of which correspond to some type of UI element or UI event (such as scrolling), then I’ll look to implementing Ajax because I don’t know how much the overall page weight is going to be affected.

2. Page Fragments

And this leads to the concept of page fragments. Obviously, this isn’t any official technical term – some probably refer to them as partials, pieces, or some other term that represents something that’s a smaller part of a larger page. Regardless, you get the idea.

Your page loading via Ajax.
Your page loading via Ajax.

As previously mentioned, you’ve most likely seen this in WordPress whenever someone is using Jetpack’s infinite scroll: You scroll down the page and then when you hit a certain point, a number of additional posts are fetched and then appended to the current page.

When doing this, a limited number of posts are loaded. This keeps performance high and makes sure that just enough is loaded onto a page. Secondly, this is a repeatable behavior such that when the user hits a new point on the page, then even more posts are added to the page.

This is but one practical example.

So When Do I Use Ajax?

I use Ajax when I have what I believe to be an amount of content that’s significant enough that it will negatively impact the page weight if loaded with the initial page.

Yes, there are tools that can help evaluate how this performs but they don’t always do such a hot job of someone loading up your site on a mobile device, a 3G connection, or a slower DSL connection. To that end, you have to use a bit of discretion as to how you’re going to load the page.

Would I use Ajax when using tabbed navigation on a single page? Yes – if the number of tabs were above a certain limit and/or if the pages that corresponded to each tab were heavier than text with a few images. On top of that, are two other ways to load page content via Ajax:

  1. You can load the content after the main page is loaded
  2. You can load the content on demand such as when a tab is clicked

To that end, there’s no general consensus as to the single best way to perform something via Ajax; however, there are certainly times in which it makes more sense to use it than not. It’s up to you to and your particular situation to determine the best course of action.

2 Replies to “Using Ajax in WordPress: Loading Pages”

  1. Thanks for this post, I found it helpful! Would love to see some code snippets of how you are accomplishing the ajax page loading. I’ve found several tutorials online, but nothing really specific to WordPress. I’m going to be tackling it myself this week for a project, so I’m sure I’ll figure out what works and what doesn’t in the context of WordPress, but would love to see how you accomplish it, as I imagine it will be much cleaner than what I come up with.

  2. That’s exactly what I was thinking about recently :) I would add another use case. With my large project I mentioned in a comment in another post of yours, I have some pages which run many complex db queries, mostly selecting, grouping and sorting by meta keys. There’s a page ‘Event’, on that page we have several tabs with different content – event info, photogallery, broadcasts and videos, reports etc which are separate custom post types. Even event general info loads another post type ‘location’ to show a venue information and map. Quering db for this amount of information in one run can be slow, especially when it’s multisite with hundreds of thousands of records. All this content obviously is not required on a first load. Loading these ‘parts’ via ajax only when requested by user makes a big difference.

Leave a Reply

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