Http Performance - Many small requests or one big

Question

Scenario:

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

Behavior:

When the user enters the site, they are presented with a list of books. Some of which are already in their "Read Later" list, some aren't.

The user has an indication next to each book telling them whether the book has been added to the list or not.

My issue

I am debating which option is the ideal for my situation.

Option 1:

1. For every book, query the server whether it already exists in the user's list.
2. Update the indicator for each book.

Pro: Very small request to the server, and very easy response (true or false).

Con: In a page with 30 books, I will send 30 separate http requests, which can block sockets, and is rather slow considering the browser and the server have to perform the entire handshake for each transaction.

Option 2:

1. I query the server once, and get a response with the full list of books in the "Read Later" list as an array.
2. In the browser, I go over the array, and update the indication for each book based on whether it exists in the array or not.

Pro: I only make one request, and update the indicator for all the books at once.

Con: The "Read Later" list might have hundreds of books, and passing a big array might prove slow and excessive. Especially in scenarios when not 30 books appear on the screen, but only 2-3. (That is, I want to check if a certain book is in the list, and for this I have the server send the client the entire list of books from the list).

So,

Which way would you go to maximize performance: 1 or 2?

Is there any alternative I am missing?

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

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.

Answer 3

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.