There is no generally accepted practice. There are different architectural patterns for web applications.
The server-side presentation pattern has the entire work of generating a page done on ther server side. The navigation in the application is between pages rendered entirely by the server. This is the oldest model as it has been supported as long as HTML itself.
The single page application has a server-provided application loader page that may be static. This page references a fully client-side application that will render pages and obtain content via XHR (large infrequent requests), EventSource (text-based server side events), Websocket (streamed, binary content), or WebRTC (realtime peer to peer audio/video) depending on need. This is a popular model for recent web applications.
There are also hybrids of both approaches that enable optimizations of page load time and resource consumption. An often overlooked aspect of web application development is power consumption on mobile devices. A particularly bad example of this is a periodic XHR to obtain updates. It will trigger the cellular radio to come on right after it has idled maximizing battery consumption and maximizing latency.
There are no straight forward absolute answers here. There are some principles with obvious wins though:
- Make as few requests as possible
- Send as little data as possible (use efficient representations and compression)
- Take advantage of caching (set Cache-Control and Last-Modified, and Etag headers correctly)
My personal experience with switching from server-side presentation to a single page application was a substantial improvement in responsiveness. There are definitely downsides to having every data set on the page pulled down in a separate request. The downsides are directly related to how they violate the principles above. We had to learn to bundle data sets into fewer requests.
Interestingly with HTTP/2 the bundling is counter-productive because HTTP/2 supports multiple streams (standard requests or otherwise) on a single TCP connection. Don't spend a lot of energy optimizing for HTTP/1.1 in ways that will hurt your app for HTTP/2. This trade off is not completely straight-forward either as Khan Academy discovered.
In your case I would advise going with a client-side presentation framework. It gives you more flexibility in rendering timelines and request counts. More importantly it gives you an application that doesn't go to a white screen when the server processing a request chokes or disappears. You can actually handle that as an exception on the client-side and provide user feedback and retry mechanisms. I do not recommend server-side presentation frameworks except to facilitate more efficient delivery of single page applications.
Much more on this is available in Ilya Grigorik's High Performance Web Browser Networking.