Significantly worse performance in Chromium extension due to lack of Cache API

[Jaifroid]

Because Cache API is not supported in Chromium extension (only secure requests and responses can be cached, i.e. https:), the app has to re-load all assets from the ZIM every time it is re-launched. This adds a really noticeable performance penalty to using the Chromium extension.

Possible solutions:

• Move to Manifest V3 (see also #755), which uses a Service Worker as its background service, though it is not clear whether this will support Cache API;
• Add a cache.js layer that selects between Cache API and IndexedDB according to availability of each API, as in Kiwix JS Windows;
• Use the same solution for Chromium in SW mode as for the Mozilla Extension (i.e., use the PWA).

[mossroy]

If I understood correctly, the performance impact is "only" when opening the ZIM file (or, more generally, when opening an article that uses an asset for the first time of the session)? Afterwards, according to the dev tools of Chromium, it keeps the assets in its memory cache, to avoid reading them again from the ZIM file.

I doubt Manifest v3 will help us on that, but I might be wrong.

It's clear that the PWA avoids many limitations of extensions, which makes it interesting. But the fact that it's not 100% offline is a big issue IMHO. And we should "play" with it (with Firefox) a bit more in the short term.

Using IndexedDB could be a solution.

But I would put a low priority on this issue.

@kelson42 : do the other Kiwix clients keep some assets in a persistent cache, that is kept after closing the app?

[Jaifroid]

Yes, we have a memory cache for assets, and Chrome implements some caching of its own, but neither seem to persist across sessions like Cache API does. I agree it's not high priority. Let's see how we get along with the PWA in Firefox once it's released.

[Jaifroid]

The PWA workaround fixes this for SW mode (which is the only place that Cache API is used in this app).