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:

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, and beyond, the solution is much less about overall performance but about user experience and user expectations.

Nowadays users 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 quickly (instead of waiting 2 seconds for that one big request to return) you should prefer that solution.

To my knowledge, there are many "high fidelity" sites out there where 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.