Http性能-许多小请求或一个大请求

场景:

在我的网站上,我展示了书籍.

用户可以将每本书添加到"稍后阅读"列表中.

行为:

当用户进入该站点时,他们会看到一系列书籍.其中一些已经在他们的"Read Later"列表中,有些则不是.

用户在每本书旁边都有一个指示,告诉他们该书是否已被添加到列表中.

我的问题

我在辩论哪种选择对我的情况是理想的.

选项1:

对于每本书,查询服务器是否已存在于用户列表中.

更新每本书的指标.

Pro: 对服务器的请求非常小,响应非常简单(真或假).

Con:在一本有30本书的页面中,我将发送30个单独的http请求,它们可以阻止套接字,并且考虑到浏览器和服务器必须为每个事务执行整个握手,这个请求相当慢.

选项2:

我查询服务器一次,并获得一个响应,其中包含"Read Later"列表中的完整书籍列表作为数组.

在浏览器中,我查看了数组,并根据它是否存在于数组中来更新每本书的指示.

亲:我只提出一个请求,并立即更新所有书籍的指标.

Con: "Read Later"列表可能有数百本书,传递一个大数组可能会证明是缓慢而过度的.特别是在屏幕上没有出现30本书的情况下,只有2-3本.(也就是说,我想检查某个书是否在列表中,为此我让服务器从列表中向客户端发送整个书籍列表).

所以,

你会采用哪种方式来最大限度地提高性能:1还是2？

我有什么替代品吗？

我认为2017年的解决方案不仅关乎整体性能,还关乎用户体验和用户期望.

而现在用户不能容忍延迟.从这个意义上讲,复杂的用户界面尽可能快地响应.因此:如果您可以使用这些小请求来启用用户执行某些操作(而不是等待一个大请求返回2秒),您应该更喜欢该解决方案.

据我所知,有很多"高保真"网站,有一个页面可能会发送50个,100个请求......所以我会考虑这种常见做法.

也许它在这里很有用:se-radio.net播客第277集在尾部延迟的背景下深入讨论了这个主题.