Hacker News Reader

Comment by arp242 | Hacker News Reader

A few years ago I did some measurements of popular projects (Wikipedia, WordPress, default React, jQuery, few things like that) comparing minify, minify+gzip, and just gzip, and found found that most minification beyond "removing comments" gives very little benefit even for poor 2G connections.

Especially things like removing as much whitespace as possible or replacing true/false with !0/!1 just don't really save a lot of space. The only two I found to make a significant difference were removing comments, and shortening identifiers (and usually with most of the savings being in "removing comments", depending on the amount of comments and code style).

View on HN

> Especially things like removing as much whitespace as possible or replacing true/false with !0/!1 just don't really save a lot of space.

At the scale of Wikipedia (~10 billion pageviews a month), even a single byte saving can mean terabytes worth of bandwidth saved.

> At the scale of Wikipedia (~10 billion pageviews a month), even a single byte saving can mean terabytes worth of bandwidth saved.

But does it really move the needle anywhere where it matters? If you are serving a million bytes in every response but you manage to trim a single byte from it, I don't think it is going to move the needle anywhere.

Sure it will save a terabyte when you have served a trillion responses. But in a trillion responses you are saving only one terabyte out of an exabyte of responses. That's not much!

Also keep in mind that for big web properties bandwidth is sold very differently than it is to normal consumers.

In many cases wikipedia probably isn't even paying for bandwidth due to peering agreement.

As far as performance goes, i suspect whether a single byte matters depends a lot more on if the extra byte results in the same number of packets or not.

So, why use two bytes for '!0' when just '1' works?

Its not strictly the same. '1' is a number whereas '!0' is a boolean.

I hate that language a bit more now

Both 1 and true are truthy, but not the same. That would work if the variable was only ever used in if(x), conditions, etc. Stringifying won't produce the same value either when passing values as well.

Because 1 !== true and 0 !== false in JavaScript:

  const index = "Hello HN".indexOf("H")
  console.log(index);
  >> 0
  index == false
  >> TRUE
  index === false
  >> FALSE

I see this type of reasoning a lot and it feels like it should have its own named fallacy. A tiny percent savings on a huge cost is a moderately big number, yes.

The problem here is that you've switched from proportional thinking to arithmetic thinking in the middle of the thought.

In most cases, if you started with proportional thinking, you should stick to it.

Example of the fallacy: 0.1% of my salary goes to avocado toast, which might not seem that much, but over ten years, that's a thousand dollars!

The fallacy here lies in the fact that a thousand dollars is insignificant over 10 years, but the statement makes it feel significant by switching from proportional to absolute.

"The avocado toast fallacy"?

Yes, but sometimes switching to arithmetic/absolute thinking is the right thing to do.

For example, suppose an engineer who is paid $200k per year can spend a week to implement an optimization that reduces costs by 0.1%. If that is 0.1% of something that costs $50 million per year, then that's not a bad use of time.

> For example, suppose an engineer who is paid $200k per year can spend a week to implement an optimization that reduces costs by 0.1%. If that is 0.1% of something that costs $50 million per year, then that's not a bad use of time.

Is it not? I don't know. I don't run a multi-million dollar business. So this is an honest question. 0.1% of $50 million is a meagre $50000. If someone is running a business that is spending $50 million per year on something, are they really going to care about a small $50k saving per year?

Well, it's not worth it to bring this optimization to the attention of the CEO. But it definitely exceeds the engineer's weekly cost by a lot, so if it only takes a week, it's potentially worth it (modulo opportunity costs for other things to work on).

Spin it around: is it worth it for a sales person who makes $200k per year to spend a week to land a $50,000 per year contract? I think it potentially is, for the same reason, even if the organization as whole makes hundreds of millions of dollars a year.

Your example is starting with absolute arithmetic, and sticking with it. There is no change.

google search engineering has entered the chat! https://www.google.com/search?q=google+41+shades+of+blue

> A tiny percent savings on a huge cost is a moderately big number, yes.

The thing is, say it takes me an hour to shave off ten bytes in the final build. Value my time per hour at 200$, and the saving of that ten bytes over a year at Wikipedia scale at a thousand dollars, and even investing five times that amount into yak shaving would still be net profitable.

It happens every single time when someone uses big time unit for shock effect

You're right, at some scales it does add up in a meaningful way, and making an informed decision based on that is entirely reasonable. However, most people operate nowhere near that kind of scale, and don't make an informed decision about this.

Are absolute numbers important in such a case? Percentages seem more appropriate.

Terabyte/month is around 3Mbit/ sec

Remember kids, if someone tries to use unusual time interval (like months for bandwidth-related stuff), they just want to make a small number look big

Is that correct? I get a larger number.

In either case, they said a single byte saved. Any amount of minification is going to save more than just a byte.

It’s also incredibly low effort to do so.

A lot of it reminds me of the olden days of Sinclair ZX81s with 1kB of memory, of which roughly half was free once you drew on the screen and defined a few variables.

We used to write things like "LET A=COS PI" instead of "LET A=1", or "SIN PI" instead of 0, because keywords were represented as a single byte and numeric constants as five bytes so two keywords represented a useful saving of three bytes.

Back then it made a huge difference but now that modern computers have hundreds or even thousands of kilobytes of RAM free it's a bit pointless.

> Back then it made a huge difference but now that modern computers have hundreds or even thousands of kilobytes of RAM free it's a bit pointless.

Jokes on you, now I'm running IntelliJ, DataGrip, Firefox, and Slack and thousands of kilobytes of RAM free is a rare sight to see.

they are really just doing us all a service, to remind us of the roots of computing, where every byte free was precious

You should try running visual studio 2022 and teams. On a medium sized project vs2022 will happily gobble 10+ gb of ram, and teams will take 1-2 more without supporting any meaningful scrollback. Even with ~500 tabs I can't hit 10gb ram in ff (thanks to tree style tabs to make it feasible to have so many tabs open).

You know what EMACS stands for?

Eight Meg And Constantly Swapping.

That joke was stale in 1994. You need to think of some new material.

Ooops, triggered one of the last dozen or so folk still using EMACS.

I'm not. It's just a trite and boring old "joke", made even more trite and boring on account of this thread not even being about Emacs.

how does minify affect the times to decompress and load the css I wonder?

My money is on much less than the time it would take to send the extra bytes over the wire. But I suppose measurement is key :D

Unless client combines decompress and CSS parsing, they would at least allocate memory for the whitespace before parsing and then skipping them.

It might be better to have slightly bigger payload on the wire to save time after decompress.

Reply on news.ycombinator.com