4 ms·

Not quite, there is a difference... but close enough. If we all stopped minifying tomorrow, I doubt a single end user would notice. The few kilobytes you save d

Not quite, there is a difference... but close enough. If we all stopped minifying tomorrow, I doubt a single end user would notice. The few kilobytes you save don't really matter when you're downloading a 12 MB image as well.

eyelidlessness 6y ago
It really does matter. Script execution is much more expensive than image rendering. A 12 MB JS file has a much bigger impact than a 12 MB JPEG.
- selcuka 6y ago
  I'm not convinced that minification actually speeds up execution. Initial parsing, maybe a little bit because of the lack of comments and whitespace. Execution, I don't think so.
  - eyelidlessness 6y ago
    It doesn’t, and no one claims it does. Some compilers (eg Closure) do other optimizations that might help, but the benefit is starting the execution sooner. 10% of the time on the wire for code that performs the same is still 90% time on the wire faster load time.
    - selcuka 6y ago
      Sorry if I'm missing anything but how does this support your original comment? The benefit of starting the execution sooner is the same as the benefit of starting the image rendering sooner. Maybe what you were trying to say was that scripts are more important than images for a web app (which I would agree). If "script execution is much more expensive than image rendering" it makes compression even less relevant for scripts. If it takes 2s to execute a script the 0.1s gain on the wire is negligible.
      - eyelidlessness 6y ago
        > Sorry if I'm missing anything but how does this support your original comment? The benefit of starting the execution sooner is the same as the benefit of starting the image rendering sooner. Because it’s not the same benefit. Executing the JS is more expensive than rendering the image. That’s just starting at square one. To the extent executable code can be delivered faster, it also opens possibilities of using those gains to support newer codecs with much smaller image sizes and reduce time on the wire even further; this generally leads to WASM, but the idea is the same. > Maybe what you were trying to say was that scripts are more important than images for a web app (which I would agree). Nope. I’m saying that JS execution has a bigger impact on websites feeling slow than large images rendering. It’s probably more noticeable on content driven sites because they’re expected to load faster (and more likely to paint but have a long janky interactivity gap). > If "script execution is much more expensive than image rendering" it makes compression even less relevant for scripts. If it takes 2s to execute a script the 0.1s gain on the wire is negligible. I honestly can’t even follow your logic. It’s not just “expensive” in the abstract, it’s the largest contributor to pages feeling slow for users. Shaving 5% (which is an arbitrary measure, and far less likely to be true on slower connections) off that might mean the difference between whether they even see your page, or its gargantuan images loading in, at all.

eyelidlessness 6y ago

It really does matter. Script execution is much more expensive than image rendering. A 12 MB JS file has a much bigger impact than a 12 MB JPEG.

selcuka 6y ago
I'm not convinced that minification actually speeds up execution. Initial parsing, maybe a little bit because of the lack of comments and whitespace. Execution, I don't think so.
- eyelidlessness 6y ago
  It doesn’t, and no one claims it does. Some compilers (eg Closure) do other optimizations that might help, but the benefit is starting the execution sooner. 10% of the time on the wire for code that performs the same is still 90% time on the wire faster load time.
  - selcuka 6y ago
    Sorry if I'm missing anything but how does this support your original comment? The benefit of starting the execution sooner is the same as the benefit of starting the image rendering sooner. Maybe what you were trying to say was that scripts are more important than images for a web app (which I would agree). If "script execution is much more expensive than image rendering" it makes compression even less relevant for scripts. If it takes 2s to execute a script the 0.1s gain on the wire is negligible.
    - eyelidlessness 6y ago
      > Sorry if I'm missing anything but how does this support your original comment? The benefit of starting the execution sooner is the same as the benefit of starting the image rendering sooner. Because it’s not the same benefit. Executing the JS is more expensive than rendering the image. That’s just starting at square one. To the extent executable code can be delivered faster, it also opens possibilities of using those gains to support newer codecs with much smaller image sizes and reduce time on the wire even further; this generally leads to WASM, but the idea is the same. > Maybe what you were trying to say was that scripts are more important than images for a web app (which I would agree). Nope. I’m saying that JS execution has a bigger impact on websites feeling slow than large images rendering. It’s probably more noticeable on content driven sites because they’re expected to load faster (and more likely to paint but have a long janky interactivity gap). > If "script execution is much more expensive than image rendering" it makes compression even less relevant for scripts. If it takes 2s to execute a script the 0.1s gain on the wire is negligible. I honestly can’t even follow your logic. It’s not just “expensive” in the abstract, it’s the largest contributor to pages feeling slow for users. Shaving 5% (which is an arbitrary measure, and far less likely to be true on slower connections) off that might mean the difference between whether they even see your page, or its gargantuan images loading in, at all.