Make sure we're loading as little as necessary on pageload

RESOLVED FIXED in 6.0.1

Status

addons.mozilla.org Graveyard
Discovery Pane
P4
normal
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: fligtar, Assigned: cvan)

Tracking

Details

(Reporter)

Description

7 years ago
Apparently the Discovery Pane doesn't display in the Add-ons Manager until everything is done loading, which is contributing to some really crappy load times (bug 635610).

We should only load what we need to before displaying the page -- even if it means having some of the content fade in later.
That sounds like we're manually implementing drawing the page as it loads.  Why don't we just turn off the "don't draw until everything is loaded" setting and get it for free?
(Reporter)

Comment 2

7 years ago
The client shows a 'Loading' screen while it's loading, and before we had that it showed a white screen while it was waiting for the response. I don't know if we can show the Loading screen only until the page starts to be drawn or if we have to wait until everything's finished loading. I definitely don't want to go back to the white screen.

Mossop, do you know?
There may be a middle ground, it'd take some experimentation though.

Comment 4

7 years ago
Show 'Loading' until a web progress listener tells us that the page has started loading?
Target Milestone: 5.12.12 → 6.0.0
(Reporter)

Comment 5

7 years ago
Pretty sure we can't get any Firefox 4 changes in for this, so let's see what we can do on our side.
It sounds like the main thing is to defer all images. There are other bugs for pulling in less js and I'd like to see discovery.css slim down too.

If we remove the user-specific content from the top-right pane we can cache this page forever in zeus. Page load time averages 0.6 seconds which is too slow for me.

If we start putting the username in a cookie we can generate all the user-specific content on the client.
cvan:  you've done some work here, can you give us an update and eta?

> If we start putting the username in a cookie we can generate all the
> user-specific content on the client.

I'd be interested in some JS that saw the logged in cookie and did another request to get logged in info (including username).  If the "info" was a JSON blob we could expand it later.
Priority: P3 → P4
Target Milestone: 6.0.0 → 6.0.1
(Assignee)

Comment 8

7 years ago
I had written a patch that loaded the page content in two calls after the DOM is loaded: one for the main content (Promo/Featured) and another for the Sidebar modules.

I better like the idea of caching this page and doing one request for the "My Account" module. I'll plan on landing this Tuesday (Monday if time permits).
(Reporter)

Comment 9

7 years ago
The caching fixes will only improve things for logged-in users, right?
(In reply to comment #9)
> The caching fixes will only improve things for logged-in users, right?

Right. Not including user info means we have a known-fast baseline page served from zeus. However, I think the largest bottleneck here is fetching all the image assets.
(Assignee)

Comment 11

7 years ago
https://github.com/jbalogh/zamboni/commit/58b2f7a6
https://github.com/jbalogh/zamboni/commit/28e5090
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.