Marketplace/Performance optimization
.png){kind=small}
This is a page to aggregate information about Marketplace performance efforts.
Contents
Current Status
Via webpagetest from a non-US country shows:
- More than one second is spent just to get '/'. Part of this is because we don't have OSCP stapling, so the initial TLS request is very slow. 1011152 was effectively wontfixed by ops (not much we can do about it).
- Another second and a half is necessary to load our 2 main CSS files (splash.css, include.css).
- Another second is necessary to load our JavaScript. (Note: at this point, we're at the 4 seconds mark and we haven't started requesting the API endpoint. In a packaged app, all this would have been loaded from the package almost instantaneously.)
- Then we have a bunch of images, svg, fonts from the CSS loading in //. (This would also be part of the packaged app.)
- Then we see the request the the API takes 2.5s (working on this now)
- Then we start rendering. Marketplace is usable at this point (8 seconds passed)
- Then we start loading the app images, and there are a lot of them.
All that was on a cable connection, on a desktop. It's going to be worse on mobile.
Want to contribute?
Log new bugs in Bugzilla, block 'marketplace-perf'
Ask about things in #marketplace.
Mitigation strategies
The short version is that we need to optimize things that should be optimized regardless of other constraints (device constraints, network constraints, etc). Only then can we differentiate between strategic investment and Doing Things The Right Way.
At a high level, these are the strategies being considered for marketplace.firefox.com:
- Feature/Memory/Device detection (reliable) (900241)
- Speed and Performance bugs, general at this point (see below)
- Establish target benchmarks & KPIs for performance
- Front and Back-end Performance adjustments (pending benchmark results -- currently the mark is "as fast as possible")
Tarako-specific:
- new "low resource" packaged app (implemented)
- Filtering apps for "low resource" device (implemented)
- UI updates to accommodate RTL & other local language requirements (pending)
Note: We now have the ability to do NewRelic/ElasticSearch deep debugging
Open issues
These are immediate issues:
These are future issues:
- Related, having the feature detection API (983502) as originally described -- this isn't a Marketplace bug, so we're implementing something else for 1.3 and hope to have this for 1.4, 1.5 at the latest.
Bugs
Tracking bug: 1075278.
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
The following bugs have been identified as delivering good performance increases; they are grouped here for ease of consideration.
Note that not all of these are Marketplace bugs, and thus not all are in the priority groupings at the bottom of the page.
overall speed
- 871683 (wontfix, Server Ops) Note: thus far, SPDY tests have not demonstrated substantial improvements, in part due to system configuration aspects outside of our control. However, these tests were run on the current Marketplace app, which is basically an iframe wrapper. SPDY tests may be more straightforward on the Tarako Marketplace, but as that app is fully packaged it may be irrelevant.
improve API response time
improve caching techniques
optimize asset delivery
optimize synchronous delivery
- 847679 -- this one is big, mostly because it depends on...
optimize first run
- 897156 -- ... becoming a real packaged app.
General performance bugs (potentially obsolete)
This is a listing of Marketplace bugs only, by priority. If a priority has not been applied, you will have to find it directly. Here's a good place to start
