How much does a WebSoket request cost compared to a RESTful HTTP request?

Question

RESTful API

For each RESTful HTTP request, a new TCP connection is initiated, then the actual request occurs, after which the TCP connection is closed.
WebSocket doesn't create a new connection, instead it does an upgrade using the HTTP Upgrade mechanism
. I've worked mostly with RESTful HTTP, and there I've tried to collect more data for a one-time request, to reduce server load, because I think that one a larger request loads the server less than the same amount of data divided into 3-4 small requests. Do the same rules apply when working with a web socket? Does it make sense to make fewer requests and get larger responses, instead of sending 3-4 small requests? And if there are 10-15 requests?
How to measure it?
The most banal example: loading data when scrolling down the page - load 40 objects at a time or 4 times 10 - after all, the user may not need those 30 objects that did not fit on the first "screen" (without scrolling down)

Thank you for your time !

Answer 1

For each RESTful HTTP request, a new TCP connection is initiated, then the actual request occurs, after which the TCP connection is closed.

This is not true for HTTP 1.1. See Persistent HTTP Connection
The advantage of WebSocket is that it does not parse HTTP headers for each request and generate headers in each response. After the initial connection is established via HTTP, then the actual raw protocol is opened, according to which "naked" packets are transmitted without any headers. This reduces the load on the server, on all intermediate proxies (which means it can affect latency) and on the client. But that's not what WebSocket was originally designed for. The main problem it was designed to solve was to replace push/long-polling/comment, a crutch that is not adapted for this HTTP.
HTTP2 completely solves this problem. Before its implementation, this approach is still relevant.

Answer 2

In this regard, one big request is better than many small ones. Because most likely you will make synchronous requests, which means that you will wait for a response from the server and only after that send the next one. That is, network delay is sometimes also worth considering.
If your protocol inside the council is asynchronous, then you can send all requests in parallel and wait for a response from the server. Then network delays are not significant.