Readium Logo

Best Practices for HTTP Caching

Publication Servers are responsible for providing the manifest, resources and APIs through HTTPS.

To optimize the user experience, each implementation should rely on HTTP caching.

For anyone unfamiliar with caching in HTTP, we highly recommend reading Mark Nottingham or Iliya Grigorik introductions to HTTP caching.

Caching the Manifest

While the in-memory model and the subsequent manifest are most of the time fairly static resources, there are a number of use cases where they can change over time:

For these reasons, it’s best to revalidate with the server the freshness of a manifest using an ETag.

We recommend each implementation to do the following:

Caching Publication Resources

Publication resources (listed in readingOrder or resources) served by the server are unlikely to change and should be cached more heavily than the manifest.

Having fonts, CSS or JS in cache can have a very positive impact on rendering time for HTML in a browser or a webview.

We recommend each implementation to do the following:

Caching APIs

Each API exposed by the server is potentially unique and there’s no generic rule that can be applied.

That said, we can use the two examples above to provide some guidelines: