Firefox installer size: How big is too big?

[Chris Peterson]

Has Mozilla ever had a code size budget? When we ran codesighs tests,
was there a policy defining test "failure"?

These questions were raised during a recent dev-platform debate about
ICU/i18n data (bug 853301) increasing the size of Firefox's installer by
~2 MB.

Anurag on the Metrics team created this chart of the Windows installer
size from 2004 to 2013. (The February 2010 inflection point is Firefox 3.6.)

https://people.mozilla.org/~cpeterson/2013/firefox-installer-size.png

Firefox 28 may be the first release where the installer size (in MB)
exceeds the version number. Firefox 27 is ~26 MB. For comparison, Chrome
30 is ~35 MB.

However, file size doesn't mean much without data about internet
download speeds for different regions. We don't have data correlating
installer size with number of unsuccessful downloads, but there is
discussion about running a Funnelcake study in bug 928017. However, my
hypothesis is that download failures will increase steadily with file
size, but not give a clear answer as to the question "How big is too big?"



cpeterson

[chris hofmann]

Here is the thread on this topic that summarized state and issues as of
18 months ago.

https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/k7fzkhdt9io

Thats probably worth reading before rehashing old ground, and to help
effective action going forward.

The sub installer with a series of components that are downloaded is
really the only way to measure how much impact this has on users. That
question was raised 18 months ago but never answered.

We did have answers to this back in the Netscape stub installer days
when the download was also about 30 MBs. About 10-15MBs into the
download the install failure rate had a dramatic hockey stick. That was
one of the key motivators to launch an effort around the Mozilla browser
which became Firefox, and which got the full install back under 5MBs.
Download success was dramatically improved as measured by total bits
transfered from the ftp/http logs.

That was more than a decade ago so the 10-15MB inflection point might
have shifted dramatically, but the only way to tell is via stub
installer data collection, or maybe telemetry could tell us when network
errors seem to mount when trying to download or stream any kind of content.

-chofmann

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[Robert Strong]

On 10/25/2013 2:44 PM, chris hofmann wrote:
>
> Here is the thread on this topic that summarized state and issues as
> of 18 months ago.
>
> https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/k7fzkhdt9io
>
>
> Thats probably worth reading before rehashing old ground, and to help
> effective action going forward.
>
> The sub installer with a series of components that are downloaded is
> really the only way to measure how much impact this has on users.
> That question was raised 18 months ago but never answered.
>
> We did have answers to this back in the Netscape stub installer days
> when the download was also about 30 MBs. About 10-15MBs into the
> download the install failure rate had a dramatic hockey stick. That
> was one of the key motivators to launch an effort around the Mozilla
> browser which became Firefox, and which got the full install back
> under 5MBs. Download success was dramatically improved as measured by
> total bits transfered from the ftp/http logs.
>
> That was more than a decade ago so the 10-15MB inflection point might
> have shifted dramatically, but the only way to tell is via stub
> installer data collection, or maybe telemetry could tell us when
> network errors seem to mount when trying to download or stream any
> kind of content.

As noted in bug 928017 (
https://bugzilla.mozilla.org/show_bug.cgi?id=928017 ) we have stub
installer data for Windows going back to 6/28.

Robert

>
> -chofmann
>
> On 10/25/13 2:11 PM, Chris Peterson wrote:

[cwe...@mozilla.com]

>However, my hypothesis is that download failures will increase steadily with file size, but not give a clear answer as to the question "How big is too big?"

I look forward to seeing the proposed funnelcake study design, and would probably share your hypothesis. But it seems like "too big" is going to be a value judgement we're always going to have to make in assessing the value provided by the specific incremental increase in size against the drop-off in installs.

If we can arrive at a model that can reasonably predict install drop-off at different sizes, we ought to be able to more soundly call something "too big".

At the same time, I notice a lot of plausible ideas for reducing size in the thread chofmann links to and that type of work could be prioritized pending the results of the ongoing program/strategy review.