Open Bug 736144 Opened 8 years ago Updated 11 months ago

Preload LocalStorage by blocking script tags

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: taras.mozilla, Unassigned)

References

Details

(Whiteboard: [Snappy:P1])

10:08 < khuey> so the script loader has two functions on it
10:08 < khuey> AddExecuteBlocker and RemoveExecuteBlocker
10:08 < khuey> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptLoader.h#152
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
               necessary
10:09 < khuey> and remove it when we're done preloading
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.
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 ...
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?
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.