As is generally well known the Marketplace-dev on Firefox OS can be very slow to load. Attached are the results of a launch loop with timing that shows it can sometimes take well over 60 seconds to load the app. Close to average it takes 30-40 seconds which is a bit poor.

This test was performed on Mozilla Guest in MV on an Unagi device on a quiet Friday afternoon :)

WONTFIXing since there's no real goal here. We are indeed working to make things faster, though, and here's some examples: - Continued work on reducing size of script bundle - Work to improve API response times (bug 869715) - Work to become a true packaged app (eliminating asset downloading) - Continued work to improve the memory management and rendering performance If there are particular examples of individual things that need performance improvement, please file bugs for each of them.

Thx, Basta, for that info -- we do need dev more stable/faster, though, specifically for Payments automation -- Jason, is this something you and the team can help with? We can work with you to find the specific painpoints. Thanks!

Stephen: Is there something in your logs that appears to be taking a long time?

-dev updates on every commit and this may make it slow and at times unstable. Can we point automation to stage instead? Stage updates once a day at noon and also has additional hardware allocated to it.

We could switch to Stage mostly but Payment testing blocks it because the payment process is different between Dev and Stage. (the details are with Andy and Krupa). tbh when I ran the same metric tests against Prod Marketplace it still would take on average 30 seconds to load on the device using MV wifi.

Obviously visiting the marketplace from a browser on desktop doesn't take 30 seconds to load. There are a few possibilities: - Poor network stack on the testing hardware (we know that unagis can't deal with wifi properly) - Saturation of the network. Quite possible since we download half a meg of assets - Improper http configuration on testing hardware. If the number of max concurrent connections is low, this will cause major perf issues.

IIRC, Krupa has filed a bug with IT to address the mobile Wifi. I agree the Marketplace definitely needs to be faster, but if I'm on a data connection (or my home wifi) pages don't take nearly as long to load. This sounds like a bug with MV's Mozilla Mobile Wifi. If so, let's fix that. There is a separate bug (bug 869715) to make our API faster, but I'm not convinced that's the (only) problem here.

Vaidik, Zac, can we reasonably break this down into components, using timestamps, logging?

Cvan what are you defining as loaded? when the spinner starts or when it is fully interactable? Stephen, yes I think that could be done with a one-off script. The current timing (as from comment #1) launches the app and wait for the 'apploadtime' b2g event which occurs when loading an app. What we would have to do is do away with that technique and use Marionette to switch to the frame, wait for and log other kinds of events for example the loading spinner appearing, loading spinner clearing, finally the apploadtime event again. if there are any other b2g system javascript events in there they could be watched too. The devs may have some events they'd like to see to help the breakdown of timing. I wouldn't be able to get to anything like this until next week. Vaidik got any other ideas?

Some useful benchmarks: - Time from launch trigger to page initialization (tapping the icon to parsing the HTML of the app's index.html) - Time from page initialization to iframe initialization (parsing index.html to triggering download of marketplace.firefox.com) - Time from triggering iframe init to downloading of Persona, L10n bootstrap library (l10n.js), and JS asset bundle (include.js) - Time from completion of all JS file downloads to marketplace init ("[mkt] Initialization complete" in the console)

Any ideas/progress on this?

Not anything the marketplace can do here.