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

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Discovery Pane, defect, P4)

Description

[Justin Scott [:fligtar]]

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.

Comment 1

[Wil Clouser [:clouserw]]

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?

Comment 2

[Justin Scott [:fligtar]]

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?

Comment 3

[Dave Townsend [:mossop]]

There may be a middle ground, it'd take some experimentation though.

Comment 4

[Brian King [:kinger]]

Show 'Loading' until a web progress listener tells us that the page has started loading?

Comment 5

[Justin Scott [:fligtar]]

Pretty sure we can't get any Firefox 4 changes in for this, so let's see what we can do on our side.

Comment 6

[Jeff Balogh (:jbalogh)]

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.

Comment 7

[Wil Clouser [:clouserw]]

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.

Comment 8

[Christopher Van Wiemeersch [:cvan]]

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).

Comment 9

[Justin Scott [:fligtar]]

The caching fixes will only improve things for logged-in users, right?

Comment 10

[Jeff Balogh (:jbalogh)]

(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.

Comment 11

[Christopher Van Wiemeersch [:cvan]]

https://github.com/jbalogh/zamboni/commit/58b2f7a6
https://github.com/jbalogh/zamboni/commit/28e5090