16 ms·

JavaScript Bloat in 2024

420 points by cdme 3y ago

cranberryturkey 3y ago
i lived in a trailer and had spotty wifi via at&t hotspot. i also have starlink but trees made it unreliable. You realy don't understand how bad js bloat is until you have a shitty internet connection.
Linoleum 3y ago
Nice article, however - your own page required 13.2 MB for me, is it okay? :)
peter_vukovic 3y ago
Looking at the screenshots in the article, the readings are wrong. You are reading the first number as if that's the amount of JS being loaded, but it's the second number (i.e. if it says 6 MB / 3MB, it's 3 MB of JavaScript, out of 6 MB total page size).
PetitPrince 3y ago
This compares how much Javascript is loaded from popular sites (cold loaded). Some highlights: - PornHub loads ~10x less JS than YouTube (1.4MB vs 12MB) - Gmail have an incomprehensible large footprint (20MB). Fastmail is 10x ligthter (2MB). Figma is equivalent (20MB) while being a more complex app. - Jira has 58MB (whoa)
- Spivak 3y ago
  Holy god YouTube is 12MB? How!?
  - troupo 3y ago
    They also load 2.5 MB of CSS on desktop :)
- mewpmewp2 3y ago
  YouTube feels really snappy to me, but Figma is consistently the worst experience I have ever felt for web apps. Jira is horrible and slow also though.
  - latency-guy2 3y ago
    YouTube does not feel snappy to me anymore, its still one of the better experiences I have on the internet, but quite bad from years before. I just tested my connection to youtube right now, just a tiny bit over 1.2 seconds from not using it for a few days. A fresh, no cache, no cookies, the entire page loaded in 2.8 seconds. A hot reload on either side varied between 0.8s to 1.4 seconds. All done with at most ublock as an extension on desktop chrome with purported gigabit speeds from my ISP. That speed is just OK, but definitely not the 54ms response time I got to hit google's server to send me the HTML document that bears all the dynamic content on youtube Figma is very surprising to me, that bullshit somehow is PREFERRED by people, getting links from designers from that dogshit app screeches my browser to speeds I haven't seen in decades, and I don't think I'm exaggerating at all when I say that
  - troupo 3y ago
    On desktop they load 2.5MB of JS and 12 MB of Javascript to show a grid of images. And it still takes them over 5 seconds to show video length in the previews. Youtube hasn't felt snappy in ages
- jkoudys 3y ago
  Pornhub needs to be small. Jira will download once then be loaded locally until it gets updated, just like an offline app. Pornhub will be run in incognito mode, where caching won't help.
  - thrwwycbr 3y ago
    > Jira will download once Maybe you should take a look on the Network Tab, because Atlassian sure does have a crappy network stack.
  - wruza 3y ago
    Pornhub will be run in incognito mode It’s not '80s anymore, nobody cares about your porn. I have bookmarks on the bookmarks bar right next to electronics/grocery stores and HN. And if you’re not logged in, how would PH and others know your preferences?
    - thiht 3y ago
      I don’t think you’re speaking for the majority here, no one has pornhub in their bookmarks bar
      - nox101 3y ago
        When I said I didn't watch porn on company laptops, only my personal one, the 5 Apple employees at a party all said they watched porn on company laptops. I was in the minority.
      - wruza 3y ago
        Yeah that was incoherent remark on my side, and there are situations where I'd put them in a folder. But I still find going incognito to watch porn paranoid.
        npteljes 3y ago
        It can also be considerate, like when using a shared device. Similar to how we don't vocalize every intrusive thought.
- pkphilip 3y ago
  No idea why an email client should have 20 MB of JS.
- niutech 3y ago
  Figma uses WASM, so its total size is much bigger: https://www.figma.com/blog/figma-faster/ https://www.figma.com/blog/figma-faster/
sublinear 3y ago
Any piece of software reflects the organization that built it. The data transferred is going to be almost entirely analytics and miscellaneous 3rd party scripts, not the javascript actually used to make the page work (except for the "elephant" category which are lazy loading modules i.e. React). Much of that is driven by marketing teams who don't know or care about any of this. All devs did was paste Google Tag Manager and/or some other script injection service to the page. In some cases the devs don't even do that and the page is modified by some proxy out in the production infrastructure. Maybe the more meaningful concern to have is that marketing has more control over the result than the people actually doing the real work. In the case of the "elephant" pages, the bloat is with the organization itself. Not just a few idiots but idiots at scale.
- jve 3y ago
  I remember associating Google with lean and fast: Google the search (vs Yahooo) and Chrome (vs IE/FF (i'm talking about when Chrome was released))... chrome on itself had not much of an UI and it was a feature.
- DanielHB 3y ago
  > All devs did was paste Google Tag Manager and/or some other script injection service to the page. In some cases the devs don't even do that and the page is modified by some proxy out in the production infrastructure. google tag manager is the best tool for destroying your page performance, previous job had google tag manager in the hands of another non-tech department. I had to CONSTANTLY monitor the crap that was being injected in the production pages. I tried very hard to get it removed.
SebastianKra 3y ago
Any reason why we're looking at uncompressed data? Some of the listed negative examples easily beat GMaps 1.5mb when compressed. Also, I'll give a pass to dynamic apps like Spotify and GMail [1] if (and only if) the navigation after loading the page is fast. I would rather have something like Discord which takes a few seconds to update on startup, than GitLab, which makes me wait up to two seconds for every. single. click. The current prioritisation of cold starts and static rendering is leading to a worse experience on some sites IMO. As an experiment, go to GitHub and navigate through the file tree. On my machine, this feels significantly snappier than the the rest of GitHub. Coincidentally, it's also one of the only parts that is not rendered statically. I click through hundreds of GitHub pages daily. Please, just serve me an unholy amount of JavaScript once, and then cache as much as possible, rather than making me download the entire footer every time I want to view a pipeline. [1]: These are examples. I haven't used GMail and Spotify
- acdha 3y ago
  Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, it’s easy to miss how much all of that code bloat affects the median user. https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
  - SebastianKra 3y ago
    I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised. Finding those things was only possible by looking at the profiler. I don't think general statements like "less JS = better" help anyone. It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? ...
lifthrasiir 3y ago
One thing completely ignored by this post, especially for actual web applications, is that it doesn't actually break JS files down to see why it is so large. For example, Google Translate is not an one-interaction app once you start to look further; it somehow has dictionaries, alternative suggestions, transliterations, pronunciations, a lot of input methods and more. I still agree that 2.5 MB is too much even after accounting that fact and some optional features can and should be lazily loaded, but as it currently stands, the post is so lazy that it doesn't help any further discussion.
- BandButcher 3y ago
  Don't want to hate on the author's post but the screenshots being slow to load made me chuckle, understandable as images can be big and there were a lot, but just found it a little ironic.
  - crooked-v 3y ago
    These days, slow-loading images usually mean that somebody hasn't bothered to use any of the automatic tooling various frameworks and platforms have for optimized viewport- and pixel density-based image sets, and just stuck in a maximum size 10+ MB image.
    - troupo 3y ago
      Which absolutely false for the website in question
    - blue_pants 3y ago
      Could you suggest some of those automatic tools?
      - littlecranky67 3y ago
        Yes, next/image which is part of Next.js Framework </irony>
- 3y ago
jakelazaroff 3y ago
I know the implication here is "too much JavaScript" but we also need to talk about how much of this is purely tracking junk.
- BandButcher 3y ago
  Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks
  - tadfisher 3y ago
    > Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks Some vendor SDKs can be built and bundled from NPM, but most of them explicitly require you fetch their minified/obfuscated bundle from their CDN with a script tag. This is so they don't have to support older versions like most other software in the world, and so they can push updates without requiring customers to update their code. Try to use vendors that distribute open-source SDKs, if you have to use vendors.
  - willsmith72 3y ago
    im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature
    - kevin_thibedeau 3y ago
      That data can be gathered with self-hosted JS if the devs were allowed to implement it. The infatuation with third party analytics is just a more elaborate version of leftpad.
      - ehnto 3y ago
danlugo92 3y ago
I only know that i know nothing, but lately libraries (not my own code) have been getting increasingly bloated... mostly true for big-ticket stuff such as Firebase or Meta's stuff. Anything homemade performs faster than ever though, so engines are getting better but my code has stayed as simplest as ever and finding improved performance.
pier25 3y ago
What's up with the React site? This is embarrassing...
- tjosepo 3y ago
  You can see from the recording that it's downloading the same few files from Codesandbox over and over again, as the iframes used for the examples are being unloaded and reloaded on scrolls and because the author disabled caching. The author could've scrolled forever and the number would've gone up indefinitely.
  - CompuIves 3y ago
    Exactly, the result would've been different if the author would not have disabled caching. In this case it's because the iframes are loaded/unloaded multiple times, but we also spawn web workers where the same worker is spawned multiple times (for transpiling code in multiple threads, for example). In all those cases we rely on caching so we don't have to download the same worker code more than once.
    - pier25 3y ago
      Wouldn't it be better if the code editors only activated if the user interacts with one? Even with caching it's absurd to download so much JS for a feature that probably most users will not use. It's a docs site after all.
- makepanic 3y ago
  Codesandbox is embedded for the code samples. If you not have cache disabled it will fetch from memory cache after the initial load and unload.
- silverwind 3y ago
  Maybe they forgot some `memo` so it re-renders everything including iframes all the time.
  - 3y ago
lukaqq 3y ago
Chillin, https://chillin.online/app/editor https://chillin.online/app/editor, integrated complete video editing functions, just for 1.8MB
- jerbear4328 3y ago
  Your editor downloads a 32.6MB ffmpeg WASM binary on every page load. Throttling the network to "Slow 3G", it took over four minutes of a broken interface before ffmpeg finally loads. (It doesn't cache, either.) A port of the Audacity audio editor to web[1] with WASM takes 2.7 minutes on the same connection, so the binary is totally reasonable, but I think claiming less than 2 MB is disingenuous. [1]: https://wavacity.com/ https://wavacity.com/
  - lukaqq 3y ago
    Sorry for that, we just focus on js bundle and don't realize how big the ffmepg.wasm is. Thanks for reminding, next step we will try to rebuild ffmepg.wasm and make it smaller.
    - occz 3y ago
      Caching might be your highest bang for the buck, depending on how often you expect someone to return to the app/reload the page it's hosted in.
- lukaqq 3y ago
  By re-confirmed, the 36MB ffmpeg.wasm file is compressed by brotli to 9.6 MB as transferred.
  - jerbear4328 3y ago
    Oh, nice! Compression is magical nowadays.
chuckadams 3y ago
Jeepers, how does this even happen? I've been developing a fairly complex app with Nuxt, Apollo client, and PrimeVue, and paid no attention to size whatsoever. Yet the most complex page in the app with the most module dependencies loads only 3.8 megs, and that's not even a minified build. Same page from the Nuxt dev server throws 24.4M at me, but I'm pretty sure it's pre-loading everything. Do the big players just not do any code splitting at all? On the other hand, node_modules weighs in at 601M. Sure I've got space to burn on the dev box, but that's reason #1 I'm not doing yarn zero-install and stuffing all that into the repo.
- hdjrudni 3y ago
  I'm at 329 kB of JS. I've been building on the same app for 10 years. That's a lot of cruft build up. And I'm still nowhere close to any of these numbers. I've got React, jQuery, lodash, and I don't know what else in there.
- Alifatisk 3y ago
  > On the other hand, node_modules weighs in at 601M. Use pnpm and see the difference
420698008 3y ago
Meanwhile the author has a ton of 1440p images while pegging his website width to 560px I like the conversation about web performance, but you should make sure you practice what you preach
- mrighele 3y ago
  Even if you are not using an high resolution display like the sibling comment says, the images are reasonably sized (they are a few hundreds KB each). I have seen landing pages with 20-30 MB images for no good reason.
  - guappa 3y ago
    Don't forget the ones with background videos of random diversely raced young good looking models having coffee and looking at screens while nodding.
- devtailz 3y ago
  The images display at 720x720, on a 2x retina screen the image needs to be 1440x1440 to fill that.
- cyclotron3k 3y ago
  720px actually, but more importantly, 720px is not actually 720px on a HiDPI screen. I just measured it on my mbp and "720px" is actually... 1440 physical pixels. I was surprised too!
  - FractalHQ 3y ago
    MBP device pixel ratio is 2 after all!
- ustad 3y ago
  The article is related to js bloat and the images are required for the presentation. The images come to 10MB - not bad. The js? 4.5KB!
chrismorgan 3y ago
> JavaScript is a universal metric for “complexity of interactions”. I don’t understand this claim in the slightest. It seems trivially falsified by the data that follows.
- redbar0n 3y ago
  I think he means ‘should be’, and then goes on to show that it in reality isn’t.
wruza 3y ago
10MB, 12MB, … Compare it to people who really care about performance — Pornhub, 1.4 MB Porn was always actual web hi-tech with good engineering, not these joke-level “tech” giants. Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense.
- thakoppno 3y ago
  > Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense. There are many, many cases of porn websites breaking the law.
  - yomly 3y ago
    Yes - writing PHP in 2024 is a crime that we should hold PH accountable for.
    - goatlover 3y ago
      Modern PHP is a pretty good language. Not my favorite, but it's not antiquated. And there's tons of websites built with it (granted Wordpress and Drupal are the majority of them).
- devjab 3y ago
  I never really understood why SPAs became so popular on the web. It’s like we suddenly and collectively became afraid of the page reload on websites just because it’s not a wanted behaviour in actual web applications. I have worked with enterprise applications for two decades, and with some that were build before I was born. And I think the React has been the absolute best frontend for these systems compared to everything that came before. You’re free to insert Angular/Vue/whatever by the way. But these are designed to replace all the various horrible client/server UIs that came before. For a web-page that’s hardly necessary unless you’re g-mail, Facebook or similar, where you need the interactive and live content updates because of how these products work. But for something like pornhub? Well PHP serves them just fine, and this is true for most web sites really. Just look at HN and how many people still vastly prefer the old.reddit.com site to their modern SPA. Hell, many people still would probably still prefer an old.Facebook to the newer much slower version.
iamsaitam 3y ago
At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hint: look at how big games have become, is it only textures though?).
- palmfacehn 3y ago
  To let us know we are not alone with our disdain. Too many JS enthusiasts paper over this insanity. The remnant lives on. "But JS is the biggest developer ecosystem in the world!"
  - StressedDev 3y ago
    This is not a JavaScript issue. It’s a software enginner/people issue. The question is how do you get people to care about performance, security, reliability, etc.? How do you get organizations to care about these issues? These are hard problems and people have been complaining about software size forever. Back in the early 90s, it was bloated C++ code. You will also see that all software continues to use more ram, more disk space, more network bandwidth etc. This trend has been going on for decades. For example, why do we use JSON as an interchange format? It’s relatively slow (i.e. creating it and parsing it is slow), nor is it is not space efficient. Back in the 1980s, the Unix community created RPC and the RPC wire formats were much more efficient because they were binary formats. The reason we use JSON is it makes the developer’s life easier and because developers prefer ease of use to performance.
    - balls187 3y ago
      > The question is how do you get people to care about performance, security, reliability, etc...How do you get organizations to care about these issues? It's very hard to, unless there is a risk to the bottom line. Let me pose it differently--apparently ZED is ridiculously fast code editor. Do I want to switch from my vscode investment? Or will I deal with the "bloat"
ohazi 3y ago
Not surprised at all that JIRA is 50 MB, but still... What the fuck
- ihateolives 3y ago
  While Minix 1.1 uncompressed is 5 MB and comes complete with network stack etc. I used to run it on 386 back in the day.
- redbar0n 3y ago
  Expected JIRA to be a worst offender, tbh. In any category, really.
nsonha 3y ago
it's always bothered me that this dogma exists. Somehow web apps need to be super frugal with code size, while apps distributed on other (native) platforms never have such a problem. Somehow it's the bloated web that blocks the access for children in Affrica, but they can download bloated android apps just fine? Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (specifically caching & PWA) is, that makes a trivial thing like code size a problem.
- eitland 3y ago
  If Atlassian did't use a full minute to update a certain roadmap view on my MBP from January I would be one step closer to agreeing with you even if it was still 50 MB. But I am old enough to remember Gannt charts didn't use to take that long on old Pentium processors back in school, way before Git was invented. Another thing is the sheer yuck of it: If a typical web app was lots of business code, maybe. But when you look at the network tab and it feels like you are looking at the hair ball from a sink drain, lots of intertwined trackers to catch everything that passes, that is another story.
  - nsonha 3y ago
    yes, the problem with the narrative is that web apps that are logic heavy are lumped together with content based sites who cannot justify their code bloat.
- donkeybeer 3y ago
  Web sites should be frugal. If content websites, even more so if they even lack comment sections, are getting huge that's a pure "skill issue". It's not our place to speculate why what should have been a content site became a web app.
- atraac 3y ago
  > while apps distributed on other (native) platforms never have such a problem Could you give an example? I was an android app dev over 5 years ago and there was a huge push for lower app size everywhere. Google even made Android App Bundles to fight this issue specifically.
dieulot 3y ago
For a more complete view, the HTTP Archive tracks general site weight over time and gives you percentiles (click Show table): https://httparchive.org/reports/page-weight#bytesJs https://httparchive.org/reports/page-weight#bytesJs The median JS bundle is 600kB on desktop. p90 (“high 10%”) is 1830kB.
- aembleton 3y ago
  Weird spike in March 2021 in the `Other Bytes` graph. Wonder what went on then; or if there was a glitch in their data.
  - lifthrasiir 3y ago
    That spike is only visible when Drupal/Magento/WordPress lenses are selected, and disappears with the top ~1M websites, so I assume it is a very long tailed behavior.
ccorcos 3y ago
Lots of websites render HTML and CSS from JS (e.g. react). So some of these “static” websites are getting an uncharitable review.
w3news 3y ago
So true, we build large complex frameworks, abstractions over abstractions. Try to make things easy to build and maintain. But I think the problem is that many developers that using these frameworks not even know the Javascript basics. Of course there are smart people at these large companies. But they try to make things easy instead of learn people the basics. We over engineer the web applications, create too much layers to hide the actual language. 20 years ago, every web developer can learn building websites by just check the source code. Now you can see the minified Javascript after a build, and nobody understand how it works, even the developers that build the web application don't recognize the code after the build. I love Javascript, but only pure Javascript, and yes, with all his quirks. Frameworks don't protect you from the quirks, you have to know it so you don't make quirks, and with all the abstraction layers, you not even know what you are really building. Keep it simple, learn Javascript itself instead of frameworks, and you downsize the Javascript codebase a lot.
- wruza 3y ago
  Pretty sure the situation wouldn't change if it wasn't minified. Recently I had to add a couple of mechanics into sd-web-ui, but found out that the "lobe theme" I used was an insufferable pile of intermingled React nonsense. Returned to sd-web-ui default look that is written in absolutely straightforward js and patched it to my needs easily in half an hour. This is a perfect example based on a medium-size medium-complexity app. Most sites in TFA are less complex. The delusions that frontend guys are preaching are on a different level than everything else in development.
advael 3y ago
I have to also wonder what percentage of each of those web logic figures come from code that's there to silently do telemetry rather than part of e.g. a UX framework
flohofwoe 3y ago
And here I am feeling bad that my WASM C64 emulator doesn't fit into 64 KBytes anymore ;) (it's grown to 116 KBytes total compressed download size over the years).
jspdown 3y ago
The state of the web is very sad. Most people with a fiber connection don't even notice how slow it became. But when you are still on a 2Mbps connection, this is just plain horrible. I'm in this case, it's terribly painful. Because of this, I can't even consider not using an ad/tracker blocker. Would love to see this test with Ublock origin enabled.
- bambax 3y ago
  > Would love to see this test with unblock origin enabled. Me too. I suspect most of this code is for user tracking and ad management.
  - panstromek 3y ago
    Tracking is a bit heavy, but from what I've looked at, the app code is usually much worse. I've looked at what Instagram and JIRA ship during the initial load and it's kinda crazy.
- deliriumchn 3y ago
  > But when you are still on a 2Mbps connection What happens when you use modern apps on iphone 3 or first nexus phone? I don't understand, do people think that with better, faster computers and network speed we should focus on smaller and smaller apps and websites?
  - pavlov 3y ago
    Your iPhone CPU doesn't suddenly become an iPhone 3G CPU sometimes, but network availability does vary a lot. You may also one day find yourself on a flaky 3G connection needing access to some web app that first loads twenty megabytes of junk before showing the 1 kB of data you need, and then it's clearer what the problem is here.
- threatofrain 3y ago
  Most people with a fiber connection? I bet a lot of people with money don't have a fiber connection, certainly not most people here on HN.
gloosx 3y ago
It would be useful if author sorted the requests by size. Most of this junk anyway is analytics, heatmaps, tracking and all that bullshit. Ofc you can make <1MB sites easily with the most complex UI and functionality, but the business just doesn't demand this or care while pennies are flowing. Caching and compression is also very important especially for virtualised sites like react-dev which author did not understood, they are essential features packed and turned on in every browser and in "real-life" test i wouldn't disable them.
djtango 3y ago
I recently came back from a road trip in New Zealand - a lot of their countryside has little to no cell coverage. Combined with roaming (which seems to add an additional layer of slowness) and boy did it suck to try to use a lot of the web. Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really sucks in so many ways
- user432678 3y ago
  Re: Spotify So much agree here, the offline mode is so beyond being annoying so I even started building my own iOS offline first music app.
  - jjav 3y ago
    > my own iOS offline first music app Sadly ironic that apple used to sell this, in the shape of an ipod! I hold on to mine, it is perfect in every way that a phone is terrible. It is tiny and 100% offline, just what I need.
    - rob74 3y ago
      Wait... iOS doesn't have an offline music app anymore either? Google replaced the "Play Music" app (which could also play offline music files) with "Youtube Music" a few years ago (not sure if that works with offline files, I switched to a third party app), but I thought iOS still had one (precisely because they used to sell the iPods, specifically the iPod touch which was more or less an iPhone lacking the phone part)?
      - d1sxeyes 3y ago
        It does. You can download playlists on Apple Music (or even use your own files with it, a rarity in the post-cloud world). Maybe OP was talking specifically about the behaviour of Spotify?
        3y ago
otabdeveloper4 3y ago
Slack is some of the worst software ever written by mankind.
- solumunus 3y ago
  It's far better than Microsoft Teams, so I must disagree.
  - xigoi 3y ago
    That’s a really low bar.
  - nesarkvechnep 3y ago
    Both are some of the worst software ever.
  - mnau 3y ago
    Tbh, new teams eat only half the memory old one did. Still sucks, but it's 700MB RAM vs 1.4GB just to open a chat.
- balls187 3y ago
  In what way? I've used a number of interoffice communication apps, and was on IRC in the hey days of dialup. Slack (for work purposes) just nails the experience for a broad set of users.
singularity2001 3y ago
The static page sites fit the narrative but for word editing and e-mail you should compare with native clients
l5870uoo9y 3y ago
I suspect ChatGPT is so bloated because they (inefficiently) include entire Markdown parser and code highlighting libraries. Add that various tracking libraries and you have a big bundle.
deleted 3y ago
[deleted]
panstromek 3y ago
Interesting how well does the amount of JS inversely correlates with my experience of using those sites...
sushirundown 3y ago
This also happens with other software, and it's arguably even worse. Some mobile apps take up hundreds of megabytes because of all of the bloat that they feel the need to bundle.
vendiddy 3y ago
I'm inspired to slim down my own app. Any good tools or techniques out there to identify what's causing bloat?
- lifthrasiir 3y ago
  In general, look for dependencies. Any popular enough bundlers should have a feature or plugin to show the bundle statistics (e.g. webpack-bundle-analyzer or rollup-plugin-analyzer). Audit your dependency to see if that's not requested nor needed, and try to remove them with a finer-grained dependency or leaner library or rewriting, in the order of preference. That alone is enough for usual JS apps, because not much people do so...
- npteljes 3y ago
  Turning on any kind of performance monitoring can help. They usually have ones for every platform. For the web, for example, I used YSlow in the past, but there are several alternatives: https://alternativeto.net/software/yahoo-yslow/ https://alternativeto.net/software/yahoo-yslow/
gpjanik 3y ago
Serious question: what is the issue with these paritcular sizes? I know that features/look these websites have are definitely achievable with less JS at a higher engineering cost, but what's the problem with it? 10MB loads in two seconds on an okay-ish desktop connection (correct me if I'm wrong, but most of people don't deploy Vercel apps from their phone from a mountain range with 3G connection). The experience on the websites mentioned is smooth as it can only get; everything is super fast and nice. Every subsequent click is just instant action. That's how web should look like. Is the problem here that they perform poorly on slower computers/connections? Is it even true? Is there an audience of developers who can't use Vercel or GitLab productively because of that? Any metrics to support that? IMHO optimizing against bundle size/JS sent over the network is one of the worst metrics for performance I could imagine.
- alexey2020 3y ago
  came here to write a similar comment. Totally agree! Focusing on a particular metric for the sake of the metric - what's the point? Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?
- AHTERIX5000 3y ago
  But the experience is not smooth as it can get if you're running a bit older HW. Gmail and Slack are notorious for bad performance even when the content displayed is rather simple plain text. As a user I don't really get anything in return when developers decide to use complex JS solutions for simple use cases.
- npteljes 3y ago
  I think it serves as a generic metric for bloat, because nobody really optimizes for size, thereby making it a good untainted metric. As the web gets bloaty and slow, the size of the websites grow as well, which also invites using size as a metric for bloat. Smooth, fast, nice, these would be good to measure, but it's much harder. I like an interface response time metric, for example [0]. I always lament that interfaces are getting slow - I get that they are nicer, too, but god damn why am I waiting 1 second for anything, when my Pentium III with Win XP was near instant? [0] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...
jwr 3y ago
I have a large and complex (ERP/MRP/inventory system for electronics) ClojureScript application and I was worried about my compiled code size being around 2.45MB. This puts it into perspective. I heard complaints about ClojureScript applications being large, which I think is true if you write a "Hello, world!" program, but not true for complex applications. Also, Google Closure compiler in advanced compilation mode is a great tool. Of course, since it is technically superior, it is not in fashion, and since it is hard to use correctly, people pretend it isn't there.
okaleniuk 3y ago
Meanwhile, all the pages on https://wordsandbuttons.online/ https://wordsandbuttons.online/ with all the animation and interactivity are still below 64 KB. This one, for example, https://wordsandbuttons.online/trippy_polynomials_in_arctangent_scale.html https://wordsandbuttons.online/trippy_polynomials_in_arctang... is 51 KB. And the code is not at all economical. It's 80% copy-paste with little deviations. There is no attempt to save by being clever either, it's all just good old vanilla JS. And no zipping, no space reduction. The code is perfectly readable when opened with the "View page source" button. The trick is - zero dependency policy. No third party, no internal. All the code you need, you get along with the HTML file. Paradoxically, in the long run, copy-paste is a bloat preventor, not a bloat cause.
- lifthrasiir 3y ago
  You can do the same with dependencies and "modern" JS toolkits. Dependency itself is not a cause but a symptom; websites and companies are no longer incentivized to reduce bloats, so redundant dependencies are hardly pruned.
- kaba0 3y ago
  It could add at least some minimal margin. On mobile, I literally can’t see the edges.
diimdeep 3y ago
Remember The Website Obesity Crisis [1] article from 2015, since then [2] things only got worse, and it is been almost 10 years already, well will be next year. Is it foolish to say that in 10 more years you wont be able to navigate the web on a circa 2015 PC ? If nothing changes seems like it. My old macbook from 2013 with latest Firefox is already can not handle loading https://civitai.com https://civitai.com web page with 23.98 MB of JavaScript, it is just hangs for half a minute while trying to render this disaster of web frontend. It is not just web, mobile all in one apps got so large that 2013 phone the same way unable to load them, and guess what, half of them are written on top of web tech stack, why three comma ,,, budget companies can not afford to write native application ? [1] https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm [2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=website%20obesity%20crisis&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
ulrischa 3y ago
Make Jquery great again
brap 3y ago
That dark-mode button is broken.
jongjong 3y ago
Just checked my SaaS platform. The entire application front end is 1.3 MB. But 300KB of that are font files and 490KB is for a cryptographic library for blockchain authentication. The thing is; I didn't use any bundling or minification. Also, it loads faster than most of the websites mentioned in this article and that's with minimal optimizations and my server being located on the other side of the world.
daflip 3y ago
All the js asset sizes quoted in the article seem inflated compared to the figures I see when I try to verify the authors figures.
danabramov 3y ago
The React site part of this is not real. The author ticked "Disable cache" which means the same code (which powers the interactive editable sandboxes they're scrolling by) gets counted over and over and over as if it was different code. If you untick "Disable cache", it's loaded once and gets cached.
- fesc 3y ago
  Yeah but once per page, which is why it is okay to disable cache as the author wanted to simulate a cold load of each of those pages.
  - danabramov 3y ago
    That's also not true? I'm navigating between pages, and it does get served from cache for all subsequent navigations. The only case when this code gets loaded is the literally the first cold load of the entire site — and it's only used for powering live editable interactive sandboxes (surely you'd expect a in-browser development environment to require some client-side code). It doesn't block the initial rendering of the page. What is the problem?
  - balls187 3y ago
    I think the issue isn't with the methodology (disabling cache), but rather the erroneous conclusion that the React.dev website continually requests data as somehow problematic when it's a sideeffect of disabling browser cache. Also, FWIW, OP is one of the authors of react.dev and a member of the react core team (not that it's relevant to the objection).
renegade-otter 3y ago
I often have to close a tab because my 12-core Mac mini starts heating the room and the fan sounds like it's about to fly off the axis. This is not specific to Javascript but the ad code doing this is obviously JS. Speaks more to the general Enshitifcation of the web. Does Web 3.0 fix this? /s
nazka 3y ago
Great article! But in the conclusion jQuery is enough? No thanks
- Alifatisk 3y ago
  jQuery being so lightweight compared to the rest felt a bit symbolical, Idk how to express it.
CraftThatBlock 3y ago
Also worth noting some of these website (such as Linear) pre-load other pages once the current page is done loading. The actual JavaScript on the page seems to be about 500kb (as opposed to 3mb)
farukmanon12 3y ago
[dead]
ohmantics 3y ago
What percentage of all that JS is just crap injected into sites by pointless invasive trackers?
qsantos 3y ago
Coincidently, I have written a browser extension to navigate Hacker News comments using Vi-style key bindings [1]. It has no compilation steps, no npm. It is mostly a 1kLoC file of vanilla JavaScript. Modern frameworks are definitely needed for large applications, but there is no need all that complexity when the scope is reduced. [1] https://github.com/qsantos/ViHN/ https://github.com/qsantos/ViHN/
mortallywounded 3y ago
SPAs were a psyop by FAANG companies to gain a monopoly and mind-share of developer talent. Are you team Google (Angular)? Meta (React)? Are you a hipster (Ember)? From there things only went downhill faster.
- Alifatisk 3y ago
  Why did you leave out Vue?
  - mortallywounded 3y ago
    It came after the first wave of SPAs and if we listed every SPA framework (or "library") we'd be here all day.
    - Alifatisk 3y ago
      Oh I get it
qingcharles 3y ago
I work with newly-released prisoners and homeless people who are mostly on free Lifeline phones. They typically get 15GB of data a month. This is used up in 2-3 days on average. After that they can sometimes get 2G data, but it is impossible to use Google Maps to get to an interview, or even to download their email or fill out a job application online. Because the phone is no longer useable they often get lost or stolen. I regularly come across web sites with >250MB home pages these days. It doesn't take many of those to kill your entire data allotment.
jauntywundrkind 3y ago
It sucks that we blew up CDNs for security reasons. How nice it would be if sites using React could use the React already in cache from visiting another site! I keep wanting to have some kind of technical answer possible here. Seems hard. And who cares, because massive bundles are what we do now anyways, in most cases. But it sucks that the web app architecture and web resource architecture are both massively less capable than they were 20 years ago.
- ivanjermakov 3y ago
  Empty React app is ~400KB uncompressed AFAIR. So just CDNs wouldn't drastically improve the situation.
  - jauntywundrkind 3y ago
    React was one example, of a library that might be used repeatedly. The premise isn't that react and react alone's core lib is reused (did you include react.dom too?), but that many different libs become cached over time & space.
ivanjermakov 3y ago
Don't get me started on mobile and desktop apps where 100MB is a bare minimum.
bufferoverflow 3y ago
If you want to see the framework that does it right, check out Qwik. Incredibly small JS / CSS bundles. Only loads what it needs. https://qwik.dev/ https://qwik.dev/
pepoluan 3y ago
Will using HTMX save a lot?
Alifatisk 3y ago
While I agree with the article, I am also obsessed with keeping the size as low as possible, I can't stop thinking about how it feels like the Author is somewhat mixing up webapps with websites. Websites requiring that much JS for doing very simple static tasks is bloat, but the same bar should not be set for webapps. It should still be required and a high priority to keep the bundle size low but webapps should be considered as different category. Websites can (and should) function without JS, webapps cannot. Another thing is that the Author only looked at the visible elements, for example on Google Translate and Outlook. What he did not consider is that there is a lot of more apps accessible behind the menus. If you take a closer look at Outlook at first glance, sure, it's just a simple app to display your emails. But on the sidebar you have access to a lot more features like calendar, contacts and the office suite.
jonaswalker305 3y ago
[dead]
wdbacker 3y ago
FYI, switching to dark mode makes the post unreadable ;-)

420 points by cdme 3y ago

i lived in a trailer and had spotty wifi via at&t hotspot. i also have starlink but trees made it unreliable. You realy don't understand how bad js bloat is until you have a shitty internet connection.

Linoleum 3y ago

Nice article, however - your own page required 13.2 MB for me, is it okay? :)

peter_vukovic 3y ago

Looking at the screenshots in the article, the readings are wrong. You are reading the first number as if that's the amount of JS being loaded, but it's the second number (i.e. if it says 6 MB / 3MB, it's 3 MB of JavaScript, out of 6 MB total page size).

PetitPrince 3y ago

This compares how much Javascript is loaded from popular sites (cold loaded). Some highlights: - PornHub loads ~10x less JS than YouTube (1.4MB vs 12MB) - Gmail have an incomprehensible large footprint (20MB). Fastmail is 10x ligthter (2MB). Figma is equivalent (20MB) while being a more complex app. - Jira has 58MB (whoa)

Spivak 3y ago
Holy god YouTube is 12MB? How!?
- troupo 3y ago
  They also load 2.5 MB of CSS on desktop :)
mewpmewp2 3y ago
YouTube feels really snappy to me, but Figma is consistently the worst experience I have ever felt for web apps. Jira is horrible and slow also though.
- latency-guy2 3y ago
  YouTube does not feel snappy to me anymore, its still one of the better experiences I have on the internet, but quite bad from years before. I just tested my connection to youtube right now, just a tiny bit over 1.2 seconds from not using it for a few days. A fresh, no cache, no cookies, the entire page loaded in 2.8 seconds. A hot reload on either side varied between 0.8s to 1.4 seconds. All done with at most ublock as an extension on desktop chrome with purported gigabit speeds from my ISP. That speed is just OK, but definitely not the 54ms response time I got to hit google's server to send me the HTML document that bears all the dynamic content on youtube Figma is very surprising to me, that bullshit somehow is PREFERRED by people, getting links from designers from that dogshit app screeches my browser to speeds I haven't seen in decades, and I don't think I'm exaggerating at all when I say that
- troupo 3y ago
  On desktop they load 2.5MB of JS and 12 MB of Javascript to show a grid of images. And it still takes them over 5 seconds to show video length in the previews. Youtube hasn't felt snappy in ages
jkoudys 3y ago
Pornhub needs to be small. Jira will download once then be loaded locally until it gets updated, just like an offline app. Pornhub will be run in incognito mode, where caching won't help.
- thrwwycbr 3y ago
  > Jira will download once Maybe you should take a look on the Network Tab, because Atlassian sure does have a crappy network stack.
- wruza 3y ago
  Pornhub will be run in incognito mode It’s not '80s anymore, nobody cares about your porn. I have bookmarks on the bookmarks bar right next to electronics/grocery stores and HN. And if you’re not logged in, how would PH and others know your preferences?
  - thiht 3y ago
    I don’t think you’re speaking for the majority here, no one has pornhub in their bookmarks bar
    - nox101 3y ago
      When I said I didn't watch porn on company laptops, only my personal one, the 5 Apple employees at a party all said they watched porn on company laptops. I was in the minority.
    - wruza 3y ago
      Yeah that was incoherent remark on my side, and there are situations where I'd put them in a folder. But I still find going incognito to watch porn paranoid.
      - npteljes 3y ago
        It can also be considerate, like when using a shared device. Similar to how we don't vocalize every intrusive thought.
pkphilip 3y ago
No idea why an email client should have 20 MB of JS.
niutech 3y ago
Figma uses WASM, so its total size is much bigger: https://www.figma.com/blog/figma-faster/ https://www.figma.com/blog/figma-faster/

sublinear 3y ago

Any piece of software reflects the organization that built it. The data transferred is going to be almost entirely analytics and miscellaneous 3rd party scripts, not the javascript actually used to make the page work (except for the "elephant" category which are lazy loading modules i.e. React). Much of that is driven by marketing teams who don't know or care about any of this. All devs did was paste Google Tag Manager and/or some other script injection service to the page. In some cases the devs don't even do that and the page is modified by some proxy out in the production infrastructure. Maybe the more meaningful concern to have is that marketing has more control over the result than the people actually doing the real work. In the case of the "elephant" pages, the bloat is with the organization itself. Not just a few idiots but idiots at scale.

jve 3y ago
I remember associating Google with lean and fast: Google the search (vs Yahooo) and Chrome (vs IE/FF (i'm talking about when Chrome was released))... chrome on itself had not much of an UI and it was a feature.
DanielHB 3y ago
> All devs did was paste Google Tag Manager and/or some other script injection service to the page. In some cases the devs don't even do that and the page is modified by some proxy out in the production infrastructure. google tag manager is the best tool for destroying your page performance, previous job had google tag manager in the hands of another non-tech department. I had to CONSTANTLY monitor the crap that was being injected in the production pages. I tried very hard to get it removed.

SebastianKra 3y ago

Any reason why we're looking at uncompressed data? Some of the listed negative examples easily beat GMaps 1.5mb when compressed. Also, I'll give a pass to dynamic apps like Spotify and GMail [1] if (and only if) the navigation after loading the page is fast. I would rather have something like Discord which takes a few seconds to update on startup, than GitLab, which makes me wait up to two seconds for every. single. click. The current prioritisation of cold starts and static rendering is leading to a worse experience on some sites IMO. As an experiment, go to GitHub and navigate through the file tree. On my machine, this feels significantly snappier than the the rest of GitHub. Coincidentally, it's also one of the only parts that is not rendered statically. I click through hundreds of GitHub pages daily. Please, just serve me an unholy amount of JavaScript once, and then cache as much as possible, rather than making me download the entire footer every time I want to view a pipeline. [1]: These are examples. I haven't used GMail and Spotify

acdha 3y ago
Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, it’s easy to miss how much all of that code bloat affects the median user. https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-...
- SebastianKra 3y ago
  I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised. Finding those things was only possible by looking at the profiler. I don't think general statements like "less JS = better" help anyone. It helps to examine the size of webpages, but then you have to also put that information into context: how often does this page load new data? once the data is loaded, can you work without further loading? Is the data batched, or do waterfalls occur? Is this a page that users will only visit once, or do they come regularly? ...

lifthrasiir 3y ago

One thing completely ignored by this post, especially for actual web applications, is that it doesn't actually break JS files down to see why it is so large. For example, Google Translate is not an one-interaction app once you start to look further; it somehow has dictionaries, alternative suggestions, transliterations, pronunciations, a lot of input methods and more. I still agree that 2.5 MB is too much even after accounting that fact and some optional features can and should be lazily loaded, but as it currently stands, the post is so lazy that it doesn't help any further discussion.

BandButcher 3y ago
Don't want to hate on the author's post but the screenshots being slow to load made me chuckle, understandable as images can be big and there were a lot, but just found it a little ironic.
- crooked-v 3y ago
  These days, slow-loading images usually mean that somebody hasn't bothered to use any of the automatic tooling various frameworks and platforms have for optimized viewport- and pixel density-based image sets, and just stuck in a maximum size 10+ MB image.
  - troupo 3y ago
    Which absolutely false for the website in question
  - blue_pants 3y ago
    Could you suggest some of those automatic tools?
    - littlecranky67 3y ago
      Yes, next/image which is part of Next.js Framework </irony>
3y ago

jakelazaroff 3y ago

I know the implication here is "too much JavaScript" but we also need to talk about how much of this is purely tracking junk.

BandButcher 3y ago
Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks
- tadfisher 3y ago
  > Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks Some vendor SDKs can be built and bundled from NPM, but most of them explicitly require you fetch their minified/obfuscated bundle from their CDN with a script tag. This is so they don't have to support older versions like most other software in the world, and so they can push updates without requiring customers to update their code. Try to use vendors that distribute open-source SDKs, if you have to use vendors.
- willsmith72 3y ago
  im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature
  - kevin_thibedeau 3y ago
    That data can be gathered with self-hosted JS if the devs were allowed to implement it. The infatuation with third party analytics is just a more elaborate version of leftpad.
    - ehnto 3y ago

danlugo92 3y ago

I only know that i know nothing, but lately libraries (not my own code) have been getting increasingly bloated... mostly true for big-ticket stuff such as Firebase or Meta's stuff. Anything homemade performs faster than ever though, so engines are getting better but my code has stayed as simplest as ever and finding improved performance.

pier25 3y ago

What's up with the React site? This is embarrassing...

tjosepo 3y ago
You can see from the recording that it's downloading the same few files from Codesandbox over and over again, as the iframes used for the examples are being unloaded and reloaded on scrolls and because the author disabled caching. The author could've scrolled forever and the number would've gone up indefinitely.
- CompuIves 3y ago
  Exactly, the result would've been different if the author would not have disabled caching. In this case it's because the iframes are loaded/unloaded multiple times, but we also spawn web workers where the same worker is spawned multiple times (for transpiling code in multiple threads, for example). In all those cases we rely on caching so we don't have to download the same worker code more than once.
  - pier25 3y ago
    Wouldn't it be better if the code editors only activated if the user interacts with one? Even with caching it's absurd to download so much JS for a feature that probably most users will not use. It's a docs site after all.
makepanic 3y ago
Codesandbox is embedded for the code samples. If you not have cache disabled it will fetch from memory cache after the initial load and unload.
silverwind 3y ago
Maybe they forgot some `memo` so it re-renders everything including iframes all the time.
- 3y ago

lukaqq 3y ago

Chillin, https://chillin.online/app/editor https://chillin.online/app/editor, integrated complete video editing functions, just for 1.8MB

jerbear4328 3y ago
Your editor downloads a 32.6MB ffmpeg WASM binary on every page load. Throttling the network to "Slow 3G", it took over four minutes of a broken interface before ffmpeg finally loads. (It doesn't cache, either.) A port of the Audacity audio editor to web[1] with WASM takes 2.7 minutes on the same connection, so the binary is totally reasonable, but I think claiming less than 2 MB is disingenuous. [1]: https://wavacity.com/ https://wavacity.com/
- lukaqq 3y ago
  Sorry for that, we just focus on js bundle and don't realize how big the ffmepg.wasm is. Thanks for reminding, next step we will try to rebuild ffmepg.wasm and make it smaller.
  - occz 3y ago
    Caching might be your highest bang for the buck, depending on how often you expect someone to return to the app/reload the page it's hosted in.
lukaqq 3y ago
By re-confirmed, the 36MB ffmpeg.wasm file is compressed by brotli to 9.6 MB as transferred.
- jerbear4328 3y ago
  Oh, nice! Compression is magical nowadays.

chuckadams 3y ago

Jeepers, how does this even happen? I've been developing a fairly complex app with Nuxt, Apollo client, and PrimeVue, and paid no attention to size whatsoever. Yet the most complex page in the app with the most module dependencies loads only 3.8 megs, and that's not even a minified build. Same page from the Nuxt dev server throws 24.4M at me, but I'm pretty sure it's pre-loading everything. Do the big players just not do any code splitting at all? On the other hand, node_modules weighs in at 601M. Sure I've got space to burn on the dev box, but that's reason #1 I'm not doing yarn zero-install and stuffing all that into the repo.

hdjrudni 3y ago
I'm at 329 kB of JS. I've been building on the same app for 10 years. That's a lot of cruft build up. And I'm still nowhere close to any of these numbers. I've got React, jQuery, lodash, and I don't know what else in there.
Alifatisk 3y ago
> On the other hand, node_modules weighs in at 601M. Use pnpm and see the difference

420698008 3y ago

Meanwhile the author has a ton of 1440p images while pegging his website width to 560px I like the conversation about web performance, but you should make sure you practice what you preach

mrighele 3y ago
Even if you are not using an high resolution display like the sibling comment says, the images are reasonably sized (they are a few hundreds KB each). I have seen landing pages with 20-30 MB images for no good reason.
- guappa 3y ago
  Don't forget the ones with background videos of random diversely raced young good looking models having coffee and looking at screens while nodding.
devtailz 3y ago
The images display at 720x720, on a 2x retina screen the image needs to be 1440x1440 to fill that.
cyclotron3k 3y ago
720px actually, but more importantly, 720px is not actually 720px on a HiDPI screen. I just measured it on my mbp and "720px" is actually... 1440 physical pixels. I was surprised too!
- FractalHQ 3y ago
  MBP device pixel ratio is 2 after all!
ustad 3y ago
The article is related to js bloat and the images are required for the presentation. The images come to 10MB - not bad. The js? 4.5KB!

chrismorgan 3y ago

> JavaScript is a universal metric for “complexity of interactions”. I don’t understand this claim in the slightest. It seems trivially falsified by the data that follows.

redbar0n 3y ago
I think he means ‘should be’, and then goes on to show that it in reality isn’t.

wruza 3y ago

10MB, 12MB, … Compare it to people who really care about performance — Pornhub, 1.4 MB Porn was always actual web hi-tech with good engineering, not these joke-level “tech” giants. Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense.

thakoppno 3y ago
> Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense. There are many, many cases of porn websites breaking the law.
- yomly 3y ago
  Yes - writing PHP in 2024 is a crime that we should hold PH accountable for.
  - goatlover 3y ago
    Modern PHP is a pretty good language. Not my favorite, but it's not antiquated. And there's tons of websites built with it (granted Wordpress and Drupal are the majority of them).
devjab 3y ago
I never really understood why SPAs became so popular on the web. It’s like we suddenly and collectively became afraid of the page reload on websites just because it’s not a wanted behaviour in actual web applications. I have worked with enterprise applications for two decades, and with some that were build before I was born. And I think the React has been the absolute best frontend for these systems compared to everything that came before. You’re free to insert Angular/Vue/whatever by the way. But these are designed to replace all the various horrible client/server UIs that came before. For a web-page that’s hardly necessary unless you’re g-mail, Facebook or similar, where you need the interactive and live content updates because of how these products work. But for something like pornhub? Well PHP serves them just fine, and this is true for most web sites really. Just look at HN and how many people still vastly prefer the old.reddit.com site to their modern SPA. Hell, many people still would probably still prefer an old.Facebook to the newer much slower version.

iamsaitam 3y ago

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hint: look at how big games have become, is it only textures though?).

palmfacehn 3y ago
To let us know we are not alone with our disdain. Too many JS enthusiasts paper over this insanity. The remnant lives on. "But JS is the biggest developer ecosystem in the world!"
- StressedDev 3y ago
  This is not a JavaScript issue. It’s a software enginner/people issue. The question is how do you get people to care about performance, security, reliability, etc.? How do you get organizations to care about these issues? These are hard problems and people have been complaining about software size forever. Back in the early 90s, it was bloated C++ code. You will also see that all software continues to use more ram, more disk space, more network bandwidth etc. This trend has been going on for decades. For example, why do we use JSON as an interchange format? It’s relatively slow (i.e. creating it and parsing it is slow), nor is it is not space efficient. Back in the 1980s, the Unix community created RPC and the RPC wire formats were much more efficient because they were binary formats. The reason we use JSON is it makes the developer’s life easier and because developers prefer ease of use to performance.
  - balls187 3y ago
    > The question is how do you get people to care about performance, security, reliability, etc...How do you get organizations to care about these issues? It's very hard to, unless there is a risk to the bottom line. Let me pose it differently--apparently ZED is ridiculously fast code editor. Do I want to switch from my vscode investment? Or will I deal with the "bloat"

ohazi 3y ago

Not surprised at all that JIRA is 50 MB, but still... What the fuck

ihateolives 3y ago
While Minix 1.1 uncompressed is 5 MB and comes complete with network stack etc. I used to run it on 386 back in the day.
redbar0n 3y ago
Expected JIRA to be a worst offender, tbh. In any category, really.

nsonha 3y ago

it's always bothered me that this dogma exists. Somehow web apps need to be super frugal with code size, while apps distributed on other (native) platforms never have such a problem. Somehow it's the bloated web that blocks the access for children in Affrica, but they can download bloated android apps just fine? Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (specifically caching & PWA) is, that makes a trivial thing like code size a problem.

eitland 3y ago
If Atlassian did't use a full minute to update a certain roadmap view on my MBP from January I would be one step closer to agreeing with you even if it was still 50 MB. But I am old enough to remember Gannt charts didn't use to take that long on old Pentium processors back in school, way before Git was invented. Another thing is the sheer yuck of it: If a typical web app was lots of business code, maybe. But when you look at the network tab and it feels like you are looking at the hair ball from a sink drain, lots of intertwined trackers to catch everything that passes, that is another story.
- nsonha 3y ago
  yes, the problem with the narrative is that web apps that are logic heavy are lumped together with content based sites who cannot justify their code bloat.
donkeybeer 3y ago
Web sites should be frugal. If content websites, even more so if they even lack comment sections, are getting huge that's a pure "skill issue". It's not our place to speculate why what should have been a content site became a web app.
atraac 3y ago
> while apps distributed on other (native) platforms never have such a problem Could you give an example? I was an android app dev over 5 years ago and there was a huge push for lower app size everywhere. Google even made Android App Bundles to fight this issue specifically.

dieulot 3y ago

For a more complete view, the HTTP Archive tracks general site weight over time and gives you percentiles (click Show table): https://httparchive.org/reports/page-weight#bytesJs https://httparchive.org/reports/page-weight#bytesJs The median JS bundle is 600kB on desktop. p90 (“high 10%”) is 1830kB.

aembleton 3y ago
Weird spike in March 2021 in the `Other Bytes` graph. Wonder what went on then; or if there was a glitch in their data.
- lifthrasiir 3y ago
  That spike is only visible when Drupal/Magento/WordPress lenses are selected, and disappears with the top ~1M websites, so I assume it is a very long tailed behavior.

ccorcos 3y ago

Lots of websites render HTML and CSS from JS (e.g. react). So some of these “static” websites are getting an uncharitable review.

w3news 3y ago

So true, we build large complex frameworks, abstractions over abstractions. Try to make things easy to build and maintain. But I think the problem is that many developers that using these frameworks not even know the Javascript basics. Of course there are smart people at these large companies. But they try to make things easy instead of learn people the basics. We over engineer the web applications, create too much layers to hide the actual language. 20 years ago, every web developer can learn building websites by just check the source code. Now you can see the minified Javascript after a build, and nobody understand how it works, even the developers that build the web application don't recognize the code after the build. I love Javascript, but only pure Javascript, and yes, with all his quirks. Frameworks don't protect you from the quirks, you have to know it so you don't make quirks, and with all the abstraction layers, you not even know what you are really building. Keep it simple, learn Javascript itself instead of frameworks, and you downsize the Javascript codebase a lot.

wruza 3y ago
Pretty sure the situation wouldn't change if it wasn't minified. Recently I had to add a couple of mechanics into sd-web-ui, but found out that the "lobe theme" I used was an insufferable pile of intermingled React nonsense. Returned to sd-web-ui default look that is written in absolutely straightforward js and patched it to my needs easily in half an hour. This is a perfect example based on a medium-size medium-complexity app. Most sites in TFA are less complex. The delusions that frontend guys are preaching are on a different level than everything else in development.

advael 3y ago

I have to also wonder what percentage of each of those web logic figures come from code that's there to silently do telemetry rather than part of e.g. a UX framework

flohofwoe 3y ago

And here I am feeling bad that my WASM C64 emulator doesn't fit into 64 KBytes anymore ;) (it's grown to 116 KBytes total compressed download size over the years).

jspdown 3y ago

The state of the web is very sad. Most people with a fiber connection don't even notice how slow it became. But when you are still on a 2Mbps connection, this is just plain horrible. I'm in this case, it's terribly painful. Because of this, I can't even consider not using an ad/tracker blocker. Would love to see this test with Ublock origin enabled.

bambax 3y ago
> Would love to see this test with unblock origin enabled. Me too. I suspect most of this code is for user tracking and ad management.
- panstromek 3y ago
  Tracking is a bit heavy, but from what I've looked at, the app code is usually much worse. I've looked at what Instagram and JIRA ship during the initial load and it's kinda crazy.
deliriumchn 3y ago
> But when you are still on a 2Mbps connection What happens when you use modern apps on iphone 3 or first nexus phone? I don't understand, do people think that with better, faster computers and network speed we should focus on smaller and smaller apps and websites?
- pavlov 3y ago
  Your iPhone CPU doesn't suddenly become an iPhone 3G CPU sometimes, but network availability does vary a lot. You may also one day find yourself on a flaky 3G connection needing access to some web app that first loads twenty megabytes of junk before showing the 1 kB of data you need, and then it's clearer what the problem is here.
threatofrain 3y ago
Most people with a fiber connection? I bet a lot of people with money don't have a fiber connection, certainly not most people here on HN.

gloosx 3y ago

It would be useful if author sorted the requests by size. Most of this junk anyway is analytics, heatmaps, tracking and all that bullshit. Ofc you can make <1MB sites easily with the most complex UI and functionality, but the business just doesn't demand this or care while pennies are flowing. Caching and compression is also very important especially for virtualised sites like react-dev which author did not understood, they are essential features packed and turned on in every browser and in "real-life" test i wouldn't disable them.

djtango 3y ago

I recently came back from a road trip in New Zealand - a lot of their countryside has little to no cell coverage. Combined with roaming (which seems to add an additional layer of slowness) and boy did it suck to try to use a lot of the web. Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really sucks in so many ways

user432678 3y ago
Re: Spotify So much agree here, the offline mode is so beyond being annoying so I even started building my own iOS offline first music app.
- jjav 3y ago
  > my own iOS offline first music app Sadly ironic that apple used to sell this, in the shape of an ipod! I hold on to mine, it is perfect in every way that a phone is terrible. It is tiny and 100% offline, just what I need.
  - rob74 3y ago
    Wait... iOS doesn't have an offline music app anymore either? Google replaced the "Play Music" app (which could also play offline music files) with "Youtube Music" a few years ago (not sure if that works with offline files, I switched to a third party app), but I thought iOS still had one (precisely because they used to sell the iPods, specifically the iPod touch which was more or less an iPhone lacking the phone part)?
    - d1sxeyes 3y ago
      It does. You can download playlists on Apple Music (or even use your own files with it, a rarity in the post-cloud world). Maybe OP was talking specifically about the behaviour of Spotify?
      - 3y ago

otabdeveloper4 3y ago

Slack is some of the worst software ever written by mankind.

solumunus 3y ago
It's far better than Microsoft Teams, so I must disagree.
- xigoi 3y ago
  That’s a really low bar.
- nesarkvechnep 3y ago
  Both are some of the worst software ever.
- mnau 3y ago
  Tbh, new teams eat only half the memory old one did. Still sucks, but it's 700MB RAM vs 1.4GB just to open a chat.
balls187 3y ago
In what way? I've used a number of interoffice communication apps, and was on IRC in the hey days of dialup. Slack (for work purposes) just nails the experience for a broad set of users.

singularity2001 3y ago

The static page sites fit the narrative but for word editing and e-mail you should compare with native clients

l5870uoo9y 3y ago

I suspect ChatGPT is so bloated because they (inefficiently) include entire Markdown parser and code highlighting libraries. Add that various tracking libraries and you have a big bundle.

deleted 3y ago

[deleted]

panstromek 3y ago

Interesting how well does the amount of JS inversely correlates with my experience of using those sites...

sushirundown 3y ago

This also happens with other software, and it's arguably even worse. Some mobile apps take up hundreds of megabytes because of all of the bloat that they feel the need to bundle.

vendiddy 3y ago

I'm inspired to slim down my own app. Any good tools or techniques out there to identify what's causing bloat?

lifthrasiir 3y ago
In general, look for dependencies. Any popular enough bundlers should have a feature or plugin to show the bundle statistics (e.g. webpack-bundle-analyzer or rollup-plugin-analyzer). Audit your dependency to see if that's not requested nor needed, and try to remove them with a finer-grained dependency or leaner library or rewriting, in the order of preference. That alone is enough for usual JS apps, because not much people do so...
npteljes 3y ago
Turning on any kind of performance monitoring can help. They usually have ones for every platform. For the web, for example, I used YSlow in the past, but there are several alternatives: https://alternativeto.net/software/yahoo-yslow/ https://alternativeto.net/software/yahoo-yslow/

gpjanik 3y ago

Serious question: what is the issue with these paritcular sizes? I know that features/look these websites have are definitely achievable with less JS at a higher engineering cost, but what's the problem with it? 10MB loads in two seconds on an okay-ish desktop connection (correct me if I'm wrong, but most of people don't deploy Vercel apps from their phone from a mountain range with 3G connection). The experience on the websites mentioned is smooth as it can only get; everything is super fast and nice. Every subsequent click is just instant action. That's how web should look like. Is the problem here that they perform poorly on slower computers/connections? Is it even true? Is there an audience of developers who can't use Vercel or GitLab productively because of that? Any metrics to support that? IMHO optimizing against bundle size/JS sent over the network is one of the worst metrics for performance I could imagine.

alexey2020 3y ago
came here to write a similar comment. Totally agree! Focusing on a particular metric for the sake of the metric - what's the point? Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?
AHTERIX5000 3y ago
But the experience is not smooth as it can get if you're running a bit older HW. Gmail and Slack are notorious for bad performance even when the content displayed is rather simple plain text. As a user I don't really get anything in return when developers decide to use complex JS solutions for simple use cases.
npteljes 3y ago
I think it serves as a generic metric for bloat, because nobody really optimizes for size, thereby making it a good untainted metric. As the web gets bloaty and slow, the size of the websites grow as well, which also invites using size as a metric for bloat. Smooth, fast, nice, these would be good to measure, but it's much harder. I like an interface response time metric, for example [0]. I always lament that interfaces are getting slow - I get that they are nicer, too, but god damn why am I waiting 1 second for anything, when my Pentium III with Win XP was near instant? [0] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...

jwr 3y ago

I have a large and complex (ERP/MRP/inventory system for electronics) ClojureScript application and I was worried about my compiled code size being around 2.45MB. This puts it into perspective. I heard complaints about ClojureScript applications being large, which I think is true if you write a "Hello, world!" program, but not true for complex applications. Also, Google Closure compiler in advanced compilation mode is a great tool. Of course, since it is technically superior, it is not in fashion, and since it is hard to use correctly, people pretend it isn't there.

okaleniuk 3y ago

Meanwhile, all the pages on https://wordsandbuttons.online/ https://wordsandbuttons.online/ with all the animation and interactivity are still below 64 KB. This one, for example, https://wordsandbuttons.online/trippy_polynomials_in_arctangent_scale.html https://wordsandbuttons.online/trippy_polynomials_in_arctang... is 51 KB. And the code is not at all economical. It's 80% copy-paste with little deviations. There is no attempt to save by being clever either, it's all just good old vanilla JS. And no zipping, no space reduction. The code is perfectly readable when opened with the "View page source" button. The trick is - zero dependency policy. No third party, no internal. All the code you need, you get along with the HTML file. Paradoxically, in the long run, copy-paste is a bloat preventor, not a bloat cause.

lifthrasiir 3y ago
You can do the same with dependencies and "modern" JS toolkits. Dependency itself is not a cause but a symptom; websites and companies are no longer incentivized to reduce bloats, so redundant dependencies are hardly pruned.
kaba0 3y ago
It could add at least some minimal margin. On mobile, I literally can’t see the edges.

diimdeep 3y ago

Remember The Website Obesity Crisis [1] article from 2015, since then [2] things only got worse, and it is been almost 10 years already, well will be next year. Is it foolish to say that in 10 more years you wont be able to navigate the web on a circa 2015 PC ? If nothing changes seems like it. My old macbook from 2013 with latest Firefox is already can not handle loading https://civitai.com https://civitai.com web page with 23.98 MB of JavaScript, it is just hangs for half a minute while trying to render this disaster of web frontend. It is not just web, mobile all in one apps got so large that 2013 phone the same way unable to load them, and guess what, half of them are written on top of web tech stack, why three comma ,,, budget companies can not afford to write native application ? [1] https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm [2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=website%20obesity%20crisis&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

ulrischa 3y ago

Make Jquery great again

brap 3y ago

That dark-mode button is broken.

jongjong 3y ago

Just checked my SaaS platform. The entire application front end is 1.3 MB. But 300KB of that are font files and 490KB is for a cryptographic library for blockchain authentication. The thing is; I didn't use any bundling or minification. Also, it loads faster than most of the websites mentioned in this article and that's with minimal optimizations and my server being located on the other side of the world.

daflip 3y ago

All the js asset sizes quoted in the article seem inflated compared to the figures I see when I try to verify the authors figures.

danabramov 3y ago

The React site part of this is not real. The author ticked "Disable cache" which means the same code (which powers the interactive editable sandboxes they're scrolling by) gets counted over and over and over as if it was different code. If you untick "Disable cache", it's loaded once and gets cached.

fesc 3y ago
Yeah but once per page, which is why it is okay to disable cache as the author wanted to simulate a cold load of each of those pages.
- danabramov 3y ago
  That's also not true? I'm navigating between pages, and it does get served from cache for all subsequent navigations. The only case when this code gets loaded is the literally the first cold load of the entire site — and it's only used for powering live editable interactive sandboxes (surely you'd expect a in-browser development environment to require some client-side code). It doesn't block the initial rendering of the page. What is the problem?
- balls187 3y ago
  I think the issue isn't with the methodology (disabling cache), but rather the erroneous conclusion that the React.dev website continually requests data as somehow problematic when it's a sideeffect of disabling browser cache. Also, FWIW, OP is one of the authors of react.dev and a member of the react core team (not that it's relevant to the objection).

renegade-otter 3y ago

I often have to close a tab because my 12-core Mac mini starts heating the room and the fan sounds like it's about to fly off the axis. This is not specific to Javascript but the ad code doing this is obviously JS. Speaks more to the general Enshitifcation of the web. Does Web 3.0 fix this? /s

nazka 3y ago

Great article! But in the conclusion jQuery is enough? No thanks

Alifatisk 3y ago
jQuery being so lightweight compared to the rest felt a bit symbolical, Idk how to express it.

CraftThatBlock 3y ago

Also worth noting some of these website (such as Linear) pre-load other pages once the current page is done loading. The actual JavaScript on the page seems to be about 500kb (as opposed to 3mb)

farukmanon12 3y ago

[dead]

ohmantics 3y ago

What percentage of all that JS is just crap injected into sites by pointless invasive trackers?

qsantos 3y ago

Coincidently, I have written a browser extension to navigate Hacker News comments using Vi-style key bindings [1]. It has no compilation steps, no npm. It is mostly a 1kLoC file of vanilla JavaScript. Modern frameworks are definitely needed for large applications, but there is no need all that complexity when the scope is reduced. [1] https://github.com/qsantos/ViHN/ https://github.com/qsantos/ViHN/

mortallywounded 3y ago

SPAs were a psyop by FAANG companies to gain a monopoly and mind-share of developer talent. Are you team Google (Angular)? Meta (React)? Are you a hipster (Ember)? From there things only went downhill faster.

Alifatisk 3y ago
Why did you leave out Vue?
- mortallywounded 3y ago
  It came after the first wave of SPAs and if we listed every SPA framework (or "library") we'd be here all day.
  - Alifatisk 3y ago
    Oh I get it

qingcharles 3y ago

I work with newly-released prisoners and homeless people who are mostly on free Lifeline phones. They typically get 15GB of data a month. This is used up in 2-3 days on average. After that they can sometimes get 2G data, but it is impossible to use Google Maps to get to an interview, or even to download their email or fill out a job application online. Because the phone is no longer useable they often get lost or stolen. I regularly come across web sites with >250MB home pages these days. It doesn't take many of those to kill your entire data allotment.

jauntywundrkind 3y ago

It sucks that we blew up CDNs for security reasons. How nice it would be if sites using React could use the React already in cache from visiting another site! I keep wanting to have some kind of technical answer possible here. Seems hard. And who cares, because massive bundles are what we do now anyways, in most cases. But it sucks that the web app architecture and web resource architecture are both massively less capable than they were 20 years ago.

ivanjermakov 3y ago
Empty React app is ~400KB uncompressed AFAIR. So just CDNs wouldn't drastically improve the situation.
- jauntywundrkind 3y ago
  React was one example, of a library that might be used repeatedly. The premise isn't that react and react alone's core lib is reused (did you include react.dom too?), but that many different libs become cached over time & space.

ivanjermakov 3y ago

Don't get me started on mobile and desktop apps where 100MB is a bare minimum.

bufferoverflow 3y ago

If you want to see the framework that does it right, check out Qwik. Incredibly small JS / CSS bundles. Only loads what it needs. https://qwik.dev/ https://qwik.dev/

pepoluan 3y ago

Will using HTMX save a lot?

Alifatisk 3y ago

While I agree with the article, I am also obsessed with keeping the size as low as possible, I can't stop thinking about how it feels like the Author is somewhat mixing up webapps with websites. Websites requiring that much JS for doing very simple static tasks is bloat, but the same bar should not be set for webapps. It should still be required and a high priority to keep the bundle size low but webapps should be considered as different category. Websites can (and should) function without JS, webapps cannot. Another thing is that the Author only looked at the visible elements, for example on Google Translate and Outlook. What he did not consider is that there is a lot of more apps accessible behind the menus. If you take a closer look at Outlook at first glance, sure, it's just a simple app to display your emails. But on the sidebar you have access to a lot more features like calendar, contacts and the office suite.

jonaswalker305 3y ago

[dead]

wdbacker 3y ago

FYI, switching to dark mode makes the post unreadable ;-)