better many small ajax request or a big one for global site performance?

Question

I have a wordpress site with an ajax search field that returns a list of posts, with just the title, the url, the date and the category.

I want to paginate the results so that max 10 results are shown every time.

My doubt is: is it good to make a different request every turn the page is turned or make only one request to fetch all the posts and then manage the pagination via javascript (the response is i JSON)?

Is it better to make more frequent small request with a light response or a big one?

I suppose that at the beginning of the site life the first solution is the best one. I'm not sure about scalability as the site grows.

What do you think?

UPDATE: I received a couple of very good answer, there were addressing more the user interface side of the problem.

Hwr I would like you to focus more on the performance point of view. My site is on a shared server but we expect traffic to go up fast, since the site will receive international exposure. My fear is that wordpress will not be able to cope with the increased overhead that comes from the ajax requests.

So going back to the question, what would it better for the server total load, many small requests, loading only the requested result page or a big one with all the results?

Considering that not all the user i suppose are going to check all of the results pages i suppose the first...

Answer 1

The correct answer is: "It depends".

If you were dealing with known quantities (10 results per page, 10 pages of results), and you wanted all of them to be made available to the user, asap, then I'd suggest downloading chunks (10 or 20) on a 500ms timer or something similar.

Then you can fill up the extra back-pages asynchronously, and update the "total-pages" controls accordingly.

From there, your user has immediate results, and has the ability to flip back and forth between all of your data in 2-ish seconds.

If you had a site where you needed all of your data accessible right away, and you had 40 results that needed to be shown, then go with a big dump.

If you had an infinite-scroll site, then you'd want to grab a couple of page-lengths. For something like Twitter, I'd probably pre-calculate the average height of the container, versus the screen height. Then I'd download 3 or 4 screen-lengths worth of tweets. From there, when the user was scrolling into their 2nd or 3rd screen (or 3rd or 4th respectively), I'd download the next batch.

So my event might be attached to an onscroll, which checks if it's allowed to run (if it's been at least 16ms since the last time it's run, -- obviously, we're still scrolling), then it will check where it is, in terms of how close it is to the bottom, considering screen-height, and the total height of the last batch (screen_bottom >= latest_batch.height * 0.75) or similar. The screen_bottom would be relative to the last_batch, in that if the user was scrolling back up, higher than the previous batch, screen_bottom would be a negative number, completely.

...or normalize them, so that you're just dealing with percentages.

It's enough to make it feel like the data is always there for you. You don't want to have to wait for a huge block to load at the start, but you don't want to wait for tiny blocks to load, while you're trying to move around, either.

So figure out what the happy medium is, based on what you're doing, and how you expect the user to use your data.

Answer 2

There are two factors that play a role in this decision: how users interact with your site (e.g. how many results they look at and how they query) and how big an "average search result" is. If you have thousands of posts and generic search terms, you will probably get very large result sets if you go the "big-one" road. If your users tend to browse a lot over this, this will result in a lot of requests if you make a request every page load.

There is no general answer, this depends a lot on your application and the search patterns of your users. In general I would do the simplest thing that does the job, but also monitor the user interaction (e.g. logging of queries and result sizes), the site performance (for example via Google Analytics load time) and the server load (for example via munin) on your page. If you run into problems, you can still optimize your application from this point on - and you will have a much better understanding on your users and your application by that time.