Should the client call them directly one after another to get the data it needs to load up a web page on the client?
It depends; however, I'd suggest providing directly usable capabilities to the client and hiding (encapsulating) the details of how results are assembled (e.g. via multiple micro services).
If too much logic is involved in combining individual micro-service results by the client, that may inadvertently cause some business logic to creep into the client. It can also expose more of your internal architecture to the client than you would like, hindering later refactoring of the microservices.
So, that means with microservices, sometimes it is helpful to have a wrapper microservice that provides the client an endpoint having useful abstractions and that performs a higher level coordination of other (perhaps now more internal) microservices.
(Further, round trips to the client are likely more expensive than from your microservices to each other.)
If you look at the direction being taken by GraphQL, for example, you'll find clients issuing directly relevant queries to an endpoint, which may or may not be implemented as a collection of micrservices. As the architecture of the microservices is hidden behind GraphQL, that makes the architecture easier to refactor and also friendlier to the client. See, for example, https://stackoverflow.com/a/38079681/471129.