Let's back up a step. At a high level, we have multiple ways to accomplish "same thing", and we've not yet written down any section criteria to rank them. We should take a moment to do that.

First and foremost, for a good UX we want to minimize "time to display first game", or perhaps first few games that are visible without scrolling. That's how the user knows the server is responsive and is doing what was requested.

Second goal is to minimize "time to get all game titles", so the UI widget is fully interactive and scrollable, showing its complete scroll bar size.

A minor goal could be to minimize battery energy consumed on the client to deserialize / parse the game titles, but that seems such a minor consideration in this Use Case that we can simply ignore it.

So I recommend sending a "small" query for maybe six titles or just one, and then one "big" query that fetches the rest. If development time for two queries is longer than you'd like, then sending a single big query would be fine. Notice that this week's "hundred titles" could become a thousand titles next month, more than a user would usually want to interact with, so you may need to paginate perhaps a hundred at a time anyway. Or put a "more" button at the bottom so we get 100, then 200, then 300 titles to scroll through.

Some or all titles may have "expensive" metadata to display, such as a screen shot or animation. Feel free to let the browser lazily load those assets in the usual way, so displaying a dozen titles may lead to a dozen GET requests for image assets which eventually are displayed.

I assume we're doing https over HTTP/2 transport where the connection is kept alive for a few seconds of idle, just in case. We suffered a couple of RTT round trip times at the beginning, for TCP 3-way handshake and for crypto setup. But thereafter each GET will be pipelined within a multiplexed channel, and we can take good advantage of the available bandwidth.

One way to think about the tradeoffs is in terms of overhead, and the fact that a client often will have more bandwidth in the download direction than for uploads. Depending on the cookies that you've set, each GET request might be about a kilobyte long. Sending a few dozen titles, or sending an image, will be a few KiB, more than the size of a GET request, so that's a sensible ratio. But replying with just a couple dozen bytes for a single title turns the ratio on its head, making it seem like much work for little gain. And recall that we're going to have a separate log entry for each request.

Let's back up a step. At a high level, we have multiple ways to accomplish "same thing", and we've not yet written down any section criteria to rank them. We should take a moment to do that.

First and foremost, for a good UX we want to minimize "time to display first game", or perhaps first few games that are visible without scrolling. That's how the user knows the server is responsive and is doing what was requested.

Second goal is to minimize "time to get all game titles", so the UI widget is fully interactive and scrollable, showing its complete scroll bar size.

A minor goal could be to minimize battery energy consumed on the client to deserialize / parse the game titles, but that seems such a minor consideration in this Use Case that we can simply ignore it.

So I recommend sending a "small" query for maybe six titles or just one, and then one "big" query that fetches the rest. If development time for two queries is longer than you'd like, then sending a single big query would be fine. Notice that this week's "hundred titles" could become a thousand titles next month, more than a user would usually want to interact with, so you may need to paginate perhaps a hundred at a time anyway. Or put a "more" button at the bottom so we get 100, then 200, then 300 titles to scroll through.

Some or all titles may have "expensive" metadata to display, such as a screen shot or animation. Feel free to let the browser lazily load those assets in the usual way, so displaying a dozen titles may lead to a dozen GET requests for image assets which eventually are displayed.

I assume we're doing https over HTTP/2 transport where the connection is kept alive for a few seconds of idle, just in case. We suffered a couple of RTT round trip times at the beginning, for TCP 3-way handshake and for crypto setup. But thereafter each GET will be pipelined within a multiplexed channel, and we can take good advantage of the available bandwidth.

One way to think about the tradeoffs is in terms of overhead, bearing in mind that often a client will have more bandwidth in the download direction than it has for uploads. Depending on the cookies that you've set, each GET request might be about a kilobyte long. Sending a few dozen titles, or sending an image, will be a few KiB, more than the size of a GET request, so that's a sensible ratio. But replying with just a couple dozen bytes for a single title turns the ratio on its head, making it seem like much work for little gain. And recall that we're going to have a separate log entry for each request.