|Firefox download size||Asa Dotzler||3/31/12 9:39 PM|
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 :\
|Re: Firefox download size||Michael Lefevre||4/1/12 2:17 AM|
On 01/04/2012 05:39, Asa Dotzler wrote:
> Is there anything obvious we can do to trim things back down some? HasIt'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
|Re: Firefox download size||Axel Hecht||4/1/12 6:17 AM|
I've gathered the current data from archive, and plotted it vs time,
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
|Re: Firefox download size||William Barnacle||4/1/12 8:29 AM|
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 ?
|Re: Firefox download size||Axel Hecht||4/1/12 9:53 AM|
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.
|Re: Firefox download size||Asa Dotzler||4/1/12 10:08 AM|
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 )
|Re: Firefox download size||Asa Dotzler||4/1/12 10:14 AM|
On 4/1/2012 8:29 AM, William Barnacle wrote: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
|Re: Firefox download size||Boris Zbarsky||4/1/12 10:26 AM|
On 4/1/12 12:39 AM, Asa Dotzler wrote:Trade off performance for space and turn off quickstubs and new DOM
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...
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.
Gecko is a lot bigger, for sure. Whether it accounts for the whole
increase, I don't know.
It also includes two complete copies of Gecko (one 32-bit, one 64-bit),
|Re: Firefox download size||Chris Hofmann||4/1/12 10:39 AM|
On 4/1/12 9:53 AM, Axel Hecht wrote: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
> dev-apps-firefox mailing list
|Re: Firefox download size||Justin Wood (Callek)||4/1/12 8:40 PM|
Asa Dotzler wrote: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!
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)
|Re: Firefox download size||Gervase Markham||4/2/12 4:32 AM|
On 01/04/12 18:26, Boris Zbarsky wrote: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
|Re: Firefox download size||Axel Hecht||4/2/12 5:23 AM|
I think we can be probably a tad more critical about what we ship by
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
I don't think there are easy wins for both, but I'd think there are some
There are more like this on the horizon, like fully implemention
language tags, ICU data, etc.
|Re: Firefox download size||Rob Campbell||4/2/12 6:08 AM|
> I think we can be probably a tad more critical about what we ship by default.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.
|Re: Firefox download size||Henri Sivonen||4/2/12 6:20 AM|
On Mon, Apr 2, 2012 at 3:23 PM, Axel Hecht <l1...@mozilla.com> wrote: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
|Re: Firefox download size||Benoit Jacob||4/2/12 6:29 AM|
2012/4/1 Justin Wood (Callek) <Cal...@gmail.com>:
> Asa Dotzler 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.
|Re: Firefox download size||Lawrence Mandel||4/2/12 7:51 AM|
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)?
|Re: Firefox download size||Axel Hecht||4/2/12 7:56 AM|
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.
|Re: Firefox download size||Mike Ratcliffe||4/2/12 8:11 AM|
Bare in mind that anything we remove will no longer be tested by the
default test suite.
|Re: Firefox download size||L. David Baron||4/2/12 8:15 AM|
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  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 . Though
I also noticed that the graph at
has been noisy (oscillating between two states) to the point of
 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
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
|Re: Firefox download size||Johnathan Nightingale||4/2/12 8:23 AM|
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.
Sr. Director of Firefox Engineering
|Re: Firefox download size||Robert Kaiser||4/2/12 12:17 PM|
Axel Hecht schrieb:
> Devtools is 4M of source, seems < 1MIf 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
|Re: Firefox download size||Daniel Cater||4/2/12 12:46 PM|
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.
|Re: Firefox download size||Ron Hunter||4/2/12 2:15 PM|
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
|Re: Firefox download size||Tim Taubert||4/2/12 2:15 PM|
On 04/02/2012 05:15 PM, L. David Baron wrote:
> It probably wouldn't be hard to write a script that looks at the FTPI wrote a little script which generates json data and created a slightly
modified copy of AWFY . 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  to make it more
|Re: Firefox download size||Asa Dotzler||4/2/12 9:53 PM|
On 4/2/2012 2:15 PM, Tim Taubert wrote:
|Re: Firefox download size||Gervase Markham||4/3/12 1:43 AM|
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.
Awesome. File a bug, tracking that one :-)
|Re: Firefox download size||Gervase Markham||4/3/12 1:45 AM|
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?
|Re: Firefox download size||Benoit Jacob||4/3/12 5:00 AM|
2012/4/3 Gervase Markham <ge...@mozilla.org>:
is there a tracking flag or bug I should add to it, to not forget it?
> dev-apps-firefox mailing list
|Re: Firefox download size||Chris Hofmann||4/3/12 8:07 AM|
On 4/3/12 5:00 AM, Benoit Jacob wrote:https://bugzilla.mozilla.org/show_bug.cgi?id=647453
|Re: Firefox download size||Robert Kaiser||4/3/12 10:29 AM|
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)
|Re: Firefox download size||Gary Kwong||4/11/12 3:34 PM|
> 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  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.
|Re: Firefox download size||Robert O'Callahan||4/11/12 4:31 PM|
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?
|Re: Firefox download size||Chris AtLee||4/13/12 6:05 PM|
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.