更好的许多小ajax请求还是一个大的全局站点性能？
我有一个带有 ajax 搜索字段的 wordpress 站点，它返回一个帖子列表，只有标题、网址、日期和类别。
我想对结果进行分页，以便每次最多显示 10 个结果。
我的疑问是：是每次翻页都发出不同的请求，还是只发出一个请求来获取所有帖子，然后通过 javascript 管理分页（响应是JSON）？
使用轻响应或大响应更频繁地提出小请求更好吗？
我想在网站生命的开始时，第一个解决方案是最好的。 随着网站的发展，我不确定可扩展性。
你怎么认为？
更新：我收到了几个非常好的答案，其中解决了更多用户界面方面的问题。
Hwr 我希望你更多地关注性能的观点。 我的网站在共享服务器上，但我们预计流量会快速上升，因为该网站将获得国际曝光。 我担心 wordpress 将无法应对来自 ajax 请求的增加的开销。
那么回到这个问题，对于服务器总负载，许多小请求，仅加载请求的结果页面还是包含所有结果的大页面，哪个更好？
解决方案
正确答案是：“视情况而定”。
如果您正在处理已知数量（每页 10 个结果，10 页结果），并且您希望所有这些都尽快提供给用户，那么我建议在 500 毫秒内下载块（10 或 20）计时器或类似的东西。
然后您可以异步填充额外的后台页面，并相应地更新“总页数”控件。
从那里，您的用户可以立即获得结果，并且能够在 2 秒内在您的所有数据之间来回切换。
如果您有一个网站，您需要立即访问所有数据，并且需要显示 40 个结果，那么请进行大转储。
如果您有一个无限滚动的站点，那么您会想要获取几个页面长度。 对于像 Twitter 这样的东西，我可能会预先计算容器的平均高度与屏幕高度。 然后我会下载 3 或 4 个屏幕长度的推文。 从那里，当用户滚动到他们的第二个或第三个屏幕（或分别为第三个或第四个）时，我会下载下一批。
所以我的事件可能附加到一个 onscroll，它检查它是否允许运行（如果它自上次运行以来已经至少 16 毫秒，–显然，我们仍在滚动），然后它会检查它在哪里，就它与底部的接近程度而言，考虑屏幕高度和最后一批的总高度（ screen_bottom >= latest_batch.height * 0.75 ）或类似的。 screen_bottom 将相对于 last_batch，因为如果用户向上滚动，高于前一个批次，则 screen_bottom 将完全是一个负数。
…或将它们标准化，以便您只处理百分比。
这足以让您感觉数据始终在您身边。 你不想在开始时等待一个巨大的块加载，但你也不想在你试图移动时等待小块加载。
因此，根据您正在做什么以及您希望用户如何使用您的数据，找出快乐的媒介是什么。
有两个因素会影响这个决定：用户如何与您的网站互动（例如，他们查看了多少结果以及他们如何查询）以及“平均搜索结果”有多大。 如果您有数以千计的帖子和通用搜索词，如果您走“大一号”之路，您可能会得到非常大的结果集。 如果您的用户倾向于为此浏览大量内容，那么如果您在每个页面加载时都发出请求，这将导致大量请求。
没有通用的答案，这在很大程度上取决于您的应用程序和用户的搜索模式。 一般来说，我会做最简单的事情，但也会监控用户交互（例如查询和结果大小的日志记录）、站点性能（例如通过 Google Analytics 加载时间）和服务器负载（例如通过 munin ) 在您的页面上。 如果您遇到问题，从现在开始您仍然可以优化您的应用程序 – 届时您将对您的用户和您的应用程序有更好的了解。
嗯，首先。 如果您的 AJAX 正在创建与普通页面加载创建的相同的帖子查询，您可以模拟页面加载。 即，查询一堆帖子（例如一个有很多帖子的页面），将它们的所有数据发送到您的 JS，并让它处理分页。
当然，您不能一次发送所有帖子，因此您必须处理可用页面的数量。 正因为如此，我认为最好一次只查询一个页面价值的帖子数量。 请记住，正常的 WP 行为是进行一个返回帖子 ID 的查询，然后为页面中的每个帖子查询整个帖子。
如果您真的想优化您的网站，请安装缓存插件。 它将在 HD 中缓存所有数据库查询，然后使用这些文件而不是再次进行相同的查询。
我是asjst的创建者，发现***要快得多，但由于设备的上传速度，资源请求速度很慢。
大上传不好
正如您在上面的屏幕截图中所看到的，您上传了很多字节，而下载了几个字节。
通常***比上传速度快。
我遇到了类似的情况。 我无权访问服务器，必须从 Excel 中以 .xl*** 格式将文件保存在 Sharepoint 上（我可以获得的最小文件大小）。 我使用自定义二进制 ajaxTransport 将它们作为 arrayBuffers 带回来，然后使用 threadJS 处理各个线程上的缓冲区，以通过 SheetsJS 获取可用的 JSON 数据，然后将它们合并为单个 JSON 数据数组。
从我的测试来看，处理一个大文件需要 41 秒，4 个小文件需要 28 秒，8 个更小的文件需要大约 20 秒，然后 16 个更小的文件仍然需要大约 20 秒……
因此，随着文件变小，AJAX 请求数量的增加抵消了更快的文件处理时间，从而导致收益递减。 老实说，我看不到使用线程或不使用线程之间的实际速度增加，可能是因为 AJAX 调用的异步性质允许在调用开始和完成之间进行处理，或者可能是因为我没有做了足够多的工作可以看到很大的不同，但是线程版本允许我的页面加载器在加载数据时不会冻结，所以我想这是一个加分项。
你可能还喜欢下面这些文章
WordPress 用户角色
每个用户在WordPress中都有自己的角色。角色类似于授予特定用户访问WordPress网站的权限。管理员可以在WordPress网站上做任何事情，例如创建更多管理员，邀请更多用户并删除它们。
WordPress 写作设置
这些设置控制添加和编辑帖子，页面和帖子类型中的功能，以及可选功能，如远程发布，通过电子邮件发布和更新服务。此选项使用电子邮件地址创建帖子并通过电子邮件在您的博客上发布帖子。要创建帖子，WordPress将需要自己的电子邮件帐户。
WordPress 阅读设置
在本章中，我们将研究WordPress中的Reading。您可以设置要在主页上显示的帖子数。点击WordPress中的Settings。您可以从下拉列表中选择要在首页上显示的实际页面。
如何禁止WordPress头部加载s.w.org
href='//s.w.org'>WordPress在头部添加dns-prefetch，应该是为了从s.w.org预获取表情和头像，目的是提高网页加载速度。
Wordpress REST API 响应慢如何解决
非常新，功能非常强大，您应该在响应时间不成问题的大多数情况下使用。//wordpress.org/plugins/wp-rest-cache/这是一个非常省时的插件，并在我们的实时网站上进行了测试。
PHP Warning: POST Content-Length of 8978294 bytes exceeds the limit of 8388608 bytes in Unknown on line 0
你可以从这个路径找到php.ini文件。已经重新启动了您的网络服务器。中找到重新启动您的服务器将有助于它开始工作。文件，然后在文件搜索中使用此代码更改不要忘记重新启动xampp使用。
WordPress 优化
当心黑帽子技巧不要欺骗Google，不要自己陷入麻烦，并通过使用黑帽子技术为您的网站创建问题。有效使用CSS和JavaScript始终将CSS保留在页面的上方，JavaScript位于底部。这里是一个插件，将帮助你得到你的JavaScript
WordPress 加速引擎，一款真正从底层加速 WordPress的插件
加速原理市面上面常规的后台加速插件大概分为两类：合并压缩或者替换js、css等静态资源达到加速页面加载的目的缓存后台数据库查询达到加速的目的其中第一类基本没什么用，文章数量少的时候不需要加速，文章数量一多不会有任何加速效果。