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

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.

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.

Well, first of all. If your AJAX is creating the same posts query a normal pageload creates, you could simulate a pageload. Ie, query a bunch of posts (like a page with a lot of posts), send ALL their data to your JS, and let it handle pagination.

Of course you can't send all your posts at once, so you gotta handle how many pages will be available. Because of that, I rly think it's better to just query a page-worth amount of posts at a time. And remember that normal WP behavior is to make a query that returns posts IDs then make a query for a whole post for each post in the page.

If you rly wanna optimize your site, then install a cache plugin. It will cache in HD all DB queries, then use these files intead of making same queries again.