davidbgk
/
larlet-fr-david-cache

title: JavaScript Bloat in 2024
url: https://tonsky.me/blog/js-bloat/
hash_url: ad911ebf7ba5523ef0be1bdd599f7623
archive_date: 2024-03-03
og_image: https://dynogee.com/gen?id=dhqv5e0x3kfz7dy&title=JavaScript Bloat in 2024
description: What is the average size of JavaScript code downloaded per website? Fuck around and find out!
favicon: https://tonsky.me/i/favicon.png
language: en_US

<p><em>Translations: <a href="https://habr.com/ru/companies/ruvds/articles/796595/" target="_blank">Russian</a></em></p>
<p>I was a bit out of touch with modern front-end development. I also remembered articles about web bloat, how the average web page size was approaching several megabytes!</p>
<p>So all this time I was living under impression that, for example, if the average web page size is 3 MB, then JavaScript bundle should be around 1 MB. Surely content should still take the majority, no?</p>
<p>Well, the only way to find out is to fuck around. Let’s do a reality check!</p>
<p>I’m writing this in 2024, so maybe do a sequel in a few years?</p>
<h1 id="method">Method</h1>
<ul>
  <li>Firefox on macOS (but should be the same in any browser)</li>
  <li>Not incognito (I want to see numbers <em>inside</em> the app, and there’s a better chance it will resemble actual everyday experience)</li>
  <li>All extensions disabled</li>
  <li>JavaScript only</li>
  <li>Uncompressed</li>
  <li>Service Workers enabled (again, more real-life)</li>
  <li>All caching disabled (cold load)</li>
</ul>
<p>Why only JavaScript? Content varies a lot from site to site (surely videos on YouTube are heavier than text messages on Slack), but JavaScript is a universal metric for “complexity of interactions”.</p>
<p>The main goal is to evaluate how much work the browser has to do to parse and execute code.</p>
<p>To set some baseline, let’s start with this blog:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/tonsky@2x.webp?t=1709315366">        </figure>
<p>The number here would be 0.004 MB. I also highlighted all the important bits you need to set if you decide to reproduce this at home.</p>
<h1 id="landings">Landings</h1>
<p>Okay, let’s start with something simple, like landing pages/non-interactive apps.</p>
<p>A normal slightly interactive page looks like this — Wikipedia, 0.2 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/wikipedia@2x.webp?t=1709315366">        </figure>
<p>Slightly bloated — like this — Linear, 3 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/linear@2x.webp?t=1709315366">        </figure>
<p>Remember: that’s without images, or videos, or even styles! Just JS code.</p>
<p>A bad landing page looks like this — Zoom, 6 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/zoom@2x.webp?t=1709315366">        </figure>
<p>or like Vercel, 6 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/vercel@2x.webp?t=1709315366">        </figure>
<p>Yes, this is just a landing page. No app, no functionality, no calls. 6 MB of JavaScript just for that.</p>
<p>You can do a lot worse, though — Gitlab, 13 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/gitlab@2x.webp?t=1709315366">        </figure>
<p>Still just the landing.</p>
<h1 id="mostly-static-websites">Mostly static websites</h1>
<p>Nothing simpler than showing a static wall of text. Medium needs 3 MB just to do that:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/medium@2x.webp?t=1709315366">        </figure>
<p>Substack needs 4 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/substack@2x.webp?t=1709315366">        </figure>
<p>Progress?</p>
<p>Quora, 4.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/quora@2x.webp?t=1709315366">        </figure>
<p>Pinterest, 10 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/pinterest@2x.webp?t=1709315366">        </figure>
<p>Patreon, 11 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/patreon@2x.webp?t=1709315366">        </figure>
<p>And all this could’ve been a static page...</p>
<h1 id="search">Search</h1>
<p>When your app’s interactivity is limited to mostly search. Type the query — show the list of results. How heavy is that?</p>
<p>StackOverflow, 3.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/stackoverflow@2x.webp?t=1709315366">        </figure>
<p>NPM, 4 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/npmjs@2x.webp?t=1709315366">        </figure>
<p>Airbnb, 7 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/airbnb@2x.webp?t=1709315366">        </figure>
<p>Booking.com, 12 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/booking@2x.webp?t=1709315366">        </figure>
<p>But Niki, booking is complicated! Look at all this UI! All these filters. All these popups about people near you stealing your vacation!</p>
<p>Okay, okay. Something simpler then. Google. How about Google? One text field, list of links. Right?</p>
<p>Well, it’ll cost you whooping 9 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/google@2x.webp?t=1709315366">        </figure>
<p>Just to show a list of links.</p>
<h1 id="simple-one-interaction-apps">Simple one-interaction apps</h1>
<p>Google Translate is just two text boxes. For that, you need 2.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/google_translate@2x.webp?t=1709315366">        </figure>
<p>ChatGPT is <em>one</em> text box. 7 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/openai@2x.webp?t=1709315366">        </figure>
<p>I mean, surely, ChatGPT is complex. But on the server, not in the browser!</p>
<h1 id="videos">Videos</h1>
<p>Loom — 7 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/loom@2x.webp?t=1709315366">        </figure>
<p>YouTube — 12 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/youtube@2x.webp?t=1709315366">        </figure>
<p>Compare it to people who really care about performance — Pornhub, 1.4 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/pornhub@2x.webp?t=1709315366">        </figure>
<h1 id="audio">Audio</h1>
<p>I guess audio just requires 12 MB no matter what:</p>
<p>SoundCloud:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/soundcloud@2x.webp?t=1709315366">        </figure>
<p>Spotify:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/spotify@2x.webp?t=1709315366">        </figure>
<h1 id="email">Email</h1>
<p>Okay, video and audio are probably heavy stuff (even though we are not measuring content, just JS, remember!). Let’s move to simpler office tasks.</p>
<p>Google Mail is just (just!) 20 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/gmail@2x.webp?t=1709315366">        </figure>
<p>It’s a freaking mailbox!!! How on earth is it almost as big as Figma, who ships entire custom C++/OpenGL rendering for their app?</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/figma@2x.webp?t=1709315366">        </figure>
<p>And if you are thinking: mail is complicated, too. Lots of UI, lots of interactivity. Maybe 20 MB is okay?</p>
<p>No!</p>
<p>Just no. See, FastMail, same deal, but only 2 MB. 10× less!</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/fastmail@2x.webp?t=1709315366">        </figure>
<h1 id="productivity">Productivity</h1>
<p>Okay, maybe e-mail is too complicated? How about something even simpler? Like a TODO list?</p>
<p>Well, meet Todoist, 9 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/todoist@2x.webp?t=1709315366">        </figure>
<p>Showing you a list of files in folders requires 10 MB in Dropbox:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/dropbox@2x.webp?t=1709315366">        </figure>
<p>List of passwords? That’ll be 13 MB on 1Password:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/1password@2x.webp?t=1709315366">        </figure>
<p>Cards? Add 0.5 MB more, up to 13.5 MB. Trello:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/trello@2x.webp?t=1709315366">        </figure>
<p>Okay, maybe TODO lists are too complex, too? How about chatting?</p>
<p>Well, Discord needs 21 MB to do that:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/discord@2x.webp?t=1709315366">        </figure>
<h1 id="document-editing">Document editing</h1>
<p>Okay, document editing is hard, right? You have to implement cursor movement, synchronization, etc.</p>
<p>Google Docs, 13.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/google_docs@2x.webp?t=1709315366">        </figure>
<p>Something simpler? Notion, 16 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/notion@2x.webp?t=1709315366">        </figure>
<h1 id="social-networks">Social Networks</h1>
<p>The typical size of code that social networks need for like buttons to go brrr is 12 MB.</p>
<p>Twitter, 11 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/twitter@2x.webp?t=1709315366">        </figure>
<p>Facebook, 12 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/facebook@2x.webp?t=1709315366">        </figure>
<p>TikTok, 12.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/tiktok@2x.webp?t=1709315366">        </figure>
<p>Instagram is somehow bigger than Facebook, despite having like 10× less functions. 16 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/instagram@2x.webp?t=1709315366">        </figure>
<p>LinkedIn. Is it a blog? A platform? It has search, it has messaging, it has social functions. Anyways, that’ll be 31 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/linkedin@2x.webp?t=1709315366">        </figure>
<p>By the way, I'd like to add you to my professional network on LinkedIn.</p>
<h1 id="elephants--its-own-category">Elephants — its own category</h1>
<p>Sometimes websites are so stupidly, absurdly large that they deserve their own category.</p>
<p>Here, Jira, a task management software. Almost 50 MB!</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/jira@2x.webp?t=1709315366">        </figure>
<p>Do they ship the entire Electron compiled WASM or what?</p>
<p>But that’s not the limit! Slack adds 5 more MB, up to 55 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/slack@2x.webp?t=1709315366">        </figure>
<p>Yes, it’s a chat. You know, list of users, messages, reactions. Stuff we did on raw HTML, even before JS was invented?</p>
<p>That’s 55 MB in today’s world. It’s almost like they are trying to see how much more bullshit can they put in a browser before it breaks.</p>
<p>Finally, this blew my mind. Somehow <a href="https://react.dev/blog/2023/03/16/introducing-react-dev" target="_blank">react.dev</a> starts with a modest 2 MB but as you scroll back and forth, it grows indefinitely. Just for fun, I got it to 100 MB (of JavaScript!), but you can go as far as you like:</p>
<figure>
  <video autoplay="" muted="" loop="" preload="auto" playsinline="" controls="">
    <source src="https://tonsky.me/blog/js-bloat/react@2x.mp4?t=1708621056" type="video/mp4">
  </source></video>
</figure>
<p>What is going on there? Even if it unloads and downloads parts of that blog post, how is it growing so quickly? The text itself is probably only 50 KB (0.05 MB).</p>
<p>UPD: It has been brought to my attention that this behavior is not, in fact, representative of normal user experience. Normally embedded code editors will be cached after first load and subsequent loads will be served from disk cache. So as you scroll, you will see no network traffic, but these 100 MB of JS will still be parsed, evaluated and initialized over and over as you scroll.</p>
<h1 id="how-fast-are-we-degrading">How fast are we degrading?</h1>
<p>Look how cute! In 2015 average web page size was approaching shareware version of Doom 1 (2.5 MB):</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/bloat_2015@2x.webp?t=1709315366"><figcaption><a href="https://twitter.com/xbs/status/626781529054834688" target="_blank">Source</a></figcaption>        </figure>
<p>Well, in 2024, Slack pulls up 55 MB, the size of the original Quake 1 with all the resources. But now it’s just in JavaScript alone.</p>
<p>For a chat app!</p>
<h1 id="how-big-is-10-mb-anyway">How big is 10 MB anyway?</h1>
<p>To be honest, after typing all these numbers, 10 MB doesn’t even feel that big or special. Seems like shipping 10 MB of <em>code</em> is normal now.</p>
<p>If we assume that the average code line is about 65 characters, that would mean we are shipping ~150,000 lines of code. With every website! Sometimes just to show static content!</p>
<p>And that code is minified already. So it’s more like 300K+ LoC just for one website.</p>
<p>But are modern websites really <em>that</em> complex? The poster child of SPAs, Google Maps, is quite modest by modern standards — is <em>still</em> just 4.5 MB:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/google_maps@2x.webp?t=1709315366">        </figure>
<p>Somebody at Google is seriously falling behind. Written with modern front-end technologies, it should be at least 20 MB.</p>
<p>And if you, like me, thought that “Figma is a really complex front-end app, so it must have a huge javascript download size”, well, that’s correct, but then Gmail is about as complex as Figma, LinkedIn is 1.5× more complex and Slack is 2.5× more ¯\_(ツ)_/¯</p>
<h1 id="conclusion">Conclusion</h1>
<p>It’s not just about download sizes. I welcome high-speed internet as much as the next guy. But code — JavaScript — is something that your browser has to parse, keep in memory, execute. It’s not free. And these people talk about performance and battery life...</p>
<p>Call me old-fashioned, but I firmly believe content should outweigh code size. If you are writing a blog post for 10K characters, you don’t need 1000× more JavaScript to render it.</p>
<p>This site is doing it right:</p>
<figure>
<img src="https://tonsky.me/blog/js-bloat/jquery@2x.webp?t=1709315366">        </figure>
<p>That’s 0.1 MB. And that’s enough!</p>
<p>And yet, on the same internet, in the same timeline, Gitlab needs 13 MB of code, 500K+ LoC of JS, just to display a static landing page.</p>
<p>Fuck me.</p>