我想分页结果，每次最多显示10个结果。
我的疑问是：每一次转动页面是否发出不同的请求，或只提出一个请求来获取所有帖子，然后通过javascript(响应是我的JSON)来管理分页是很好的吗？
做出更多的频繁的小要求，轻的反应或一个大的更好吗？
我想，在现场生活的开始，第一个解决方案是最好的解决方案。随着网站的增长，我不确定可扩展性。
你怎么看？
更新：我收到了几个非常好的答案，有更多的用户界面方面的问题。
Hwr我希望你更多地关注性能的观点。我的网站是在一个共享的服务器上，但是我们预计流量会快速上升，因为该网站将获得国际曝光。
我的恐惧是，wordpress将无法应对来自ajax请求的增加的开销。
所以回到这个问题，对服务器的总负载，许多小的请求，只加载请求的结果页面或者一个大的结果是什么会更好？
考虑到并非我所有的用户都会检查所有的结果页面，我想第一个…
如果您正在处理已知数量(每页10个结果，10页结果)，并且您希望所有这些都可以提供给用户，asap，那么我建议在500ms下载块(10或20)定时器或类似的东西。
然后，您可以异步填写额外的后台，并相应地更新“总页面”控件。
从那里，您的用户立即得到结果，并且能够在2秒钟之间在所有数据之间来回跳转。
如果您有一个网站，您需要立即访问所有数据，并且您有40个结果需要显示，那么请转到大转储。
如果你有一个无限滚动网站，那么你想要抓住几页的长度。对于像Twitter这样的事情，我可能会预先计算容器的平均高度，而不是屏幕高度。然后我会下载3或4个屏幕长度的推文。
从那里，当用户滚动到他们的第二或第三屏幕(或分别第3或第4)时，我会下载下一批。
所以我的事件可能被附加到一个onscroll，它检查它是否被允许运行(如果它是上次运行至少16ms，显然，我们仍然在滚动)，那么它将检查它在哪里，关于底部的距离，考虑屏幕高度和最后一个批次的总高度(screen_bottom> = latest_batch.height * 0.75)或类似的。 screen_bottom将相对于last_batch，因为如果用户正在向上滚动，高于上一批次，则screen_bottom将完全为负数。
…或规范化，以便您只是处理百分比。
这样就足够让你感觉到数据总是在那里。
你不想在开始时等待一个巨大的块加载，但是你也不想等待小块加载，而你也想要移动。
因此，根据您所做的工作，以及您期望用户使用数据的方式，找出快乐的媒介。