4 ms·

I (thought) I saw where the article was going before it got there, but, the notion that the 'optimization' actually increases gzipped sizes surprised me (I

I (thought) I saw where the article was going before it got there, but, the notion that the 'optimization' actually __increases__ gzipped sizes surprised me (I thought the conclusion was going to drive at 'it makes no difference', or 'only a byte or two saved'). I don't have a site that sees a ton of traffic, and I know what some of my direct competitors spend on IAAS (and how long their pages take to load). I'm orders of magnitude below it - hence, I do not spend much time investigating optimizations. I can name a list as long as my leg as to where I bet I can win quite a bit on optimizing for IAAS cost or UX speed. Business-wise I decided it's not (currently!) worth investigating. One of the more intriguing ones on my list is that I __do not minify anything__. My reasoning is that post-gzip, who cares. It's such a tiny difference. Yes, turning e.g. class names or whatnot in the CSS, or local identifiers in javascript, into short letter sequences means even post-gzip it'll be smaller, but by so little. The reduction in file size when e.g. eliminating all unnecessary whitespace is really, really tiny. For any site that isn't trying to optimize for 'millions of hits a day!' levels of traffic, why _do_ you minimize all that stuff? It makes the developer experience considerably shittier and the gain seems a few orders of magnitude too small to even bother with it.

williamdclt 3y ago
You make decent points, but for this one: > It makes the developer experience considerably shittier and the gain seems a few orders of magnitude too small to even bother with it. Does it? It's very rare that I interact with the minimised code
- ravenstine 3y ago
  Wouldn't that have to be due to your setup not minifying code during development? That's typical to a lot of web frameworks, if not nearly all of them. I think the OP may be referring to situations where production needs to be debugged, in which case navigating production code usually becomes a massive pain in the rear.
  - zamadatix 3y ago
    Source maps generally solve most of the pain automatically. They aren't perfect, but production bugs don't mean you need to look at minified code often. That said, if one can get away with not needing to do more work and still have a performing site then how little the difference is remains irrelevant.
    - no_wizard 3y ago
      esp. if you upload your source-maps to your logging platform of choice. All the major ones support it that I've interacted with so far.
    - ravenstine 3y ago
      > They aren't perfect, That's a problem in its own, though. While I agree that source maps can and often do solve the minification problem/confusion, it can also introduce another "vector" for something to go wrong and make production debugging a pain. Like everything, it's about tradeoffs. I've worked on some apps where, yes, minification really did matter, but minification has also become a default even when it's questionable whether it's even called for. Whereas just shipping the code as-is is less likely to introduce a pain point when debugging, source maps are more likely to introduce them when the source map somehow doesn't work or, in rare circumstances, can't accurately represent the runtime code when transpilation is emulating the original code by doing something almost completely different somewhere down the chain. Although this is an "it depends" thing, like everything else, I lean on the side of not minifying things in 2023 when both gzip is adequate and the time it takes to parse and run the main code is not the source of performance problems. But the last time I brought a similar topic, a bunch of HNers got mad because "starving people in Africa with flip phones and 3G tho", so maybe I'm still objectively wrong years later.
    - ilyt 3y ago
      Extra step to worry about, need to always use things that support it, and it is solving self-inflicted problems
kevingadd 3y ago
Part of the reasoning behind minification is that it theoretically makes JS parsing (and compilation) faster thanks to reduced whitespace and shorter identifiers. At this point you won't notice the impact of that on developer hardware, but it probably still matters on cheap phones and old PCs. The file size improvement really doesn't matter compared to that - you only download the file once* but it gets parsed and compiled on every page load** * assuming your website doesn't get instantly evicted from cache. ** modern browsers have mechanisms for caching the parsed/compiled code for a given JS file hash, I think, but I don't know how it works
- zelphirkalt 3y ago
  I doubt, that parsing code with longer identifiers really makes any noticeable difference even on old hardware. Parsing the code will most likely not be the bottleneck. Running an JS code is most likely going to take more time than parsing it. It is such a micro-optimization, that it is not worth even the development overhead of setting up a minimizer.
  - kevingadd 3y ago
    If you shrink a JS file by 50kb or more via minification (some JS libraries are a meg or more, so this is a realistic scenario - if not understating how much a minifier can do) that's a meaningful reduction in the # of bytes being processed. With how optimized and parallelized modern JS runtimes are it's probably only a few ms in total savings, but on older devices it could save more time. Historically it's been proven that small improvements to load time can have a measurable positive impact on a website. Identifiers are often turned into atoms (which makes table lookup performance not really depend on how long they are) but for cases where identifiers are being looked up in dictionaries as raw strings, making them shorter could also improve runtime performance for your JS. I'm not sure how much this actually matters in practice though - I've seen dictionary key lookups show up in profiles here and there but it's usually not the main bottleneck.
hinkley 3y ago
CSS and JavaScript are partially ordered file formats, and there are some tricks one can do with that to boost compression ratios, with or without minification. In a Java minifier ages ago, I modified it to suffix sort the constants pool and saw a little over 1% further size reduction. Given that the pool is half of the file, that’s >2% on the pool. The reason for suffix sorting was that entities in bytecode, JS and CSS often have end of statement markers, so suffix sorting gets you slightly longer runs than prefix sorting.

I (thought) I saw where the article was going before it got there, but, the notion that the 'optimization' actually __increases__ gzipped sizes surprised me (I

williamdclt 3y ago

You make decent points, but for this one: > It makes the developer experience considerably shittier and the gain seems a few orders of magnitude too small to even bother with it. Does it? It's very rare that I interact with the minimised code

ravenstine 3y ago
Wouldn't that have to be due to your setup not minifying code during development? That's typical to a lot of web frameworks, if not nearly all of them. I think the OP may be referring to situations where production needs to be debugged, in which case navigating production code usually becomes a massive pain in the rear.
- zamadatix 3y ago
  Source maps generally solve most of the pain automatically. They aren't perfect, but production bugs don't mean you need to look at minified code often. That said, if one can get away with not needing to do more work and still have a performing site then how little the difference is remains irrelevant.
  - no_wizard 3y ago
    esp. if you upload your source-maps to your logging platform of choice. All the major ones support it that I've interacted with so far.
  - ravenstine 3y ago
    > They aren't perfect, That's a problem in its own, though. While I agree that source maps can and often do solve the minification problem/confusion, it can also introduce another "vector" for something to go wrong and make production debugging a pain. Like everything, it's about tradeoffs. I've worked on some apps where, yes, minification really did matter, but minification has also become a default even when it's questionable whether it's even called for. Whereas just shipping the code as-is is less likely to introduce a pain point when debugging, source maps are more likely to introduce them when the source map somehow doesn't work or, in rare circumstances, can't accurately represent the runtime code when transpilation is emulating the original code by doing something almost completely different somewhere down the chain. Although this is an "it depends" thing, like everything else, I lean on the side of not minifying things in 2023 when both gzip is adequate and the time it takes to parse and run the main code is not the source of performance problems. But the last time I brought a similar topic, a bunch of HNers got mad because "starving people in Africa with flip phones and 3G tho", so maybe I'm still objectively wrong years later.
  - ilyt 3y ago
    Extra step to worry about, need to always use things that support it, and it is solving self-inflicted problems

kevingadd 3y ago

Part of the reasoning behind minification is that it theoretically makes JS parsing (and compilation) faster thanks to reduced whitespace and shorter identifiers. At this point you won't notice the impact of that on developer hardware, but it probably still matters on cheap phones and old PCs. The file size improvement really doesn't matter compared to that - you only download the file once* but it gets parsed and compiled on every page load** * assuming your website doesn't get instantly evicted from cache. ** modern browsers have mechanisms for caching the parsed/compiled code for a given JS file hash, I think, but I don't know how it works

zelphirkalt 3y ago
I doubt, that parsing code with longer identifiers really makes any noticeable difference even on old hardware. Parsing the code will most likely not be the bottleneck. Running an JS code is most likely going to take more time than parsing it. It is such a micro-optimization, that it is not worth even the development overhead of setting up a minimizer.
- kevingadd 3y ago
  If you shrink a JS file by 50kb or more via minification (some JS libraries are a meg or more, so this is a realistic scenario - if not understating how much a minifier can do) that's a meaningful reduction in the # of bytes being processed. With how optimized and parallelized modern JS runtimes are it's probably only a few ms in total savings, but on older devices it could save more time. Historically it's been proven that small improvements to load time can have a measurable positive impact on a website. Identifiers are often turned into atoms (which makes table lookup performance not really depend on how long they are) but for cases where identifiers are being looked up in dictionaries as raw strings, making them shorter could also improve runtime performance for your JS. I'm not sure how much this actually matters in practice though - I've seen dictionary key lookups show up in profiles here and there but it's usually not the main bottleneck.

hinkley 3y ago

CSS and JavaScript are partially ordered file formats, and there are some tricks one can do with that to boost compression ratios, with or without minification. In a Java minifier ages ago, I modified it to suffix sort the constants pool and saw a little over 1% further size reduction. Given that the pool is half of the file, that’s >2% on the pool. The reason for suffix sorting was that entities in bytecode, JS and CSS often have end of statement markers, so suffix sorting gets you slightly longer runs than prefix sorting.