Mostly due to JavaScript, though styling can be a problem too; the gmail stylesheets have a huge number of rules (over 10,000), with a fair amount of duplication in them. For example, gmail has about 4600 rules that all set a background-image of "//ssl.gstatic.com/chat/emoji/png28-7f9d3a5045813584f828fe69a1fecb77.png" according to <https://bugzilla.mozilla.org/show_bug.cgi?id=1397971#c0>. You can see some data on the styling end in https://bugzilla.mozilla.org/show_bug.cgi?id=1392314 and its dependencies.
Anyway, I just tried loading gmail in Firefox, pulling up about:memory, and measuring. The overall gmail window takes about 125MB of RAM over here, not counting its images. Style data is about 27MB of that. Another 11.5MB is DOM (6MB of textnodes). Most of the rest is JavaScript.
And _boy_ is there a lot of JavaScript. I'm seeing a 15MB arraybuffer from a hangouts iframe (why is that there by default on gmail? I've never used hangouts!). 2MB of just Function objects on gmail itself, out of 10MB total for JS bits. 8MB of objects/functions/arrays for _another_ hangouts iframe. 4MB of JS stuff for a notifications.google.com iframe.
Note that a lot of the style and DOM bits above were _also_ for the hangouts iframes. Just eyeballing it, about half the memory gmail is using over here is actually for those hangouts iframes...
Oh, and none of that includes the strings. There's 10MB of strings, including at least three more or less identical-looking strings with nearly 1 million characters each that look like stylesheet text. And then another 500k-character stylesheet-text string.... And yes, I just forced a full GC and those strings are still there; gmail is keeping them around somehow.
It could probably specify the background image only once in a rule that matches all the relevant things and then specify the background positions separately. Sure would be more efficient without the browser having to jump through hoops to deduplicate the url.
I wonder how much longer it'll be before we re-invent the wheel yet again and mobile things actually have cached library version hell like Windows DLLs became? Are we already there (or is it too optimistic for me to assume that the /exact/ same version of a library can be referenced and de-duplicated)?
