Paging in multi-user environments where data can change between requests for pages is tricky at best, pointless at worst.
Say your first request got you a page of 10 items out of a total of 100. Now you do another request for the second page of 10 items, but the number of items has changed to 101, with the new item existing in what would be the first page.
Now what do you return? The request was no doubt intended for 10 records not yet retrieved, but should that new record be returned or not? In other words, should we return records 12-21, 12-20 + the new record, 10 records starting at the new record, records 11-20, or what?
Applications like Twitter handle it by just returning the X most recent data points and allowing users to retrieve more at either end as desired, but their data is structured such that no data will fit within an interval already retrieved (or if it does, like when following someone new who's posted in that interval) they simply ignore it.
If your application can retrieve data based on custom filters and ordering sequences this is of course not an option, and the problems I described start rearing their ugly head.
In those cases, a hybrid solution where you select a broad chunk of data using only filters that won't cause a situation where new data can enter the chunk, then filtering and sorting further on the client is often the best solution.
Overall then, there is no best way. It depends greatly on your data, your presentation requirements for it, and the acceptable network load (returning larger data volumes of course means higher network load) and security requirements (in some domains, returning more than the absolute minimum data to the client is considered a security risk).