更好的许多小型ajax请求或一个大的全球网站性能？

Question

我有一个带有ajax搜索字段的wordpress网站，它返回一个帖子列表，只包含标题，网址，日期和类别。

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

我的疑问是：在页面翻转的每一个回合中提出不同的请求是好还是只提出一个请求来获取所有帖子然后通过javascript管理分页（响应是我的JSON）？

通过轻微响应或大响应来制作更频繁的小型请求会更好吗？

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

您怎么看？

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

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

回到这个问题，对于服务器总负载，许多小请求，仅加载请求的结果页面还是加载具有所有结果的大页面，它会有什么好处？

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

Answer 1

正确的答案是：“这取决于”。

如果您正在处理已知数量（每页10个结果，10页结果），并且您希望所有这些数据都可供用户使用，那么我建议下载数据块（10或20）在一个500毫秒的计时器或类似的东西。

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

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

如果您的网站需要立即访问所有数据，并且您需要显示40个结果，那么请使用大转储。

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

所以我的事件可能附加到onscroll上，它会检查是否允许它运行（如果它自上次运行以来至少已经运行了16ms， - 显然，我们仍在滚动），那么它将检查考虑到屏幕高度，以及最后一批（screen_bottom >= latest_batch.height * 0.75）或类似的总高度，它与底部的接近程度如何。 screen_bottom将相对于last_batch，因为如果用户向上滚动，高于上一批，则screen_bottom将完全为负数。

...或将它们标准化，以便您只处理百分比。

这足以让您觉得数据始终适合您。 你不想在开始时等待一个巨大的块加载，但你不想等待小块加载，而你也试图四处移动。

根据您正在做的事情，以及您希望用户如何使用您的数据，弄清楚什么是快乐的媒介。

Answer 2

在此决策中有两个因素起作用：用户如何与您的网站互动（例如，他们查看了多少结果以及他们如何查询）以及“平均搜索结果”有多大。如果您有数以千计的帖子和通用搜索字词，那么如果您走“大一号”的道路，您可能会获得非常大的结果集。如果您的用户倾向于对此进行大量浏览，那么如果您在每次加载页面时发出请求，则会产生大量请求。

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

Answer 3

嗯，首先。如果您的AJAX正在创建相同的帖子查询，则会创建正常的页面加载，您可以模拟页面加载。即，查询一堆帖子（如包含大量帖子的页面），将所有数据发送到JS，并让它处理分页。

当然，您无法一次发送所有帖子，因此您必须处理可用的页数。因此，我认为最好只查询一次页面数量的帖子。请记住，正常的WP行为是创建一个返回帖子ID的查询，然后查询页面中每个帖子的整个帖子。

如果您想要优化您的网站，请安装缓存插件。它将在HD中缓存所有数据库查询，然后使用这些文件重新进行相同的查询。

Answer 4

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

大上传不好

正如您在上面的屏幕截图中所看到的，您上传了许多字节，只下载了几个字节。

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

Answer 5

我遇到了类似的情况。我无权访问服务器，必须将Excel中的文件以.xlsb格式保存在Sharepoint上（我可以获得的最小文件大小）。我使用自定义二进制ajaxTransport将它们作为arrayBuffers带回，然后使用threadsJS处理各个线程上的缓冲区，以通过SheetsJS获得可用的JSON数据，然后将它们合并为一个JSON数据数组。

根据我的测试，单个大文件需要41秒才能完成处理，4个较小的文件需要28秒，8个甚至更小的文件也需要20秒，然后16个甚至更小的文件仍然需要20秒...

因此，随着文件变得更小，返回的收益会减少，其中AJAX请求数量的增加抵消了更快的文件处理时间。老实说，我发现使用线程或不使用线程之间没有实际的速度提高，这可能是因为AJAX调用的异步特性允许在调用开始和结束之间进行处理，或者可能是因为我没有他们做了足够多的工作，看到了很大的不同，但是线程版本允许我的页面加载器在数据加载时不冻结，所以我认为这是一个加分。