RE: Web Publications via HTML Imports

Sorry, Hadrien, I guess I wasn’t clear.

My thought was that the algorithms and strategies backed into the Resource Hints spec (i.e. the process of following the links, accumulating secondary resources, etc) might be useful when they build something that “keeps” (or “offlines” or whatevers) a Web Publication.

If you imagine an HTML Table of Contents a starting point and a browser that understands that (when asked by the user) it should “keep” the publication through a process similar to prefetching and prerendering, then you get closer to what was in my head. :)

It wasn’t a post about “optimization” option so much as “implementation” option—that already has some similar plumbing built into browsers.

Hope that clarifies a bit.

Cheers!
Benjamin

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
Sent: Monday, July 31, 2017 6:45 PM
To: Benjamin Young <byoung@bigbluehat.com>
Cc: Ivan Herman <ivan@w3.org>; Dave Cramer <dauwhe@gmail.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Web Publications via HTML Imports

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