Generally speaking, you're almost always better off with more light requests than fewer heavy requests.
Assuming this is static content (chapters) there's absolutely zilch you're gaining by fetching the whole block at once instead of chapter by chapter, since you can shove it all behind a CDN anyways.
You're losing a lot of flexibility and responsiveness on slow connections, though.
Not to mention - it may make sense to be doing something like fetching say... 5 chapters at a time, and then fetching the next chapter when the user scrolls to the end of the current chapter (pagination - a sane approach used by anyone who's had to deal with data at scale)
In basically every case though, as long as each chapter is at least a few hundred characters, the extra overhead from the requests is basically negligible, and if they're static - easily cached.
You didn't read what I wrote closely enough. You just fetch the data you need for the list of chapters. In most cases, it'll just be something like chapterID, chapterTitle and maybe chapterShortDescription. This would be easily stored in db cache since chapters don't change much.
Generally speaking, you're almost always better off with more light requests than fewer heavy requests.
Assuming this is static content (chapters) there's absolutely zilch you're gaining by fetching the whole block at once instead of chapter by chapter, since you can shove it all behind a CDN anyways.
You're losing a lot of flexibility and responsiveness on slow connections, though.
Not to mention - it may make sense to be doing something like fetching say... 5 chapters at a time, and then fetching the next chapter when the user scrolls to the end of the current chapter (pagination - a sane approach used by anyone who's had to deal with data at scale)
In basically every case though, as long as each chapter is at least a few hundred characters, the extra overhead from the requests is basically negligible, and if they're static - easily cached.