Preload LocalStorage by blocking script tags




6 years ago
6 months ago


(Reporter: (dormant account), Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Snappy:P1])



6 years ago
10:08 < khuey> so the script loader has two functions on it
10:08 < khuey> AddExecuteBlocker and RemoveExecuteBlocker
10:08 < khuey>
10:09 < khuey> so LS just needs to listen for the new window created ("content-document-global-created"?) and then call AddExecuteBlocker on the script loader if
10:09 < khuey> and remove it when we're done preloading


6 years ago
Blocks: 627635

Comment 1

6 years ago
Is the idea here to see if a script mentions localStorage, and if it does, to preload the localStorage data before running the script so that when the script uses localStorage, it will not need to wait for it?

If so, this seems a little risky, since it will delay starting the page even when the page mentions localStorage but does not actually use it?
The plan I had was to block scripts for pages that have any localStorage data and that data is not already in memory.

Comment 3

6 years ago
This still seems risky to me, it will penalize initial load of any page that ever stored something to localStorage.
Sure.  It'll keep the browser responsive though ...

Comment 5

6 years ago
Ok, so it seems, once we do this we can rewrite LS impl using indexedDB
And that will unify quotas "automatically"
Is this option still being considered?
(In reply to Dietrich Ayala (:dietrich) from comment #6)
> Is this option still being considered?

I don't think so. The new localStorage design (bug 600307) already pre-fetches on page load and Telemetry shows that 80% of the time the data gets loaded before the first client JS access. 

There is further LocalStorage performance work being considered in bug 842777
Flags: needinfo?(honzab.moz)
(In reply to Vladan Djeric (:vladan) from comment #7)
> There is further LocalStorage performance work being considered in bug 842777

Taras doesn't believe this is going to help much.

He suggest to add more telemetry (which I agree) to find out.  But I'm fully occupied with new cache implementation for necko these days, so I don't have much time to do it soon.
Flags: needinfo?(honzab.moz)
Semi-annual ping :) What can we do to find out if this is worth doing?
Status is the same as outlined in comment 8.
So what kind of Telemetry do we need?
You need to log in before you can comment on or make changes to this bug.