
Measuring the memory usage of popular web apps - dsr12
https://github.com/dominictarr/your-web-app-is-bloated
======
pdkl95
> 25.09

Twenty five _what?_ Megabytes? Mebibytes? Percent? Libraries of Congress?
Furlongs per fortnight? Inverse femtobarns?

I can guess you mean "MiB" (mebibytes) from the charts, but units are always
important. Bare numbers leads to confusion! It's good practice to always
include units, even if it's a simple "All numbers are in MiB" at the top.

~~~
icc97
I guess that its MB, I've created a PR with the list reformatted as a table
with the MB column right-aligned so the data is more scannable:
[https://github.com/ianchanning/your-web-app-is-
bloated/tree/...](https://github.com/ianchanning/your-web-app-is-
bloated/tree/patch-1)

~~~
sbr464
It's Mebibytes (megabinary) from the units in the pictures, so it's slighty
more in megabytes. 1MiB = 1.04858MB

So Google Inbox actually uses 225.4447 MB

~~~
icc97
I've just updated the table header to reflect that it's MiB - plus its sorted
now. Interesting to see is Google Inbox at the top vs Gmail (vintage) at the
bottom

------
chrismorgan
My FastMail accounts (personal and work) tend to sit stably around 10–12MB
(when open for days) if I have only opened the mail part, and nudge up to
15–17MB if I have also opened the calendar, settings and address book (which
are modules loaded separately on request). As you would imagine, large emails
will inevitably increase the memory footprint while they’re loaded, until they
perhaps get evicted from the LRU cache after viewing many more emails.

This is what comes of _caring_ about performance and memory footprint. It
doesn’t hurt also that almost all of it has been done by one guy rather than
having fifty or more people all adding, adding, adding in uncontrolled
fashion.

And Topicbox, our group email (mailing lists) product, is using 7–8MB for
browsing archives. (It’s definitely simpler than FastMail.)

Somehow, large teams like Gmail’s, which have vastly more resources than us,
are never good at memory usage, and seldom good at performance. I have some
vague ideas about why this is, but it’s initially quite counterintuitive. It
does seem to be a fairly consistent observation, though: small teams actually
have a big advantage in such matters.

I’m almost sad that this was all under control before I started working at
FastMail early last year, because it’s hard to justify improving it further,
and I do find optimising things like memory usage and running performance to
be such fun. (I know of a couple of ways memory usage and startup performance
could made reduced; but the main thing for startup performance will be service
workers and a persistent data cache.)

Meanwhile, I often have to interact with a Jenkins instance with a plugin that
has a habit of redrawing a large table from scratch every second or two when a
build is running, _and keeping a reference to the orphaned DOM node_. It can
consume almost a gigabyte an hour.

------
icc97
Wow talk about memory usage expansion:

Gmail vintage (0.8 MiB) -> Gmail (158 MiB) -> Inbox (215 MiB)

I feel a desire to switch back to the original HTML version - credit to Google
for keeping it going. Here's the handy support page [0] with a link to convert
back.

Edit: it appears you just need the `/h` appended to the URL [1]

[0]:
[https://support.google.com/mail/answer/15049?hl=en](https://support.google.com/mail/answer/15049?hl=en)

[1]: [https://mail.google.com/mail/u/0/h](https://mail.google.com/mail/u/0/h)

~~~
at-fates-hands
Wasn't this the initial reason gmail was designed? It had a small footprint
and wasn't a performance hog which made it fast, responsive and easy to use?

I've read lately Inbox is probably going away after the recent gmail redesign
which is incorporating some of Inbox's features.

~~~
paulddraper
Gmail's innovation was being a high quality web based email client.

It wasn't necessarily "fast" compared to a native client but was optimized
enough to run in slow browsers.

And with crazy optimizations too. IE6 has bad memory performance for for-in
loops. So instead it implement custom key-value structures
[https://github.com/google/closure-
library/blob/master/closur...](https://github.com/google/closure-
library/blob/master/closure/goog/structs/map.js#L51)

------
bartread
This is interesting, but it's not the whole story. Apps that are media heavy
can often use large amounts of memory outside the JavaScript heap.

E.g., if you load and decode a 3MB MP3 with the Web Audio API you can easily
find yourself swallowing 30MB of RAM, depending upon the uncompressed sample
rate. Another example: image decompression can lead to large amounts of GPU
memory being swallowed.

You can see the effect of situations like this by using Chrome Task Manager,
which will give you a more realistic view of total memory usage by a page.

------
amanzi
Nice to see The Guardian so low, especially compared the NYTimes. I often come
across issues with the NYT where the page starts to load and then just goes
completely blank.

I think overall this list is a good indication of sites that have respect for
their users.

~~~
shaki-dora
> where the page starts to load and then just goes completely blank.

That's almost certainly a bug on your end. You do have 50MB of free RAM
available, right? Other than actually running out of memory (and swap), normal
usage should never result in a no-render.

My best guess would be a content blocker interfering.

------
fouc
What if the browser had visible page score next to the search field?

It could be a score based on asset sizes, memory impact, cpu impact, etc.

By making it visible, people would be more cognizant of which sites have poor
experiences or have a big impact on their computer.

~~~
onion2k
_By making it visible, people would be more cognizant of which sites have poor
experiences or have a big impact on their computer._

You can't simplify this problem down to "This uses more RAM than an arbitrary
threshold therefore it's a problem." If I spend 99% of my time using an app
then I _want_ it to cache hundreds of megabytes of data in to memory so I can
work fast. Saying it's a bad experience if it does that is wrong.

~~~
chrismorgan
Take a particularly bad example: Gmail uses over 150MB of RAM, and achieves
similar results to what FastMail does with 11MB. The main difference is that
Gmail includes the Hangouts chat system—and indeed, last time I checked
Hangouts was responsible for most of the megabytes downloaded, most of the
time spent and most of the memory consumed. Suppose then we decide to let
Hangouts off scot-free for its profligacy, calling it 50% of the footprint,
and just focus on comparing the email part of the system.

Gmail is still using an estimated 80MB for what FastMail needs only 11MB for.

Where is this 80MB coming from? Is it caching 80MB of emails? I think not.
You’ll be lucky if that 80MB corresponds to even half a megabyte of email.

Most high memory usage is not because it’s caching things so it can work fast.
Most high memory usage is simply because the app is inefficient.

~~~
pathartl
I'd be interested to see how the offline capability of Gmail ties into this.
Whatever it uses, localstorage or service workers or whatever, it does a
pretty dang good job.

~~~
chrismorgan
I can’t speak about how Gmail’s offline functionality works, but I would
expect it to be broadly similar to the basic approach we’re planning on in
FastMail, which is that you start by simply adding a persistent cache. There’s
already a robust object syncing protocol in place (JMAP), and you already have
what amounts to simple tables (Mailbox, Email, CalendarEvent, _& c._), so all
that’s really changing is that you’re moving most of that cache onto disk
rather than keeping it in memory. Most likely, content is moved out of the JS
heap into an IndexedDB. I’m not sure what the memory characteristics of
IndexedDB are yet, but at least theoretically that should be memory that can
easily be freed, because it’s all flushed to disk. There’s the possibility
that the browser may keep more in memory than is necessary, but I would
actually expect memory to be a little _lower_ in the presence of service
workers, rather than higher.

------
kenhwang
It's definitely noticeable on the Google/Facebook/Twitter properties, which is
unfortunate because they're the ones behind a lot of the tech (and ads)
commonly used across the web.

I wonder how much of the bloat comes from everyone using
React/Angular/Polymer/Bootstrap and the layers and layers of libraries and
another DOM and rendering engine.

~~~
acchow
gmail at 158, facebook at 56.

I don't think React is the problem.

~~~
CapacitorSet
It's hard to tell, to be fair. We don't know whether a React version of Gmail
(equally maintained etc.) would use more or less RAM.

~~~
chrismorgan
FastMail uses our in-house framework Overture, which doesn’t use a VDOM, but
rather uses computed properties with explicitly-declared dependencies,
observers, and things like that. It’s definitely more effort to work in, but
the results speak for themselves: it’s markedly faster than anything done in
React or Angular or similar, and uses around 11MB of memory.

------
cozzyd
They should have left gmail open for a long time. On my workstation (Firefox
Quantum on Centos 7), it eats gobs of memory over time.

------
nottorp
That's nice, but now please do the same after having that tab open in the
browser for 24 hours... it's unbelievable how much memory some crap (i'm
looking at you google docs) can leak.

------
alexmat
Best part of dropping Gmail is how snappy roundcube feels. I'm way more
productive. The only thing I miss is being able to snooze emails.

~~~
pjmlp
I just use it as aggregator from my mail accounts.

90% of the time I use it via IMAP, quite snappy indeed.

------
swebs
Here's a graph of that data:

[https://i.imgur.com/smpvriF.png](https://i.imgur.com/smpvriF.png)

------
nine_k
One of the sources of bloat may be not just apps, but also extensions.

E.g. I see the Okta authentication extension (which is a required part of work
setup) spending nearly a hundred megs after prolonged usage in Firefox. Mong
other things, it appears to allocate a lot of identical strings (like 500M of
them), likely by a thoughtless `substring` call somewhere.

------
grawlinson
I'd be interested in the methodology and whether the following was taken into
consideration:

1\. Was the cache emptied before each test? (A lot of these sites would share
scripts on CDNs)

2\. What Firefox addons were enabled? (README says that uBlock was active, so
that definitely has an effect)

------
EZ-E
"Memory is cheap!" is the new "Storage is cheap!"

~~~
LandR
Ive had this conversation with devs at work, they just don't care about memory
/ perf in general really.

It's the attitude of if it works who cares how much memory it uses.

Or when I bring up allocations in something like .net, I get don't worry about
it .NET GC will sort it out eventually.

Modern developers....

~~~
AstralStorm
It works on my 2GB ram phone?

~~~
TeMPOraL
Probably not. Your phone is old. 4GB is the new minimum.

------
suixo
Awesome analysis, quite instructive. I am even considering adding it to my
server performance tool, as a frontend performance metric, since I guess it
could be easily automated. Imagine little README badges saying "quite bloated"
and "pretty good" :p

~~~
dspillett
_> since I guess it could be easily automated_

Certainly at the add-on level, as I presume this is how
[https://addons.mozilla.org/en-GB/firefox/addon/tab-memory-
us...](https://addons.mozilla.org/en-GB/firefox/addon/tab-memory-usage/) is
implemented.

If feeding this back to use as a general performance metric, you would have to
be very careful to make sure you were measuring the same thing each time which
for a complex application could be difficult unless you are only measuring on
initial page load (which might not be as useful as you are hoping for).
Without this control you would need a lot of results to make any average or
other analysis of the metric meaningful.

For controlled tests run by yourself in dev (rather than a performance metric
for your app in production) it could be useful though.

------
TheBeardKing
I'd like to see the new reddit vs the old reddit.

~~~
chrismorgan
Opened [https://www.reddit.com/](https://www.reddit.com/) in Private Browsing
and measured it after some ten or fifteen seconds, 92.69MB (38MB of objects—of
which 16MB is ArrayBuffer—33MB of scripts, 7MB of DOM nodes, 5MB of other, 2MB
of strings).

[https://old.reddit.com/](https://old.reddit.com/), 13.70MB (1MB of scripts,
1MB of other, 2MB of objects, 6MB of DOM nodes, 782KB of strings).

------
at-fates-hands
I know Google adding load times into their algorithm for SERP's a while ago.
It would be nice if they added the same thing for memory usage.

------
samirm
Why did you leave ublock on? Kinda defeats the purpose...

------
have_faith
How does it compare to their desktop counterparts?

~~~
interfixus
Their _desktop counterparts_ will more likely than not be the exact same
shoddily thrown together heap of disjointed third party bloat, for the
occasion bundled with the affront to professional developer pride and
integrity known as ' _Electron_ '.

------
magnat
hacker news (if you can call HN a web app) 0.88

------
Apocryphon
Curious how Discord compares to Slack.

------
lunaru
The web has come a long way and expectations from consumers have evolved over
the years. While admittedly a lot of the bloat likely comes from negative
things like trackers, ads, etc there are also assets loaded on a typical page
that genuinely enhance the user experience. On the list, Google Mail scores
the highest in terms of bloat, but it's a full web app and daily users
probably have come to be spoiled on some of the UX niceness that makes Google
Mail enjoyable to use. Users would rather have that vs a plain HTML page with
links. The empirical evidence is clear on that, otherwise the web would not
have evolved as it did.

Software is built on layers of abstraction[0], and necessarily, there will be
bloat as a byproduct of layering. If we had to map out complexity of what's
really going on in a typical computer, the "bloat" floating at the top layer
caused by JavaScript would be put to shame by the complexity in the underlying
browser and the OS underneath that, all of which arguably are too "bloated"
for 90% of daily use.

[0] [https://xkcd.com/676/](https://xkcd.com/676/)

~~~
tannhaeuser
> _Users would rather have [bloated JS webmail] vs a plain HTML page with
> links. The empirical evidence is clear on that, otherwise the web would not
> have evolved as it did._

There's got to be a special name for this kind of logical fallacy.

> _Software is built on layers of abstraction, and necessarily, there will be
> bloat as a byproduct of layering._

Except we're layering less powerful, less abstracted APIs over an already
high-level document model, or we're layering a primitive record access API
over SQL.

~~~
TeMPOraL
> _There 's got to be a special name for this kind of logical fallacy._

Voting-with-your-wallet fallacy?

Users choose from what's available on the market. Between high marketing,
network effects and lack of technical understanding of the average user, there
is close to _zero_ feedback going back to service providers. The providers get
to unilaterally decide what's on the market, and users have no choice but to
take it.

