I don't think this is the right way to consider the problem. Putting aside the dose to talk about toxicity is hooliganism, and putting aside the time to talk about quantity is also hooliganism.
some interfaces are accessed in milliseconds, and some interfaces are accessed in seconds.
when we consider this problem, we must look at it in a comprehensive way. For example, you said that the same interface uses different parameters, which may be a good design. It may also be a stupid design that cannot be generalized.
for example, the first screen displays product information, showing that the top3, of different categories is designed to access N (number of categories) of interfaces. Each time the top (n), n of a single class is returned is an interface parameter.
this interface may have been requested 8 times on the first screen, and the front end said it was stupid. But in fact, the interface designed in this way is more flexible. Maybe one day the operator said, now we want to show product An eight, product B five, product C removed, and the front end changes when you move your fingers. What if the back-end interfaces converge into one? The front end needs to be changed, and the back end also needs to be changed. After the back end has been changed, the server may have to stop publishing, which is very troublesome. Generally speaking, the cost of updating H5 is the lowest, so it is reasonable to put this partial front-end logic in the page.
and js as an asynchronous language, region-independent ajax requests can be loaded first, rendered first, and the experience of the page will be better. It is also more convenient to do modularization.

if you need to obtain so much data, split requests and aggregate requests can be considered to have better aggregate request performance in terms of time. This is the same as the comparison between Edge and Chrome. It is said that Edge is actually faster than Chrome, but Edge must wait until the resources are downloaded before loading. Chrome is downloaded and loaded while downloading, which appears to be faster than edge.

in addition, there are really not many 8 requests.

many places say that page performance optimization reduces http requests. Do you think this is reasonable?

I am in favor of the subject's current multiple requests. Generally, http will set keep-alive , so multiple requests do not consume much time, and the advantage is that the page's first screen loading time will be faster. If unified into one interface, it will increase the cost of maintenance in the future.

there is no specific limit on the number. It depends on the project. Moreover, when multiple interfaces are merged together, the complexity of the interface increases, and it is not convenient to maintain and upgrade in the future. Too many interfaces are taken apart and there are too many interface requests, so you have to weigh the middle trade-off. There is no specific limit on this thing.

there is nothing wrong with multiple interfaces. Because the function of each interface is different.
but the same interface passes different parameters, which must be merged and optimized at the back end.

your idea should be optimized on the first screen, not on the home page, preferably one on the first screen, and the rest should be used to trigger load http requests. The request for the home page can be multiple

A page just entered may need to request seven or eight interfaces at a time, which I think is obviously more, and it also has an impact on performance. Personal advice: try to combine as many as possible in one interface

. Add, delete, modify, check

look at the business and database design. Of course, the less the better, and the less time spent on each request, the better. But the front end can't control it. If there are too many requests, consider changing requests such as polling to websocket, and caching some api locally, loading the cached data first when the page is loaded, and then sending a request to update the data and cache