The best way to approach this is using lazy fetches. The Reportable REST API is already set up to do paged fetching, as is the OSLC API, and this is how DNG does it too. 

Users inside the UI will never view the entire contents of a large module on one screen, they will inevitably page or search, so fetch the bare minimum to show an initial overview, and then fetch detail as the user browses to it, storing the data in a local cache. Refresh the cache for single records as the user goes into more detail.

If you watch how DNG does it, the first fetch pulls the basic module information so that you have the total number of artefacts, and enough for a table of contents, then the first page of the view being shown in the module is fetched, and finally the details of the current artefact are fetched if you have the side current artefact panel visible. If you then grab the scroll bar and start moving it down, you see the currently fetched contents scrolling and then it just shows section numbering, unless you pause. Then it fetches the next level of content.

In your case, I suspect you're asking this for your compare widget, so I would fetch the initial content and start your compare at the highest level, then fetch the detail that the user can currently see, and compare that, and then slowly fetch and compare in the background using Promises or async calls.

I'd also have a look at the code for the Module Browser widget supplied in the examples - it may give you some ideas but it may just be fetching the top level only.

Yes, there is simple way to improve speed of those reporting calls to DNG. Just use views data schema insteed of module.

Views allows you to get the exact data from the view you have in the DNG. IBM printModuleBook and printModuleTable are created this way.