Retreving cached HTML from localStorage is taking > 150ms

[wilsonpage]

We can try:

A. Store less HTML (less bytes should make retrieval faster).
B. Store just the data and manually construct the elements/HTML before injecting into DOM.

[wilsonpage]

A. would be the quickest option to try right away. We would also likely get a win lowering first-pain time too due to the reduction in number of will-change items.

[etiennesegonzac]

Vivien really wants us to try the Cache API for that.
But I think you did already no?

The rationale is that it doesn't need to run on the main thread of the main process so it should play nicer on the launch path of an app.

[wilsonpage]

I tried IndexedDB, but it resulted in a flash of white before the content was ready. I've never used the Cache API, is it ready to use now?

[wilsonpage]

Just spoke to Francisco, gonna try it out when I have some time.

[wilsonpage]

I have a branch using the Cache API and so far results seem promising. It's taking 100 - 200ms to retrieve the cached content on startup, but this should not block unlike localStorage.

I've found opening the cache as soon as possible (before cache content is explicitly requested) seems to lead to fastest retrieval on startup.

I'm running into issues with the cachedHeight feature though. Currently we were able to retrieve this value synchronously on startup so that it was ready as soon as fast-list.js called getFullHeight(). Now the request for cachedHeight has not resolved before getFullHeight() is called, therefore the list scrollHeight can be wrong.

There are several ways we can address this, non of which seem ideal yet:

A. We could wait for the request for cachedHeight to resolve before creating new FastList(). This has the disadvantage that we're essentially blocking list setup until the cache request resolves. If we have content in the cache this isn't so bad as we will have painted something, if we don't have content in the cache we'll be adding to the time it takes for the user to see content.

B. We could update the height later. This will cause additional reflows and cause scrollbar flashing which is one of the things this feature aimed to avoid in the first place.

C. We could store the height integer in a synchronous storage container (localStorage or document.cookie) so that we can retrieve it before new FastList() is called. It would be best to avoid localStorage altogether and cookies are verbose/tricky to reason with.

---

I should also note that now cached HTML is fetched and injected async, we must be careful to avoid race conditions with the real fast-list. There is always a chance that new FastList() could render before the cached HTML is injected, in which case we need to be able to bail out of the cache injection.

[wilsonpage]

I've found opening the cache as soon as possible (before cache content is explicitly requested) seems to lead to fastest retrieval on startup.

Right now I'm doing this inline as one of the very first things in gaia-fast-list.js. This is not ideal as it means we're calling caches.open() even when the user may not be using the caching feature of gaia-fast-list.

But it has the advantage of giving us a boost of cache retrieval times when caching is being used! What to do?!