It's the default pane in the AOM and it takes 10 seconds to load in a new profile. I tried it in my daily-use profile and it also took 10 seconds, but I might never have loaded it there before.

This is likely a dupe of bug 631054. Can you ping the IPs from comment #13 there?

Yep reachable, ~400ms.

400ms is a lot. Where are you geographically? If you ping addons.mozilla.org, what IP do you get?

I'm sitting in Europe and I get a ping time of about 200ms, which is also a lot and it takes ~5 seconds to load the pane.

(In reply to comment #3) > 400ms is a lot. Where are you geographically? If you ping addons.mozilla.org, > what IP do you get? Thailand. I get 63.245.217.40. Latency is generally higher here but most of the web still loads up in a few seconds. The 10 seconds for the Get Add-ons content is by far an outlier.

(In reply to comment #5) > Thailand. I get 63.245.217.40. Same IP address for me. > Latency is generally higher here but most of the web still loads up in a few > seconds. The 10 seconds for the Get Add-ons content is by far an outlier. Dietrich, what about if you load the page outside of the AOM? In my case it's a way faster. https://services.addons.mozilla.org/en-US/firefox/discovery/pane/4.0b11/linux

Another reason for the slowness is the fact that we're not displaying the pane until the complete web site has loaded, including all images. Normal web sites don't block their initial rendering on images, they add the images as they come in.

(In reply to comment #7) > Another reason for the slowness is the fact that we're not displaying the pane > until the complete web site has loaded, including all images. Normal web sites > don't block their initial rendering on images, they add the images as they come > in. Hmm, I didn't realize that. I've filed bug 635685 for us to make sure we're deferring as much as possible to after the page loads.

(In reply to comment #6) > Dietrich, what about if you load the page outside of the AOM? In my case it's a > way faster. > > https://services.addons.mozilla.org/en-US/firefox/discovery/pane/4.0b11/linux No problems there, loads in a reasonable period of time.

deitrich, can you traceroute to 72.26.221.66? That site is in Singapore and I'd like to understand the network path you take to get there. It's geographically closer than Phoenix, AZ is. (know any hosting providers in that region I could host AMO at?)

traceroute to 72.26.221.66 (72.26.221.66), 64 hops max, 52 byte packets 1 192.168.16.1 (192.168.16.1) 1.301 ms 0.837 ms 0.796 ms 2 182.53.128.1 (182.53.128.1) 25.670 ms 25.484 ms 38.318 ms 3 172.17.21.69 (172.17.21.69) 25.875 ms 25.500 ms 25.654 ms 4 118.174.231.253.static.totbb.net (118.174.231.253) 27.056 ms 26.586 ms 26.161 ms 5 ten-7-1-338.kkm-core-01.totisp.net (203.113.24.149) 38.870 ms 38.232 ms 37.965 ms 6 ten-1-3.kkm-gw-01.totisp.net (203.113.127.29) 40.247 ms 38.722 ms 38.156 ms 7 203.190.251.73 (203.190.251.73) 38.200 ms 38.363 ms 38.122 ms 8 203.190.251.70 (203.190.251.70) 42.240 ms 38.507 ms 41.091 ms 9 203.190.251.22 (203.190.251.22) 57.455 ms 54.655 ms 55.206 ms 10 203.190.251.33 (203.190.251.33) 55.361 ms 56.052 ms 56.397 ms 11 et-network.asianetcom.net (202.147.17.253) 257.014 ms 256.496 ms 259.936 ms 12 gi3-0-0.cr3.hkg3.asianetcom.net (203.192.134.65) 257.962 ms 257.437 ms 257.885 ms 13 po1-0-2.gw2.sin3.asianetcom.net (202.147.32.113) 279.245 ms 279.237 ms 279.492 ms 14 vdi-0001.asianetcom.net (203.192.169.234) 278.832 ms 278.946 ms 279.034 ms 15 21.te1-5.csr1.sin1.sg.voxel.net (72.26.220.18) 279.400 ms 279.441 ms 20.te1-1.csr1.sin1.sg.voxel.net (72.26.220.10) 281.174 ms 16 * * * 17 * * * 18 * * * and then i killed it. i'll ask around about hosting.

(In reply to comment #8) > (In reply to comment #7) > > Another reason for the slowness is the fact that we're not displaying the pane > > until the complete web site has loaded, including all images. Normal web sites > > don't block their initial rendering on images, they add the images as they come > > in. > > Hmm, I didn't realize that. I've filed bug 635685 for us to make sure we're > deferring as much as possible to after the page loads. I suspect this is the only reason for the delay. I am seeing it too in the AOM.

Are load times still as bad as they were when this bug was filed?

I just tried, was 9 seconds.

Christian, we discussed this in the products meeting today and think it should probably be on your radar as possibly blocking major update. We're hopeful bug 648146 will make a big improvement here.

FWIW, I was doing demos in Africa and got the same delays there. Due to this pane being the default for the AOM, a new oft-demo'd feature of Fx4, this bug should be very high priority.

Dietrich, before IT will jump in, can you also give us the information from traceroute from your current location in Africa?

I'm not there anymore. I'll ping someone from there to get it.

FTR, this is loading much much faster from my location in Thailand now.

(In reply to comment #20) > Created attachment 527578 [details] > tracert from kenya That's pretty high latency; that said, over in bug 648146, we've hooked AMO trunk staging up to a CDN (EdgeCast). If you'd like to try it (or have someone else try), do this: 1. Visit https://addons-cdn.allizom.org/ 2. Add the cert exception (should be safe, warning aside) 3. Via about:config, change extensions.webservice.discoverURL to https://addons.allizom.org/%LOCALE%/%APP%/discovery/pane/%VERSION%/%OS% You can follow-up in bug 648146, but if everything goes well, we'll probably flip the switch on production before May 2nd.

I've been doing a little experimenting with removing the loading message early and showing the content as it is loaded. In looking at the time it takes to load for me (albeit with a fast connection in the bay area) it seems that the largest problem is the initial delay before we start receiving data from SAMO. This try build hides the loading message as soon as data starts to flow in. It is a few moments before anything is visible but things start to appear very quickly after that. Since it no longer waits till everything is there it feels a little quicker to me but I'd like to get feedback from people who are seeing more of a problem here. It also logs information to the stdout console with timings at some stages during the load so getting that info might be useful too. Try builds based on latest nightly are showing up here now: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dtownsend@mozilla.com-d24c95284643/

(In reply to comment #22) > Try builds based on latest nightly are showing up here now: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dtownsend@mozilla.com-d24c95284643/ Sadly those builds are not available anymore. If you want to get it tested, can you fire-off another set of tryserver builds please?

New builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dtownsend@mozilla.com-e07383757f33/

That build works a lot faster for me.

Yeah, it looks way better and it's good to see how the page is build up instead of only watching the spinning indicator.

Sounds like this is a step in the right direction then. This shows the content sooner, also includes a little cleanup for a test that doesn't reset the url properly (causing all subsequent tests to touch the network) and properly removing the progress listener. Note that the addProgressListener call we use ignores the second argument so it is unnecessary.

Comment on attachment 528919 [details] [diff] [review] client patch rev 1 >+ } >+ catch (e) { Style nit: no newline. On a slow connection in NZ, the page stays white for quite awhile (3-4 secs) before anything starts to appear, which makes it look broken ("The loading message disappeared, its not doing anything, so it must be finished loading and must be broken.") So, to me at least, it feels like this hides the loading message too early. Not sure if it would improve on existing code, but did you try using DOMContentLoaded? Anyway, I'd like Boriss to look at the Try build, on both a fast and slow connection (clear cache between runs). r+ on the code, and deferring the rest to Boriss.

For some reason I couldn't get anything to catch DOMContentLoaded and this seemed like a good result anyway but seems it isn't ideal for you so I'll look back at catching that.

(In reply to comment #28) > On a slow connection in NZ, the page stays white for quite awhile (3-4 secs) > before anything starts to appear, which makes it look broken ("The loading > message disappeared, its not doing anything, so it must be finished loading and > must be broken.") So, to me at least, it feels like this hides the loading > message too early. I discovered a silly mistake in that patch which meant it hid the loading message much earlier than I had intended. I've made two more try runs and I'd appreciate it if you could test them. The first is basically as above, it waits for transferring to begin, but properly this time: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dtownsend@mozilla.com-379b844a55d9 The second is using DOMContentLoaded, it feels like it maybe waits a little too long to me but sounds like you have a worse connection than me so maybe you're a better judge: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dtownsend@mozilla.com-ea4a9614dfc2 I'd also appreciate the stuff dumped to the text console from that so I can see where you are getting the slowness.

Dave, I absolutely like the DOMContentLoaded version from above. Only with that build the removal of the loading indicator is directly followed with displaying the page content. The former build still has a delay in displaying the content. During that time nothing is shown.

(In reply to comment #31) > Dave, I absolutely like the DOMContentLoaded version from above. Only with that > build the removal of the loading indicator is directly followed with displaying > the page content. The former build still has a delay in displaying the content. > During that time nothing is shown. Can you get me the logs from the console for this build please?

The CDN is up. How does the add-on pane feel now?

Saw the loading panel for 11 seconds, then content appeared.

FWIW, the loading info in the bottom-left corner was showing things like 'connecting to static-cdn.blah...'. (Another issue is whether we should show that kind of in-content status information in application content pages, but that's a Mossop question for another bug.)

So no improvement for you? Can you traceroute to static-cdn.addons.mozilla.net so I can see which node you're hitting?

squirple:~ dietrich$ traceroute static-cdn.addons.mozilla.net traceroute to gs1.adn.edgecastcdn.net (68.232.42.20), 64 hops max, 52 byte packets 1 192.168.16.1 (192.168.16.1) 2.786 ms 1.754 ms 1.830 ms 2 182.53.128.1 (182.53.128.1) 25.742 ms 25.824 ms 25.378 ms 3 172.17.21.153 (172.17.21.153) 26.090 ms 25.983 ms 26.282 ms 4 118.174.231.253.static.totbb.net (118.174.231.253) 28.020 ms 25.370 ms 25.634 ms 5 ten-7-1-338.kkm-core-01.totisp.net (203.113.24.149) 146.280 ms 112.780 ms 494.893 ms 6 ten-2-3.kkm-gw-01.totisp.net (203.113.127.161) 40.459 ms 40.381 ms 40.018 ms 7 203.190.251.77 (203.190.251.77) 42.313 ms 42.020 ms 43.191 ms 8 203.190.250.49 (203.190.250.49) 38.399 ms 40.400 ms 40.462 ms 9 203.190.251.98 (203.190.251.98) 54.436 ms 56.552 ms 54.466 ms 10 203.190.251.41 (203.190.251.41) 53.634 ms 56.225 ms 53.417 ms 11 pos4-0.gw5.sin1.asianetcom.net (202.147.33.209) 611.785 ms 570.373 ms 265.571 ms 12 te0-0-2-0.wr1.sin0.asianetcom.net (61.14.157.109) 661.059 ms 570.003 ms 262.358 ms 13 te0-1-0-0.wr2.nrt0.asianetcom.net (61.14.157.82) 653.413 ms 260.897 ms 613.329 ms 14 gi14-0-0.gw3.lax1.asianetcom.net (61.14.157.94) 263.962 ms 615.461 ms 265.425 ms 15 * * * 16 68.232.42.20 (68.232.42.20) 264.112 ms 265.293 ms 405.766 ms

(In reply to comment #32) > Can you get me the logs from the console for this build please? Dave, do you still want those logs? If yes, I would need a new tryserver build. The one you have specified isn't available anymore.

(In reply to comment #38) > (In reply to comment #32) > > Can you get me the logs from the console for this build please? > > Dave, do you still want those logs? If yes, I would need a new tryserver > build. The one you have specified isn't available anymore. Yes, the builds are here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/old/dtownsend@mozilla.com-ea4a9614dfc2/

As discussed on IRC I do not get any output in the console with that build. So I can't help you in that case. Sorry.

Oops, sorry, I totally missed comment 30. Using the build from comment 39, there's no awkward delay between hiding the loading message and showing any content. Though I also didn't get to see the content being built, so maybe it is too early. I don't have the other build to compare against. Here's the log: 0: START REQUEST DOCUMENT NETWORK WINDOW https://services.addons.mozilla.org/en-US/firefox/discovery/pane/6.0a1/WINNT 973: TRANSFERRING REQUEST DOCUMENT https://services.addons.mozilla.org/en-US/firefox/discovery/pane/6.0a1/WINNT 979: STOP REQUEST https://services.addons.mozilla.org/en-US/firefox/discovery/pane/6.0a1/WINNT 986: START REQUEST https://static-cdn.addons.mozilla.net/media/css/zamboni/discovery-pane-min.css?build=2b3eaf2 994: START REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/jsi18n.js?b=2b3eaf2 998: START REQUEST https://static-cdn.addons.mozilla.net/media/js/zamboni/discovery-min.js?build=2b3eaf2 1004: START REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/addons/buttons.js?b=2b3eaf2 1014: TRANSFERRING REQUEST https://static-cdn.addons.mozilla.net/media/css/zamboni/discovery-pane-min.css?build=2b3eaf2 1027: STOP REQUEST https://static-cdn.addons.mozilla.net/media/css/zamboni/discovery-pane-min.css?build=2b3eaf2 1045: TRANSFERRING REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/jsi18n.js?b=2b3eaf2 1051: STOP REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/jsi18n.js?b=2b3eaf2 1056: TRANSFERRING REQUEST https://static-cdn.addons.mozilla.net/media/js/zamboni/discovery-min.js?build=2b3eaf2 1061: STOP REQUEST https://static-cdn.addons.mozilla.net/media/js/zamboni/discovery-min.js?build=2b3eaf2 2440: TRANSFERRING REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/addons/buttons.js?b=2b3eaf2 2447: STOP REQUEST https://static-cdn.addons.mozilla.net/en-US/firefox/addons/buttons.js?b=2b3eaf2 2452: STOP DOCUMENT https://services.addons.mozilla.org/en-US/firefox/discovery/pane/6.0a1/WINNT 2457: STOP NETWORK WINDOW https://services.addons.mozilla.org/en-US/firefox/discovery/pane/6.0a1/WINNT

Comment on attachment 528919 [details] [diff] [review] client patch rev 1 Lets get this reviewed finally. Fresh Try builds will appear here: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bmcbride@mozilla.com-e81a7d18efc7

Er, try here: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bmcbride@mozilla.com-8b234cfa8396/

Comment on attachment 528919 [details] [diff] [review] client patch rev 1 This seems much better to me. A simple change that would improve this even more on fast networks: don't show the spinner unless 2-3 seconds have passed, since right now I get a spinner for a few hundred milliseconds, then the page shows, and it's just being distracting. Anyway, ui-r+ on this, and if it's trivial to delay the spinner a few seconds, feel free to do that too. :)

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #45) > A simple change that would improve this even more on fast networks: don't > show the spinner unless 2-3 seconds have passed, since right now I get a > spinner for a few hundred milliseconds, then the page shows, and it's just > being distracting. We do something similar for loading the details view (because database access is async). But the norm for database access is almost-instant. For network access, almost-instant isn't the norm. Filed bug 722938 to look into this another time.

(Setting assignee to Dave, since it's his patch.) https://hg.mozilla.org/integration/fx-team/rev/e7f7c1e948ca