W3C home > Mailing lists > Public > public-publ-wg@w3.org > July 2017

Re: Web Publications via HTML Imports

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Tue, 1 Aug 2017 00:44:34 +0200
Message-ID: <CA+KS-10x8OWEJiugwNAyAiyRQ54PuQBsDkJDjPpfLkp=wB7J0A@mail.gmail.com>
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>
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:

"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

Here's an example of a manifest that also prefetches such secondary
resources using a HTTP Link header:

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.

Received on Monday, 31 July 2017 22:45:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:15 UTC