Keep in mind this is memory used by a browser tab, not "how bug the website is". Probably a memory leak as the feed is scrolled or something, but it is a massive download when you first load the page.

I'm seeing 72MB in the network tab (7MB transferred--that's due to compression). An incredible 10MB is HTML (800K transferred), a more incredible 11MB of CSS (500K transferred), 25MB of JS (3MB transferred), 16MB XHR (1MB), 17MB images (1.7MB transferred).

A lot of the HTML is inline JS in `window.__como_rehydration__` -- letting a server-side rendered be dynamic as if it were fully client-side rendered.

The size of the CSS also presents in bloated HTML. Why not have 18 classes on your button? `<button class="_5732bd68 _4cbf0195 _00dac29f _737a8a8c b241f848 _9572431e _56fd9a8a ff367c5b f7a6e63a aa661bbd b1e8a5cc d6e0deb3 _0582e059 f7e4b8f0 f9d5d3fb e037a5e8 _340d09d4 fbc7d17b" ...`

Honestly, while I'm sure Linked is bloated, HN in Chrome is taking 204meg for the front page on my MBP. That's with no images, no videos, a minimal amount of css. `document.body.textContent.length` says 4278

Checking again it went down to 78meg. Still 78MEG!!! Thats over 1200 Apple IIs, Commodore 64s. I use to run Windows 3.1 for Workgroups, and in it run Microsoft Word, Excel, etc, on machines with 4meg. Now, a simple page of text is taking 78

I get why to some degree. It's highres 32bit display, multi-layered. The screen itself requires 36meg (40bit RGBA, 40bit because it's an HDR display). Each window itself is a texture. If the window is the same size as the screen then that's 36meg. Font Glpyhs are high-res antialias.

Compare that to my Windows 3.1 machine. OSes didn't use textures then and didn't anti-alias. GPUs didn't exist and the screen was 1024x768 or something small like that. Software rendering from fonts that were 1 bit per pixel.

I'm not saying that excuses browsers nor LinkedIn. Rather, if you go add up the basic pieces you'll find that part of the reason these things take lots of memory is because these things take lots of memory.

That's the sort of question a reasonable person would ask. To answer this correctly, you need to occupy the mind of a madman. Now, we've got a boatload of KPIs to optimise or our necks are on the chopping block!

Probably a memory leak

But other ideas: - all pages of FE site loaded at once instead as as needed - FE indexed search engine - bug rendering too many invisible HTML elements (eg 1M select boxes)