更好的许多小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 调用的异步性质允许在调用开始和完成之间进行处理,或者可能是因为我没有做了足够多的工作可以看到很大的不同,但是线程版本允许我的页面加载器在加载数据时不会冻结,所以我想这是一个加分项。

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

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

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

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

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

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

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

wordpress礼物淘宝客主题:imwpgiftwordpress礼物淘宝客主题:imwpgift

一款礼物类型的淘宝客主题,能够为你带来丰厚的利润的主题!
整体以简洁为主,突出礼物图片,适合人群、年龄、场景等,拥有明显的购买按钮,用户可以从寻找礼物到完成购买,形成体验闭环。

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

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

wordpress单本小说主题 imwpnovelwordpress单本小说主题 imwpnovel

imwpnovel,极佳的wordpress单本小说主题

不仅仅是主题本身,我们还希望使用者能够使用这款主题为自己带来更多的收入,imwpnovel在最合适的位置均有广告位,在不影响用户体验的同时,给使用者带来更多的广告收入。
未使用缓存的时候,服务器会直接输出渲染好的页面,而使用缓存之后,因为无法保证用户看到的是夜间模式还是护眼模式,字体调整的有多大,因此在使用静态化缓存之后,将会使用js来渲染用户自定义的大小

蜂集采集器,一款全自动的wordpress采集插件蜂集采集器,一款全自动的wordpress采集插件

imwprobot(蜂集)是一款wordpress采集插件。
有什么功能1. 全自动无人值守,支持定时采集2. 可自动同步目标站的更新3. AI自动关键词、自动摘要生成4. 直接发布到wordpress,不需要额外的接口支持5. 正文图片和缩略图均可本地化6. 每个任务中的文章图片均可设置独立水印7. 采集到的内容均支持正则和css选择器替换可以采集哪些站1. 新闻资讯站2. 文章范文站3. BBS论坛4. 博客站点5. 资源站、下载站支持哪些采集规则1. 正则表达式2. XPath规则3. JQuery选择器(CSS选择器)代理支持1. HTTP代理 2. Socks5代理 哪些主机可以运行没有环境限制,虚拟主机都可以运行蜂集特色

蜂集采集器视频逐字稿蜂集采集器视频逐字稿

欢迎使用蜂集采集器,现在给大家分享蜂集采集器的使用教程。
接下来可以开始创建一个采集任务了,还是以lz13为例子,添加任务名称,添加入口地址,入口页面间隔可以不用改,正文抓取间隔可以不用改,选择采集模块,选择发布模块,选择草稿,任务选择暂停,后面我们测试好了再选择自动执行。

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

微信赞赏支付宝赞赏