10 ms·

Measuring the memory usage of popular web apps

161 points by dsr12 8y ago

fouc 8y ago
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.
- KyeRussell 8y ago
  I'm not convinced that such a number could be calculated in such a way that wouldn't be utterly meaningless to all but the biggest nerds. The resources a 'web app' 'should' use is highly context dependent. As a web developer, I can determine some of that context, as I know what functionality is resource intensive. I don't think that you can distill that down in any useful way.
  - pdkl95 8y ago
    > such a number could be calculated Compute this from the start of page load. Adjust the scale of the final output if desired. # automatically scaled to local hardware # in units the user actually experiences t := "total wall-clock CPU time used (in ms)" # yes, allocations - NOT total usage m := "Total heap allocations (in kB/kiB)" # magnitude of about:blank a := typical_m_for("about:blank") * typical_t_for("about:blank") # score is computed similar to decibel score := 10 * log10( (m * t) / a ) A variant of the score that excludes media data in <audio> or <video> tags should also be computed. Both versions should be presented. Continuously update these numbers, so the user can see the impact of any background JS/etc. > utterly meaningless to all but the biggest nerds Please don't assume people are stupid. If you give people real data consistently and it affects their life, they will figure out how to use it. Their interpretation may not be technically rigorous, but it will mean something to them. Also, most people will understand and expect the score for youtube to be (much) larger than a messaging service like twitter and both larger than a simple static text-only page. > as I know what functionality is resource intensive You only know this an isolated abstract sense. You do NOT know how much network bandwidth, CPU time, or RAM the user actually has available and wishes to use for you page. They may be using their bandwidth for other important things on another computer. Their RAM an CPU might be needed for other uses - inside or outside the browser. Approximately nobody only uses one application at a time. Your app or webpage is almost always going to be competing for resources in an environment you do not control and can never truly understand (you do not know the user's ultimate goals, environment, or requirements/restrictions).
- onion2k 8y ago
  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.
  - snaky 8y ago
    That's not about right or wrong, and by the way, the proposed indicator indicates numbers, not wrongness level. I'd add to it the slider "cache this app more-less", because you know how do you usually use this app or page. And the "complain" button with auto-redirect to some support, or uservoice form of this app, if there is any, when e.g. I moved the slider to the "less" as possible and even then it still eats 200 megabytes of RAM.
  - chrismorgan 8y ago
    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 8y ago
      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.
- natecavanaugh 8y ago
  I'm wondering if this could be made a relative score instead of an absolute one that measures the current site's memory consumption relative to your available free memory. It might be more useful to see the impact it has for you.
- shaki-dora 8y ago
  That seems like a convoluted scheme to get "normal" people to care about something that you care a lot about, and they don't. They don't care because it's not a problem for them. Yeah, maybe they could have bought a cheaper phone if everyone had spend twice as much time writing the code. But hardware advances have actually caught up with requirements (and then some), and all these sites work fine on even lower-end current phones. You care about it like a watchmaker cares about the mechanical drive of his watch. They don't need a watch. They have smartphone. It's 8 magnitudes more precise than your mechanical watch.
  - TeMPOraL 8y ago
    It is absolutely a problem for them. It is what makes them pissed off and ruining my day by getting in anger fits over how their phone is shit (it's not their phone - it's the accumulated bloat of the apps they use). It's what makes them buy a new computer ("my old one was too slow"). It's just regular users know so little about technology that they accept what they're given without any question. "Thinks work slow so it's definitely the fault of my computer, maybe it has viruses".
    - kpcyrd 8y ago
      I was about to say this. Computers are not getting slower over time, the programs get worse over time.
  - rectang 8y ago
    I care about bandwidth because I don't have unlimited data on my mobile plan. I wish I knew how much each site/domain was costing me. Then I could have a better idea which sites are profligate wastrels to be avoided and which sites I can feel free to visit at will.
    - sbr464 8y ago
      I agree, but I believe this is referring to memory usage, not data transfer/usage over the network. But that number would be interesting if more readily available.
- prplhaz4 8y ago
  I use the uBlock origin badge in my browser as a proxy for making page judgements - I avoid revisiting sites with a high number (>5?) of blocked elements...
lunaru 8y ago
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/
- mook 8y ago
  I wonder how Gmail as it originally came out (during the invite-only stage) compares to Gmail now? That already had a lot of the functionality (but not, say, chat). Of course, it's rather difficult to go back in time to measure the old interface now.
- tannhaeuser 8y ago
  > 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.
  - anewhnaccount2 8y ago
    >There's got to be a special name for this kind of logical fallacy. Similar to https://en.m.wikipedia.org/wiki/Just-world_hypothesis https://en.m.wikipedia.org/wiki/Just-world_hypothesis perhaps?
grawlinson 8y ago
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)
kenhwang 8y ago
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 8y ago
  gmail at 158, facebook at 56. I don't think React is the problem.
  - CapacitorSet 8y ago
    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.
    - tandav 8y ago
      basic HTML gmail link (fast AF) https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui
    - chrismorgan 8y ago
      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.
Apocryphon 8y ago
Curious how Discord compares to Slack.
alexmat 8y ago
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 8y ago
  I just use it as aggregator from my mail accounts. 90% of the time I use it via IMAP, quite snappy indeed.
amanzi 8y ago
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 8y ago
  > 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.
  - bumblebritches5 8y ago
    > 50MB of free RAM More like 500
suixo 8y ago
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 8y ago
  > 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-usage/ https://addons.mozilla.org/en-GB/firefox/addon/tab-memory-us... 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.
bartread 8y ago
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.
magnat 8y ago
hacker news (if you can call HN a web app) 0.88
EZ-E 8y ago
"Memory is cheap!" is the new "Storage is cheap!"
- LandR 8y ago
  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 8y ago
    It works on my 2GB ram phone?
    - TeMPOraL 8y ago
      Probably not. Your phone is old. 4GB is the new minimum.
- tinus_hn 8y ago
  Your memory is cheap for me!
pdkl95 8y ago
> 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 8y ago
  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/patch-1 https://github.com/ianchanning/your-web-app-is-bloated/tree/...
  - sbr464 8y ago
    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 8y ago
      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
swebs 8y ago
Here's a graph of that data: https://i.imgur.com/smpvriF.png https://i.imgur.com/smpvriF.png
have_faith 8y ago
How does it compare to their desktop counterparts?
- interfixus 8y ago
  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'.
TheBeardKing 8y ago
I'd like to see the new reddit vs the old reddit.
- chrismorgan 8y ago
  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).
icc97 8y ago
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 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - paulddraper 8y ago
    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/closure/goog/structs/map.js#L51 https://github.com/google/closure-library/blob/master/closur...
- ebikelaw 8y ago
  The very lightweight HTML Gmail lacks all of "normal" Gmail's latency-hiding features, which is one reason it uses so little memory. Gmail preloads all of the messages in the thread list so when you click them they are displayed instantly. HTML Gmail doesn't, and when you click a message it fetches the body from the origin. The tradeoff is yours to make. I find the HTML version infuriating when I'm tethered on mobile because every mouse click takes 10 seconds. On the same tether I can leave normal Gmail open all the time and it's fast. Ironically the lightweight Gmail is more usable on a fast, reliable wired connection.
nottorp 8y ago
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.
chrismorgan 8y ago
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.
at-fates-hands 8y ago
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.
cozzyd 8y ago
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.
samirm 8y ago
Why did you leave ublock on? Kinda defeats the purpose...
nine_k 8y ago
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.

161 points by dsr12 8y ago

fouc 8y ago

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.

KyeRussell 8y ago
I'm not convinced that such a number could be calculated in such a way that wouldn't be utterly meaningless to all but the biggest nerds. The resources a 'web app' 'should' use is highly context dependent. As a web developer, I can determine some of that context, as I know what functionality is resource intensive. I don't think that you can distill that down in any useful way.
- pdkl95 8y ago
  > such a number could be calculated Compute this from the start of page load. Adjust the scale of the final output if desired. # automatically scaled to local hardware # in units the user actually experiences t := "total wall-clock CPU time used (in ms)" # yes, allocations - NOT total usage m := "Total heap allocations (in kB/kiB)" # magnitude of about:blank a := typical_m_for("about:blank") * typical_t_for("about:blank") # score is computed similar to decibel score := 10 * log10( (m * t) / a ) A variant of the score that excludes media data in <audio> or <video> tags should also be computed. Both versions should be presented. Continuously update these numbers, so the user can see the impact of any background JS/etc. > utterly meaningless to all but the biggest nerds Please don't assume people are stupid. If you give people real data consistently and it affects their life, they will figure out how to use it. Their interpretation may not be technically rigorous, but it will mean something to them. Also, most people will understand and expect the score for youtube to be (much) larger than a messaging service like twitter and both larger than a simple static text-only page. > as I know what functionality is resource intensive You only know this an isolated abstract sense. You do NOT know how much network bandwidth, CPU time, or RAM the user actually has available and wishes to use for you page. They may be using their bandwidth for other important things on another computer. Their RAM an CPU might be needed for other uses - inside or outside the browser. Approximately nobody only uses one application at a time. Your app or webpage is almost always going to be competing for resources in an environment you do not control and can never truly understand (you do not know the user's ultimate goals, environment, or requirements/restrictions).
onion2k 8y ago
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.
- snaky 8y ago
  That's not about right or wrong, and by the way, the proposed indicator indicates numbers, not wrongness level. I'd add to it the slider "cache this app more-less", because you know how do you usually use this app or page. And the "complain" button with auto-redirect to some support, or uservoice form of this app, if there is any, when e.g. I moved the slider to the "less" as possible and even then it still eats 200 megabytes of RAM.
- chrismorgan 8y ago
  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 8y ago
    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.
natecavanaugh 8y ago
I'm wondering if this could be made a relative score instead of an absolute one that measures the current site's memory consumption relative to your available free memory. It might be more useful to see the impact it has for you.
shaki-dora 8y ago
That seems like a convoluted scheme to get "normal" people to care about something that you care a lot about, and they don't. They don't care because it's not a problem for them. Yeah, maybe they could have bought a cheaper phone if everyone had spend twice as much time writing the code. But hardware advances have actually caught up with requirements (and then some), and all these sites work fine on even lower-end current phones. You care about it like a watchmaker cares about the mechanical drive of his watch. They don't need a watch. They have smartphone. It's 8 magnitudes more precise than your mechanical watch.
- TeMPOraL 8y ago
  It is absolutely a problem for them. It is what makes them pissed off and ruining my day by getting in anger fits over how their phone is shit (it's not their phone - it's the accumulated bloat of the apps they use). It's what makes them buy a new computer ("my old one was too slow"). It's just regular users know so little about technology that they accept what they're given without any question. "Thinks work slow so it's definitely the fault of my computer, maybe it has viruses".
  - kpcyrd 8y ago
    I was about to say this. Computers are not getting slower over time, the programs get worse over time.
- rectang 8y ago
  I care about bandwidth because I don't have unlimited data on my mobile plan. I wish I knew how much each site/domain was costing me. Then I could have a better idea which sites are profligate wastrels to be avoided and which sites I can feel free to visit at will.
  - sbr464 8y ago
    I agree, but I believe this is referring to memory usage, not data transfer/usage over the network. But that number would be interesting if more readily available.
prplhaz4 8y ago
I use the uBlock origin badge in my browser as a proxy for making page judgements - I avoid revisiting sites with a high number (>5?) of blocked elements...

lunaru 8y ago

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/

mook 8y ago
I wonder how Gmail as it originally came out (during the invite-only stage) compares to Gmail now? That already had a lot of the functionality (but not, say, chat). Of course, it's rather difficult to go back in time to measure the old interface now.
tannhaeuser 8y ago
> 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.
- anewhnaccount2 8y ago
  >There's got to be a special name for this kind of logical fallacy. Similar to https://en.m.wikipedia.org/wiki/Just-world_hypothesis https://en.m.wikipedia.org/wiki/Just-world_hypothesis perhaps?

grawlinson 8y ago

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)

kenhwang 8y ago

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 8y ago
gmail at 158, facebook at 56. I don't think React is the problem.
- CapacitorSet 8y ago
  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.
  - tandav 8y ago
    basic HTML gmail link (fast AF) https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui
  - chrismorgan 8y ago
    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.

Apocryphon 8y ago

Curious how Discord compares to Slack.

alexmat 8y ago

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 8y ago
I just use it as aggregator from my mail accounts. 90% of the time I use it via IMAP, quite snappy indeed.

amanzi 8y ago

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 8y ago
> 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.
- bumblebritches5 8y ago
  > 50MB of free RAM More like 500

suixo 8y ago

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 8y ago
> 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-usage/ https://addons.mozilla.org/en-GB/firefox/addon/tab-memory-us... 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.

bartread 8y ago

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.

magnat 8y ago

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

EZ-E 8y ago

"Memory is cheap!" is the new "Storage is cheap!"

LandR 8y ago
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 8y ago
  It works on my 2GB ram phone?
  - TeMPOraL 8y ago
    Probably not. Your phone is old. 4GB is the new minimum.
tinus_hn 8y ago
Your memory is cheap for me!

pdkl95 8y ago

> 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 8y ago
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/patch-1 https://github.com/ianchanning/your-web-app-is-bloated/tree/...
- sbr464 8y ago
  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 8y ago
    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

swebs 8y ago

Here's a graph of that data: https://i.imgur.com/smpvriF.png https://i.imgur.com/smpvriF.png

have_faith 8y ago

How does it compare to their desktop counterparts?

interfixus 8y ago
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'.

TheBeardKing 8y ago

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

chrismorgan 8y ago
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).

icc97 8y ago

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 8y ago
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.
- deleted 8y ago
  [deleted]
- paulddraper 8y ago
  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/closure/goog/structs/map.js#L51 https://github.com/google/closure-library/blob/master/closur...
ebikelaw 8y ago
The very lightweight HTML Gmail lacks all of "normal" Gmail's latency-hiding features, which is one reason it uses so little memory. Gmail preloads all of the messages in the thread list so when you click them they are displayed instantly. HTML Gmail doesn't, and when you click a message it fetches the body from the origin. The tradeoff is yours to make. I find the HTML version infuriating when I'm tethered on mobile because every mouse click takes 10 seconds. On the same tether I can leave normal Gmail open all the time and it's fast. Ironically the lightweight Gmail is more usable on a fast, reliable wired connection.

nottorp 8y ago

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.

chrismorgan 8y ago

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.

at-fates-hands 8y ago

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.

cozzyd 8y ago

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.

samirm 8y ago

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

nine_k 8y ago

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.