更好的许多小ajax请求还是一个大的全局站点性能?

更新于 2021年12月26日 wordpress教程

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

更好的许多小ajax请求还是一个大的全局站点性能?

我想对结果进行分页,以便每次最多显示 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 中以 .xlsb 格式将文件保存在 Sharepoint 上(我可以获得的最小文件大小)。 我使用自定义二进制 ajaxTransport 将它们作为 arrayBuffers 带回来,然后使用 threadJS 处理各个线程上的缓冲区,以通过 SheetsJS 获取可用的 JSON 数据,然后将它们合并为单个 JSON 数据数组。

从我的测试来看,处理一个大文件需要 41 秒,4 个小文件需要 28 秒,8 个更小的文件需要大约 20 秒,然后 16 个更小的文件仍然需要大约 20 秒……

因此,随着文件变小,AJAX 请求数量的增加抵消了更快的文件处理时间,从而导致收益递减。 老实说,我看不到使用线程或不使用线程之间的实际速度增加,可能是因为 AJAX 调用的异步性质允许在调用开始和完成之间进行处理,或者可能是因为我没有做了足够多的工作可以看到很大的不同,但是线程版本允许我的页面加载器在加载数据时不会冻结,所以我想这是一个加分项。

你可能还喜欢下面这些文章

imwpcache如何使用ssi技术在所有页面展示最新文章imwpcache如何使用ssi技术在所有页面展示最新文章

前段时间有个朋友说用了缓存插件之后蜘蛛抓取变少了。
当使用缓存之后,所有的页面都是静态的,发了新的文章之后不会在旧的页面的侧边栏展示。
为了解决这个问题,imwpcache使用ssi技术来展示最新文章。
第一步:缓存后台开始SSI

全站缓存插件1.8版本发布:可单独控制页面是否缓存全站缓存插件1.8版本发布:可单独控制页面是否缓存

经过两个礼拜的改造,全站缓存1.8版本终于发布!
因此1.8版本之后插件中增加了单独控制文章或者页面是否禁用缓存的选项。
这个时候当访问有新文章发布的分类时,前台展示的是之前的缓存页面,但同时会自动生成一份新的缓存。

wordpress缓存插件: imwpcache 最快的全站静态化插件wordpress缓存插件: imwpcache 最快的全站静态化插件

imwpcache是一款可以最大限度为wordpress提速的缓存插件。
这就是imwpcache是最快的全站缓存插件的原因。
一定要两个插件都安装,imwpf是imwpcache运行的基础缓存。

WordPress文章去重插件simp,支持巨量文章查重WordPress文章去重插件simp,支持巨量文章查重

simp是一款文章排重插件,支持百万文章秒级去重!
如果您的文章是采集来的或者有用户上传发布,那么您可能需要这个文章排重插件。
历史文章一键查重如果您的站点存在大量已经发布的文章,可用本插件检测历史文章是否有重复。

puretext 一款能够支撑百万级文章的纯文字类型的wordpress cms主题puretext 一款能够支撑百万级文章的纯文字类型的wordpress cms主题

经过几年的制作,一款纯文字型的cms风格主题终于要和大家见面了。
但到目前为止,没有一款主题能支持巨量文章,于是只能自己做一款。
轻松支持百万文章不卡,无论是前台还是后都不卡。

wordpress多本小说主题 imwpnovelswordpress多本小说主题 imwpnovels

功能更强的wordpress小说主题imwpnovels,让创建小说站点更简单!
小说阅读页面支持无限制的字体缩放,支持护眼模式,页面模式,在使用静态缓存下刷新无闪烁的特性,用户体验极佳。

wprec:wordpress相关文章插件,最好的相似推荐插件wprec:wordpress相关文章插件,最好的相似推荐插件

一个理想的相关文章推荐插件应该是什么样子的?
wprec就是一个能够提升用户体验,提升搜索引擎排名的相关文章推荐插件!
插件的后台在 WP工具箱-文章推荐,进入即可看到设置。

wordpress小说主题imwpclassic 一个古典风格的小说主题wordpress小说主题imwpclassic 一个古典风格的小说主题

功能超强,页面美观的wordpress多本小说主题,一个能给你带来超额收入的主题!
主题拥有为小说优化的阅读页面,和普通的页面分开。
主题内置sitemap站点地图生成,支持巨量章节生成!

好看 (0) 很好看 (0) 非常好看 (0)
赞赏

微信赞赏支付宝赞赏