> For example: optimize PNGs, it's easy and a one time procedure.
And then that PNG is loaded by a webpage, which contains no HTML, but loads 28 megabytes of JS, which your browser has to parse, JIT and run, and then that triggers loading of web-fonts, and after that we create a virtual DOM, and then render that into a real DOM... (which is probably around 150kb)
And then after about 15 seconds of 100% CPU time, the browser finally has something to show... And then it loads that minified PNG.
You know what? That PNG isn't the issue. That PNG probably has a highly optimized decoder, written in native code, and the relative cost of a optimized/unoptimized PNG in this case is probably 0.0001% of the total energy we just spent getting and rendering that page, a page which more often than not contains basically static content.
If that page instead:
1. had been plain, pre-rendered HTML
2. had no JS, except if needed.
3. had no web-fonts, because the user already has 2000 fonts installed. (And you want to be green, right?)
4. And finally had that PNG.
Then optimizing that PNG would actually have an impact. On most sites today though? Not a chance in a hell.
Also: that page would render in a nano-second, so it's not just a greenification, it's an actual real world performance-optimization too.
The savings made by a single png doesn't change in this scenario, it just drowns. One thing you can do: optimize pngs. Another thing you can do: optimize js. Focusing on the largest sinner first makes some sense, but doesn't change the fact that optimizing a png will certainly save the whales.
And then that PNG is loaded by a webpage, which contains no HTML, but loads 28 megabytes of JS, which your browser has to parse, JIT and run, and then that triggers loading of web-fonts, and after that we create a virtual DOM, and then render that into a real DOM... (which is probably around 150kb)
And then after about 15 seconds of 100% CPU time, the browser finally has something to show... And then it loads that minified PNG.
You know what? That PNG isn't the issue. That PNG probably has a highly optimized decoder, written in native code, and the relative cost of a optimized/unoptimized PNG in this case is probably 0.0001% of the total energy we just spent getting and rendering that page, a page which more often than not contains basically static content.
If that page instead:
1. had been plain, pre-rendered HTML
2. had no JS, except if needed.
3. had no web-fonts, because the user already has 2000 fonts installed. (And you want to be green, right?)
4. And finally had that PNG.
Then optimizing that PNG would actually have an impact. On most sites today though? Not a chance in a hell.
Also: that page would render in a nano-second, so it's not just a greenification, it's an actual real world performance-optimization too.