Wil Clouser [:clouserw] Reporter
	Description • 10 years ago

Currently we send enough data in our API response to populate the home, listing, and detail pages for an app (minus reviews).  This lets us cache the entire response on the client and make loading any of those pages instant once we have the initial request.  This was built for two reasons:

1) users want to see the screenshots and descriptions of an app before installing so the common path was to click through to the detail page

2) We were building for wifi/wired connections

Now that EDGE is in play we should consider the time and byte savings of doing separate requests for additional data in Fireplace.  Additional requests likely wouldn't be noticed on desktop, especially if they were async, but they could save us some time on EDGE.  Even though this Marketplace isn't technically going on EDGE, it would let us expand there in the future easily and we might not need to revisit the Tarako panic again.

Tony:  Do you see any concerns from the UX POV?  Do you have any numbers for how often people click through to detail pages?

Engineering:  Any concerns?  We could use the same client side async caching strategy we have today, this would just reduce the first load size.

	David Bialer [:dbialer]
	Comment 1 • 10 years ago

> Tony:  Do you see any concerns from the UX POV?  Do you have any numbers for
> how often people click through to detail pages?
> 
Roughly 37% of all page views are app details pages.  On average, about 2 app detail page views per visit.  That is very high.

	Wil Clouser [:clouserw] Reporter
	Comment 2 • 10 years ago

(In reply to David Bialer [:dbialer] from comment #1)
> > Tony:  Do you see any concerns from the UX POV?  Do you have any numbers for
> > how often people click through to detail pages?
> > 
> Roughly 37% of all page views are app details pages.  On average, about 2
> app detail page views per visit.  That is very high.

Until bug 991306 is fixed, I'm not sure that number is accurate (I'd guess it's low).  It's an interesting number to have, but doesn't block looking in to splitting these out.

	Tony Santos [:tsmuse]
	Comment 3 • 10 years ago

Clicking through is largely dependent on the popularity of the app, from what I've seen across multiple tests focused on other things. For apps people know (Facebook, Line, Where's My Water, etc) they don't usually need to see any screenshots or reviews (although I've seen a few cases where a low star rating on a popular app has draw people to look at reviews to see what's wrong with it on our platform.) With that in mind, most of the stuff on Marketplace is unknown, so I would agree with the guess that the 37% of page views being details page views being too low. From data that I've seen from work on Apple and Google's stores, the price of the app also plays a role in how likely someone is to click through (A free app is more likely to be downloaded with little or no info than a paid app, esp on a fast network connection.)

What kind of load times are we talking about on EDGE or slower networks if we strip out this metadata and move it into an additional call? My guess is that in a majority of consumers (although it might be a small majority)will just end up making 2 calls instead of the one we have now.

	Mathieu Pillard [:mat]
	Comment 4 • 10 years ago

Removing from tarako v0 to replace with other API optimisations easier to include without breaking everything (see https://bugzilla.mozilla.org/show_bug.cgi?id=995793#c2)

	David Durst [:ddurst]
	Comment 5 • 10 years ago

It's unclear if this effort gains us any substantial (noticeable) perf improvement (in a non-Tarako context). Closing for now; someone can reopen if it's important.