3 ms·

Most of the work would be essentially quick and one-off: no one blinks at minifying JS or CSS and I bet that 50% of this would be entirely the same and at low d

by DamonHD 10y ago

Most of the work would be essentially quick and one-off: no one blinks at minifying JS or CSS and I bet that 50% of this would be entirely the same and at low dev cost. I entirely see your point, but disagree that it's not worth doing any of it, given an almost certain quick small win + saving CPU time and bandwidth and a bit of planet while we're at it!

acdha 10y ago
> Most of the work would be essentially quick and one-off: Again, think about the complexity of what's generating that content. Do you really think they have a single index.html template floating around rather than the system described pulling blocks of content in from various sources, all of which need to be updated in various places? You could build a system to collapse whitespace runs after the content is generated but now you need to develop that and test it to make sure it doesn't trigger on something where the whitespace actually matters … and suddenly you're taking time away from changes which actually benefit people. > given an almost certain quick small win + saving CPU time and bandwidth and a bit of planet while we're at it! How much CPU time do you think you're talking about, anyway? Here's what doing this in a naive manner which will break things looks like: cadams@jupiter:~ $ gzip -9 < bbc.html | wc -c 32259 cadams@jupiter:~ $ curl -s http://www.bbc.com | perl -pe 's/\s+/ /gs' | gzip -9 | wc -c 30859 So we're talking an extremely small amount of CPU time and one packet saved. That's might seem useful until you look at this in context of a page which loads a couple MB of content and uses multiple seconds of CPU time: https://www.webpagetest.org/result/170424_NT_W4S/ https://www.webpagetest.org/result/170424_NT_W4S/ Image compression, enabling gzip on the remaining resources which lack it, etc. are all going to save more data on individual files and have the nice property of not breaking anything else.
- DamonHD 10y ago
  I'm not saying don't do the other things too, but a ~5% saving (maybe more at a more typical gzip TX setting) for no semantic change at all saves some outgoing BBC resource but is more significant for the RX side in CPU, etc. Anyhow we can agree to disagree but many of my clients over the years have been very happy with 5% resource savings, although 5x is nicer when available... B^> (And yes I'm fudging CPU and bandwidth, but with a compressor involved and the CPU often being a bottleneck on lower-end devices for example, I think that simplification can be justified.)

by DamonHD 10y ago

acdha 10y ago

> Most of the work would be essentially quick and one-off: Again, think about the complexity of what's generating that content. Do you really think they have a single index.html template floating around rather than the system described pulling blocks of content in from various sources, all of which need to be updated in various places? You could build a system to collapse whitespace runs after the content is generated but now you need to develop that and test it to make sure it doesn't trigger on something where the whitespace actually matters … and suddenly you're taking time away from changes which actually benefit people. > given an almost certain quick small win + saving CPU time and bandwidth and a bit of planet while we're at it! How much CPU time do you think you're talking about, anyway? Here's what doing this in a naive manner which will break things looks like: cadams@jupiter:~ $ gzip -9 < bbc.html | wc -c 32259 cadams@jupiter:~ $ curl -s http://www.bbc.com | perl -pe 's/\s+/ /gs' | gzip -9 | wc -c 30859 So we're talking an extremely small amount of CPU time and one packet saved. That's might seem useful until you look at this in context of a page which loads a couple MB of content and uses multiple seconds of CPU time: https://www.webpagetest.org/result/170424_NT_W4S/ https://www.webpagetest.org/result/170424_NT_W4S/ Image compression, enabling gzip on the remaining resources which lack it, etc. are all going to save more data on individual files and have the nice property of not breaking anything else.

DamonHD 10y ago
I'm not saying don't do the other things too, but a ~5% saving (maybe more at a more typical gzip TX setting) for no semantic change at all saves some outgoing BBC resource but is more significant for the RX side in CPU, etc. Anyhow we can agree to disagree but many of my clients over the years have been very happy with 5% resource savings, although 5x is nicer when available... B^> (And yes I'm fudging CPU and bandwidth, but with a compressor involved and the CPU often being a bottleneck on lower-end devices for example, I think that simplification can be justified.)