Http Performance - Many small requests or one big one

Question

Scenario:

1. In my site I display books.
2. The user can add every book to a \"Read Later\" list.

Behavior:

Answer 1

I think in 2017 the solution is less about overall performance but about user experience and user expectations.

And nowadays user do not tolerate delays. In that sense sophisticated user interfaces try to be responsive as quickly as possible. Thus: if you can use those small requests to enable the user to do something (instead of waiting 2 seconds for that one big request to return) you should prefer that solution.

Too my knowledge, there are many "high fidelity" sites out there were a single page might sends 50, 100 requests... So I would consider that common practice.

And maybe it is helpful here: se-radio.net podcast episode 277 discusses this topic intensively, in the context of tail latency.

Answer 2

In my view it depends on how the data is stored. If a relational database is being used you could easily get the boolean flag into the list of books by simply doing a join on the corresponding tables. This will most likely give you the best results and you wouldn't have to write any algorithms in the front end.

Answer 3

Option 1 sounds good but has a big problem in terms of scalability.

Option 2 mitigates this scalability problem and we can improve its design:

Client side, via javascript, collect only displayed book ids and query once, via ajax, for an array of read-later info, only for those 30 books. This way you still serve the page fast and request a small set of additional info, once with a single http request.

Server side you can further improve caching an in memory array of read-later ids for each user.