Hello Benjamin, In the context of Readium-2 we've already explored (and implemented support for) preload/prefetch/prerender. I highly recommend reading the following article: https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf "Prerender" is very tricky to use properly, because the resource is kept for a limited amount of time and there's an upper limit memory-wise (lower on mobile as you can guess). If you prerender too many resources that are then trashed, you're wasting CPU cycles and RAM that could be used more effectively in another context. IMO, the only effective way to use "prerender" in the context of a Web Publication is when you're fairly sure that a resource is going to be rendered very soon. This can be implemented for example by dynamically injecting a link (HTML header) when the user reaches the end of a given resource. "Prefetch" is easier to implement, in the Go and Typescript versions of the Readium-2 streamer (the part that takes an EPUB as an input and outputs a Web Publication with a manifest and multiple addition services on top) we use it to preload CSS/fonts/JS at the same time as the manifest is loaded. Since these resources are heavily cached by our server (using Cache-Control) this means that they're pretty much preloaded once and for all. Here's an example of a manifest that also prefetches such secondary resources using a HTTP Link header: https://readium2.feedbooks.net/Ym9va3MvbW9ieS1kaWNrLmVwdWI=/manifest.json That said, I don't believe that such optimizations belong in a spec, but they could be mentioned in the type of best practice document that Ivan recently mentioned. Best, Hadrien
Received on Monday, 31 July 2017 22:45:18 UTC