Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Firefox download size

420 views
Skip to first unread message

Asa Dotzler

unread,
Apr 1, 2012, 12:39:04 AM4/1/12
to
This evening I noticed that my full win32 mar update for Firefox was
21MB. That caused me to look at what our full win32 installer size was.
I was a bit surprised to see it's up to 17MB.

When we shipped Firefox 1, our Windows installer build was 4.7MB. I
realize that we've added some nice features and that we're including
some new DirectX libraries so I didn't expect Firefox to stay that
small. I am concerned about getting this large, though, and what than
means for people downloading Firefox, especially on slower connections.

Between 2002 and late 2004 when we shipped Firefox 1, we believed it was
critical to get Firefox down to "about the size of an mp3" both to make
the decision to download palatable and to increase the likelihood that
people would finish the download before switching to some other task and
forgetting about it. A download cannot become a Firefox user if it's
lost in the background of other Web activities.

Is there anything obvious we can do to trim things back down some? Has
it been a steady growth or did it recently spike up? Is this current
size acceptable? (I don't think it is.) Do we have any data that
correlates completed downloads with download size over the last few
years? Where in the product is this growth? Is Gecko that much bigger or
is it Firefox front-end?

Also, our Mac download is over 39MB :\

- A

Michael Lefevre

unread,
Apr 1, 2012, 5:17:21 AM4/1/12
to
On 01/04/2012 05:39, Asa Dotzler wrote:
[...]
> Is there anything obvious we can do to trim things back down some? Has
> it been a steady growth or did it recently spike up? Is this current
> size acceptable? (I don't think it is.) Do we have any data that
> correlates completed downloads with download size over the last few
> years? Where in the product is this growth? Is Gecko that much bigger or
> is it Firefox front-end?

It's been a steady growth. I would think that would make it pretty hard
to look at correlation usefully.

I asked a similar question last year, and I guess some of the answers
there are still relevant. Particularly that part of the growth is in
supporting more platforms (and since then I imagine adding Windows 8
while still supporting Windows XP, within the same download, is or has
contributed to that), and having a stub installer would mean just
download the appropriate pieces could be downloaded rather than
supporting everyone on Windows with one file and everyone on Mac with
another.

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

Michael

Axel Hecht

unread,
Apr 1, 2012, 9:17:34 AM4/1/12
to
I've gathered the current data from archive, and plotted it vs time,
http://people.mozilla.org/~axel/Firefox%20sizes.ods.

Didn't manage to get something that can be understood without the
spreadsheet, but it looks like linear growth over time from 1-3.6, and
then from 3.6 to 12. Just the latter at a rather different slope, and a
worse one.

Axel

William Barnacle

unread,
Apr 1, 2012, 11:29:09 AM4/1/12
to
Nice graph. Is it just me, or does the significant change in rate of
size increase after about 2009, seem to be related to the introduction
of the rapid release schedule ?

Axel Hecht

unread,
Apr 1, 2012, 12:53:55 PM4/1/12
to
Note that already 4.0 showed the size increase, and that one was
anything but rapid.

I think it has more to do with the growth of our contributor size that's
able to work full time. And most of them are working on adding features,
not ripping stuff out.

Axel

Asa Dotzler

unread,
Apr 1, 2012, 1:08:56 PM4/1/12
to
Firefox 12 is a 16.1 MB download.
Firefox 4 was a 12.0 MB download.
Firefox 3.6 was a 7.7 MB download.

In less than three years we've more than doubled in size. (fuller chart
here http://grab.by/cSHA )

- A

Asa Dotzler

unread,
Apr 1, 2012, 1:14:49 PM4/1/12
to
On 4/1/2012 8:29 AM, William Barnacle wrote:
>
> Nice graph. Is it just me, or does the significant change in rate of
> size increase after about 2009, seem to be related to the introduction
> of the rapid release schedule ?

A time focused instead of release focused graph disagrees. See
http://grab.by/cSHO which shows that the rapid releases are no more
likely to add size than the Firfox 3.5 to 4 cycle which was anything but
rapid.

- A

Boris Zbarsky

unread,
Apr 1, 2012, 1:26:45 PM4/1/12
to
On 4/1/12 12:39 AM, Asa Dotzler wrote:
> Is there anything obvious we can do to trim things back down some?

Trade off performance for space and turn off quickstubs and new DOM
bindings.

Rip out support for a few media or font formats.

Change compiler optimization options to focus on size, not speed.

Take out the OpenType sanitizer or the GL sanitizer.

In general, find features which involve too much code and get rid of them...

An actual binary diff showing which symbols have added size would be
needed to say more precisely what those are. We used to run that test
on Tinderbox, but stopped, since it mostly showed us adding features...

> Has it been a steady growth or did it recently spike up?

The former.

> Is this current size acceptable?

By what metric? It's a smaller size than our competitors, last I
checked. There's a limit to how small we can make compiler output
without trading off on performance, in general.

> Is Gecko that much bigger or is it Firefox front-end?

Gecko is a lot bigger, for sure. Whether it accounts for the whole
increase, I don't know.

> Also, our Mac download is over 39MB :\

It also includes two complete copies of Gecko (one 32-bit, one 64-bit),
right?

-Boris

Chris Hofmann

unread,
Apr 1, 2012, 1:39:17 PM4/1/12
to Axel Hecht, dev-apps...@lists.mozilla.org
On 4/1/12 9:53 AM, Axel Hecht wrote:
> On 01.04.12 17:29, William Barnacle wrote:
>> On 01-Apr-12 6:17 AM, Axel Hecht wrote:
>>> On 01.04.12 11:17, Michael Lefevre wrote:
>>>> On 01/04/2012 05:39, Asa Dotzler wrote:
>>>> [...]
>>>>> Is there anything obvious we can do to trim things back down some?

There are a few bug still hanging off the dependency tree of
*Bug 647453* <https://bugzilla.mozilla.org/show_bug.cgi?id=647453> -size
of the windows installer now over 13MB

-chofmann
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Justin Wood (Callek)

unread,
Apr 1, 2012, 11:40:45 PM4/1/12
to Asa Dotzler
Asa Dotzler wrote:
> When we shipped Firefox 1, our Windows installer build was 4.7MB. I
> realize that we've added some nice features and that we're including
> some new DirectX libraries so I didn't expect Firefox to stay that
> small. I am concerned about getting this large, though, and what than
> means for people downloading Firefox, especially on slower connections.

Since Firefox 1 we have shipped with the windows MSVC dll's necessary to
run Firefox with, in the case that our users don't have them installed
already. That is not a low size, but certainly necessary unless we want
to allow users to try launching Firefox and get *very cryptic* error
messages from windows.

We also ship the DirectX redistributable so that WebGL and related
acceleration can work for our users!

> Also, our Mac download is over 39MB :\

That is because our Mac builds are "universal binary" which basically
means we take a version compiled for 32 bit CPU's and one compiled for
64 bit CPU's and "join" them together. It is this magic that makes the
32 bit plugins even work on a 64 bit Mac Firefox (Which is why we would
not want to just drop it even if all our mac users on supported OS's had
64 bit processors)

--
~Justin Wood (Callek)

Gervase Markham

unread,
Apr 2, 2012, 7:32:20 AM4/2/12
to Boris Zbarsky
On 01/04/12 18:26, Boris Zbarsky wrote:
> Trade off performance for space and turn off quickstubs and new DOM
> bindings.
>
> Rip out support for a few media or font formats.

As Boris said... my first thought was that in the last couple of years
particularly we've been adding libraries for media and font formats as
the web platform has gained in features.

If "the web is the platform", 21MB is pretty darn small for an entire
platform!

Gerv

Axel Hecht

unread,
Apr 2, 2012, 8:23:25 AM4/2/12
to
I think we can be probably a tad more critical about what we ship by
default.

I think we're doing the right thing when not looking at UI locale for
hyphenation dicts, but the ones we ship are 2M of source, 1M compressed
(with zip, ballpark number). Devtools is 4M of source, seems < 1M
compressed.

I don't think there are easy wins for both, but I'd think there are some
hard ones.

There are more like this on the horizon, like fully implemention
language tags, ICU data, etc.

Axel

Rob Campbell

unread,
Apr 2, 2012, 9:08:45 AM4/2/12
to Axel Hecht, dev-apps...@lists.mozilla.org

On 2012-04-02, at 09:23 , Axel Hecht wrote:

> On 02.04.12 13:32, Gervase Markham wrote:
>> On 01/04/12 18:26, Boris Zbarsky wrote:
>>> Trade off performance for space and turn off quickstubs and new DOM
>>> bindings.
>>>
>>> Rip out support for a few media or font formats.
>>
>> As Boris said... my first thought was that in the last couple of years
>> particularly we've been adding libraries for media and font formats as
>> the web platform has gained in features.
>>
>> If "the web is the platform", 21MB is pretty darn small for an entire
>> platform!
>
> I think we can be probably a tad more critical about what we ship by default.
>
> I think we're doing the right thing when not looking at UI locale for hyphenation dicts, but the ones we ship are 2M of source, 1M compressed (with zip, ballpark number). Devtools is 4M of source, seems < 1M compressed.
>
> I don't think there are easy wins for both, but I'd think there are some hard ones.

Definitely, though I think there are also some pretty compelling reasons for shipping within Firefox. If we started shipping a "core" Firefox application and included a checkbox installer for various features, we'd be trading off application size for another set of complex variables and, potentially, confusing our users.

When faced with "which types of Fonts do I want to be compatible with?", "WebGL support?", "Developer Tools?" we're assuming users want to able to strip out features and make hard choices about what types of components they install.

If they did, would we also want to include a "maxi" build with everything pre-installed? This is starting to sound like a pretty complex set of release configurations to keep track of.

Something to keep in mind, though I don't think our Developer Tools teams are going to be able to consider migrating all of our features to addons anytime this year.

~ rob

Henri Sivonen

unread,
Apr 2, 2012, 9:20:46 AM4/2/12
to dev-apps...@lists.mozilla.org
On Mon, Apr 2, 2012 at 3:23 PM, Axel Hecht <l1...@mozilla.com> wrote:
>> If "the web is the platform", 21MB is pretty darn small for an entire
>> platform!
>>
>> Gerv

>
> I think we can be probably a tad more critical about what we ship by
> default.
>
> I think we're doing the right thing when not looking at UI locale for
> hyphenation dicts, but the ones we ship are 2M of source, 1M compressed
> (with zip, ballpark number). Devtools is 4M of source, seems < 1M
> compressed.

I think we shouldn't drop the devtools. Chrome and Safari got an edge
over Firefox during the time when they shipped Web Inspector built-in
but for Firefox you had to go and download Firebug separately.

Instead of dropping features, be they Web correctness features like
hyphenation or developer features, I think it makes more sense to
focus on how omnijar is compressed in the installer and how a stub
installer could make the initial download size smaller than to start
dropping features or fragmenting the Firefox feature set by making
stuff optional.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Benoit Jacob

unread,
Apr 2, 2012, 9:29:11 AM4/2/12
to Justin Wood (Callek), dev-apps...@lists.mozilla.org
2012/4/1 Justin Wood (Callek) <Cal...@gmail.com>:
> Asa Dotzler wrote:
>>
>> When we shipped Firefox 1, our Windows installer build was 4.7MB. I
>> realize that we've added some nice features and that we're including
>> some new DirectX libraries so I didn't expect Firefox to stay that
>> small. I am concerned about getting this large, though, and what than
>> means for people downloading Firefox, especially on slower connections.
>
>
> Since Firefox 1 we have shipped with the windows MSVC dll's necessary to run
> Firefox with, in the case that our users don't have them installed already.
> That is not a low size, but certainly necessary unless we want to allow
> users to try launching Firefox and get *very cryptic* error messages from
> windows.
>
> We also ship the DirectX redistributable so that WebGL and related
> acceleration can work for our users!

By the way, it is possible that we might be able to do with only 1 of
the 2 DirectX DLLs we're currently redistributing.
http://code.google.com/p/angleproject/issues/detail?id=311

Benoit

Lawrence Mandel

unread,
Apr 2, 2012, 10:51:19 AM4/2/12
to Asa Dotzler, dev-apps...@lists.mozilla.org
There have been a lot of good thoughts in this thread. I suggest that if the Firefox download size is a concern that we need some concrete proposals of ways to shrink the download size based on data. To me this sounds like a suitable project for a few people to dig in to better understand our options and come back to this list with a proposal. Of course we also need to weigh the priority of this effort against everything else in flight.

Asa - Is download size a metric that you think is worth tracking as part of a quality program (by release drivers)?

Lawrence

Axel Hecht

unread,
Apr 2, 2012, 10:56:18 AM4/2/12
to
My point isn't to drop them or to offer user choice. But I think that
we're starting the download of webdev tools early enough if someone
opens the menu item for 'em. Don't ask, just do it. It can even have the
menu items for the individual tools, so that you have something to stare
at while it installs silently in the background.

Axel

Mike Ratcliffe

unread,
Apr 2, 2012, 11:11:28 AM4/2/12
to dev-apps...@lists.mozilla.org
Bare in mind that anything we remove will no longer be tested by the
default test suite.

L. David Baron

unread,
Apr 2, 2012, 11:15:37 AM4/2/12
to dev-apps...@lists.mozilla.org
On Sunday 2012-04-01 15:17 +0200, Axel Hecht wrote:
> I've gathered the current data from archive, and plotted it vs time,
> http://people.mozilla.org/~axel/Firefox%20sizes.ods.

It probably wouldn't be hard to write a script that looks at the FTP
server [1] to graph the sizes of nightly installer downloads. I
don't have time to do this right now, but it might lead to a graph
that makes it clearer how much of the increase has been continuous
and how much has been certain big things landing.

We could probably also use better regression detection, e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=607552 , but perhaps
also a test that looks at the compressed size of the binary [2]. Though
I also noticed that the graph at
http://graphs.mozilla.org/graph.html#tests=[[31,1,6]]&sel=none&displayrange=365&datatype=running
has been noisy (oscillating between two states) to the point of
being useless.

-David

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

[2] The codesighs test is useful because (a) it gives detailed
information about what increased in size and (b) it avoids
reporting issues related to file segment sizes being limited to
certain round sizes (and, e.g., blaming an 8K regression on the
person who added the last 10 bytes since the last 8K
regression). Looking at compressed file size likely has the
same advantage as (b), though PGO might have its own weird
behavior that quantizes things in certain ways and interferes
with figuring out what's really going on. Note, however, that
Codesighs broken on Windows and was never fixed; see
https://bugzilla.mozilla.org/show_bug.cgi?id=436339 .

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

Johnathan Nightingale

unread,
Apr 2, 2012, 11:23:18 AM4/2/12
to Axel Hecht, dev-apps...@lists.mozilla.org
On 2012-04-02, at 10:56 AM, Axel Hecht wrote:
> My point isn't to drop them or to offer user choice. But I think that we're starting the download of webdev tools early enough if someone opens the menu item...

We're optimizing before profiling, here.

I agree with Lawrence up-thread when he suggests that what would help here is to gather some data and some options, and then figure out how the work necessary to address those stacks against other priorities. Until we have that, I think it's premature to dive in on a particular component or reduction strategy.

On Windows, stub installers are coming for a variety of reasons, of which "initial download size" is an important one, but not the only one. On Mac, I agree that the universal DMGs are a pain, and a smarter solution to that would be a huge win (50%!) for download size on that platform. I further suspect that making file size diffs more visible in, e.g., tryserver test runs might change the slope significantly (as I see dbaron is suggesting in-thread as we speak.)

Does someone want to run with this? I'm not convinced that it's the most important battle we have right now, but it is an important question of hygiene and it absolutely does impact user experience and Firefox adoption. (Last data I saw suggested a surprisingly linear relationship between download size and abandonment rates). Someone picking this up in a methodical way could have a significant effect on the adoption of Firefox, worldwide.

J

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
joh...@mozilla.com




Robert Kaiser

unread,
Apr 2, 2012, 3:17:55 PM4/2/12
to
Axel Hecht schrieb:
> Devtools is 4M of source, seems < 1M
> compressed.

If all the dead code in terms of what we use (e.g. all the stuff to
support non-current or non-Mozilla browsers) is being ripped out of
Orion, I guess devtools would shrink - but then, I guess it would make
it a lot less easy to follow upstream, and getting there would be quite
some work...

Robert Kaiser

Daniel Cater

unread,
Apr 2, 2012, 3:46:39 PM4/2/12
to
I see 2 things that can be done here:

1. Add installer size for each platform to the graph server so diagnosing this is easier in future.

2. Reprioritise the stub installer work. Initially this probably wouldn't decrease the overall size, just the initial download (although this could still be useful on its own if people are abandoning the large downloads before they finish). However, with some work it could allow for only downloading some of the shipped DLLs if they're needed, only downloading developer tools if the user asks for them (as was the way with the old Inspector), only downloading theme and image files for the relevant flavour of Windows etc. and other things that I'm probably not thinking of.

Obviously the full installer would still be available.

Thoughts?

Ron Hunter

unread,
Apr 2, 2012, 5:15:45 PM4/2/12
to
It adds up to about a 2hour download for dialup users, though, and
that's all they see.
Of course, that is for the full download. What is the average size for
updates?

Tim Taubert

unread,
Apr 2, 2012, 5:15:38 PM4/2/12
to dev-apps...@lists.mozilla.org
On 04/02/2012 05:15 PM, L. David Baron wrote:
> On Sunday 2012-04-01 15:17 +0200, Axel Hecht wrote:
> It probably wouldn't be hard to write a script that looks at the FTP
> server [1] to graph the sizes of nightly installer downloads. I
> don't have time to do this right now, but it might lead to a graph
> that makes it clearer how much of the increase has been continuous
> and how much has been certain big things landing.

I wrote a little script which generates json data and created a slightly
modified copy of AWFY [1]. By default it shows the nightly build sizes
for all desktop platforms of the last 30 days.

It's called "are we small yet" for now (slim is already taken and I
couldn't think of anything better) and shows data back to Sep 2011, I'm
currently importing anything up to Jan 2011 which takes quite some time
to complete. The diagram accepts some get parameters [2] to make it more
useful.

- Tim



[1] http://awsy.timtaubert.de/
[2] http://awsy.timtaubert.de/?days=30&step=2&offset=30

--
Tim Taubert
Firefox Engineer
ttau...@mozilla.com

Asa Dotzler

unread,
Apr 3, 2012, 12:53:14 AM4/3/12
to
On 4/2/2012 2:15 PM, Tim Taubert wrote:
> It's called "are we small yet" for now (slim is already taken and I
> couldn't think of anything better) and shows data back to Sep 2011, I'm
> currently importing anything up to Jan 2011 which takes quite some time
> to complete. The diagram accepts some get parameters [2] to make it more
> useful.
>
This is great! Thanks Tim.

- A

Gervase Markham

unread,
Apr 3, 2012, 4:43:48 AM4/3/12
to
On 02/04/12 14:29, Benoit Jacob wrote:
> By the way, it is possible that we might be able to do with only 1 of
> the 2 DirectX DLLs we're currently redistributing.
> http://code.google.com/p/angleproject/issues/detail?id=311

Awesome. File a bug, tracking that one :-)

Gerv

Gervase Markham

unread,
Apr 3, 2012, 4:45:42 AM4/3/12
to Daniel Cater
On 02/04/12 20:46, Daniel Cater wrote:
> I see 2 things that can be done here:

3. Better compression algorithm? Or have we exhausted the options there?

If we install the developer tools on demand, is there a risk of it being
an issue that the user doesn't have sufficient permissions to install them?

Gerv

Benoit Jacob

unread,
Apr 3, 2012, 8:00:47 AM4/3/12
to Gervase Markham, dev-apps...@lists.mozilla.org
2012/4/3 Gervase Markham <ge...@mozilla.org>:
Done:
https://bugzilla.mozilla.org/show_bug.cgi?id=741742

is there a tracking flag or bug I should add to it, to not forget it?

Benoit

>
> Gerv

Chris Hofmann

unread,
Apr 3, 2012, 11:07:03 AM4/3/12
to Benoit Jacob, Gervase Markham, dev-apps...@lists.mozilla.org
On 4/3/12 5:00 AM, Benoit Jacob wrote:
> 2012/4/3 Gervase Markham<ge...@mozilla.org>:
> Done:
> https://bugzilla.mozilla.org/show_bug.cgi?id=741742
>
> is there a tracking flag or bug I should add to it, to not forget it?
>
> Benoit
https://bugzilla.mozilla.org/show_bug.cgi?id=647453

Robert Kaiser

unread,
Apr 3, 2012, 1:29:55 PM4/3/12
to
Tim Taubert schrieb:
> It's called "are we small yet" for now

Nice, the "are we ... yet" meme is continuing! :)

(I myself have set up arewestableyet.com recently - still somewhat in
prototype mode, in case anyone wonders)

Robert Kaiser

Gary Kwong

unread,
Apr 11, 2012, 6:34:19 PM4/11/12
to
> 3. Better compression algorithm? Or have we exhausted the options there?

I think we use 7-Zip / LZMA? to compress the installer. LZMA2 has
recently been released [1] but requires 7-Zip to be updated.

Not only that, we've had regressions associated with updating 7-Zip too,
but its bug number currently eludes me.

-Gary

[1] http://www.7-zip.org/

Robert O'Callahan

unread,
Apr 11, 2012, 7:31:56 PM4/11/12
to
On Sunday, 1 April 2012 16:39:04 UTC+12, Asa Dotzler wrote:
> Is there anything obvious we can do to trim things back down some? Has
> it been a steady growth or did it recently spike up? Is this current
> size acceptable? (I don't think it is.) Do we have any data that
> correlates completed downloads with download size over the last few
> years? Where in the product is this growth? Is Gecko that much bigger or
> is it Firefox front-end?

The Chrome download is much larger than ours; is that hurting them at all?

Chris AtLee

unread,
Apr 13, 2012, 9:05:02 PM4/13/12
to
I've been poking at https://bugzilla.mozilla.org/show_bug.cgi?id=641212
to add xz support to the updater. We can shave at least 10% off the
partial/complete update using xz compression instead of bz2.
0 new messages