对于全局站点性能来说，多个小ajax请求还是多个大ajax请求更好？

我有一个wordpress站点，它有一个ajax搜索字段，返回一个帖子列表，只有标题、url、日期和类别

我想对结果进行分页，以便每次最多显示10个结果

我的疑问是：每次翻页都提出不同的请求，还是只提出一个请求来获取所有帖子，然后通过javascript管理分页（响应是JSON）

更频繁地提出一个小请求，并给出一个轻松的响应，还是一个大请求

我认为在站点生命周期开始时，第一个解决方案是最好的。随着网站的发展，我不确定其可扩展性

你觉得怎么样

更新：我收到了两个非常好的答案，解决了更多用户界面方面的问题

Hwr我希望您更多地关注性能的观点。我的网站在一个共享服务器上，但我们预计流量会快速增长，因为该网站将获得国际曝光。 我担心wordpress将无法应对ajax请求所增加的开销

那么回到问题上来，对于服务器总负载，许多小请求，只加载请求的结果页面，还是加载一个包含所有结果的大页面，有什么更好的方法呢

---

考虑到并非所有的用户都会检查所有的结果页面，我认为第一个…

在这个决定中有两个因素起作用：用户如何与您的站点交互（例如，他们查看多少结果以及如何查询结果）以及“平均搜索结果”有多大。如果你有成千上万的帖子和通用搜索词，如果你走“大一”之路，你可能会得到非常大的结果集。如果您的用户倾向于浏览大量内容，那么如果您在每次加载页面时都发出请求，则会导致大量请求

没有一般的答案，这在很大程度上取决于您的应用程序和用户的搜索模式。一般来说，我会做最简单的事情来完成这项工作，但也会监控页面上的用户交互（例如记录查询和结果大小）、网站性能（例如通过Google Analytics加载时间）和服务器负载（例如通过munin）。如果您遇到问题，您仍然可以从现在开始优化您的应用程序-到那时，您将对您的用户和应用程序有更好的了解。

正确答案是：“视情况而定”

如果您处理的是已知数量（每页10个结果，10页结果），并且您希望尽快将所有结果提供给用户，那么我建议使用500毫秒计时器或类似工具下载块（10或20）

然后，您可以异步填充额外的后台页面，并相应地更新“总页面”控件

从那里，您的用户可以立即获得结果，并且能够在2秒钟内在所有数据之间来回切换

如果你有一个需要立即访问所有数据的站点，并且有40个结果需要显示，那么就进行一个大的转储

如果你有一个无限滚动的网站，那么你会想要抓取一些页面长度。对于像Twitter这样的东西，我可能会预先计算容器的平均高度和屏幕高度。然后我会下载3到4个屏幕长度的tweet。 从那里，当用户滚动到第二或第三个屏幕（或分别为第三或第四个屏幕）时，我将下载下一批

因此，我的事件可能会附加到onscroll上，它会检查是否允许运行（如果上次运行至少16毫秒，显然，我们仍在滚动），然后它会根据屏幕高度和最后一批的总高度检查它在哪里，它离底部有多近（

screen\u bottom>=最新的\u batch.height*0.75

）或类似内容。屏幕\u bottom将与最后一个\u批次相对，如果用户向上滚动，则屏幕\u bottom将完全为负数

…或者将它们标准化，这样你就只需要处理百分比

这足以让你感觉数据总是在那里。 你不想在一开始就等待一个大的块加载，但你也不想在你试图四处移动时等待一个小的块加载

---

因此，根据你正在做的事情，以及你希望用户如何使用你的数据，找出快乐的媒介是什么。

首先，如果你的AJAX创建的帖子与普通页面加载创建的帖子相同，你可以模拟页面加载。例如，查询一堆帖子（比如一个包含大量帖子的页面），将其所有数据发送到JS，并让它处理分页

当然，你不能一次发送所有的帖子，所以你必须处理有多少页面可用。正因为如此，我认为最好一次只查询一个页面的帖子数量。记住，正常的WP行为是查询返回帖子ID，然后为页面中的每个帖子查询整个帖子

如果你想优化你的站点，那么安装一个缓存插件。它将缓存所有的数据库查询，然后使用这些文件，避免再次进行相同的查询。

我是的创建者，发现下载速度快得多，但由于设备的上传速度，请求资源的速度慢

大上传是不好的

正如您在上面的屏幕截图中所看到的，您上传了很多字节，而下载了很少的字节

---

通常下载速度比上传速度快。

我遇到了类似的情况。我没有访问服务器的权限，必须从Excel（我能得到的最小文件大小）以.xlsb格式将文件保存在Sharepoint上。我使用自定义二进制ajaxTransport将它们作为arrayBuffers和t返回