For books with many pages, don't show all pages to the user at first.

[eddierubeiz]

In our efforts to see if our app could work on Heroku, one persistent obstacle has been making sure the works that have over a hundred pages don't load too slowly.
While this a very small proportion of our overall works, these works tend to be high-prestige books, Ramelli being the prime example. At the moment, on Heroku, these works take quite a long time to load compared to our current setup.
This ticket covers the work of experimenting with changes to the user interface so when you first pull up a book like Ramelli, you do not see all the members (pages) in the browser immediately. This will make the page load much faster.
This is a complex question with accessibility implications.

[jrochkind]

My measurements showed that 80 would be a nice break -- 80 children still displays relatively quickly, and there are a pretty small proportion of works that haev more than 80 children. (Although I can't seem to find my notes on the details there at the moment).

In addition to work show page, another slow pages is the JSON data that powers the viewer, at a viewer_images_info route. This currently returns JSON for all children, and can also be fairly slow -- while the user might not notice as it happens in the bg, it can still be bogging down our app, with other requests waiting behind. It would be of benefit to split that up so the front-end JS requests the viewer_images_info JSON data in batches of 100 -- the user wouldn't be waiting any longer, but it would distribute between load balanced workers better/more evenly, instead of clogging up a request queue.

[jrochkind]

The new Rails "turbo frames" JS library may be useful here. Here is a good overview: https://mailchi.mp/railsspeed/turbo-frames-drive-and-migrating-a-legacy-app?e=e9606cf04b