Q:

Why don't you get rid of your newlines and spaces (minifi your pages)?

The following script will tell you that you could be reducing the size of your pages by 10-13% if you chose to get rid of superfluous white space and newlines.
import urllib2
SITES = ["stackoverflow.com",
    # put all your sites domains here...
     ]

stats = []
for site in SITES:
    stream = urllib2.urlopen("http://"+site).read()
    before = len(stream)/1024.0
    after = len(" ".join(stream.strip().split()))/1024.0
    savings = before-after
    stats.append((site, before, after, savings, savings/before*100))
    print "{0:<30} {1:>5.1f} {2:>5.1f} {3:>5.1f} {4:>4.1f}%".format(*stats[-1])

The results:
stackoverflow.com              194.2 169.6  24.6 12.7%
meta.stackoverflow.com         124.6 109.1  15.4 12.4%
superuser.com                  120.9 105.9  15.0 12.4%
serverfault.com                121.0 106.0  15.0 12.4%
stackapps.com                  122.4 102.5  19.9 16.3%
careers.stackoverflow.com       15.1  12.6   2.4 16.2%
cooking.stackexchange.com      119.9 104.6  15.2 12.7%
area51.stackexchange.com        31.0  24.6   6.4 20.6%
webapps.stackexchange.com      118.2 103.0  15.2 12.9%
gaming.stackexchange.com       117.7 102.5  15.2 12.9%
ubuntu.stackexchange.com       125.5 108.2  17.3 13.8%
webmasters.stackexchange.com   117.9 102.7  15.2 12.9%
gamedev.stackexchange.com      117.8 103.0  14.8 12.6%
math.stackexchange.com         118.9 103.5  15.4 13.0%
photography.stackexchange.com  132.8 115.5  17.3 13.1%
stats.stackexchange.com        130.0 112.6  17.4 13.4%
tex.stackexchange.com          120.4 105.1  15.4 12.8%
english.stackexchange.com      119.6 104.1  15.4 12.9%
cstheory.stackexchange.com     121.8 106.9  14.9 12.2%
programmers.stackexchange.com  117.9 103.2  14.8 12.5%
unix.stackexchange.com         116.7 101.4  15.3 13.1%
apple.stackexchange.com        119.5 104.1  15.4 12.9%
wordpress.stackexchange.com    126.3 109.0  17.4 13.7%
physics.stackexchange.com      120.7 105.4  15.3 12.7%
diy.stackexchange.com          119.4 104.2  15.2 12.8%
gis.stackexchange.com          127.4 110.1  17.3 13.6%
electronics.stackexchange.com  124.8 107.4  17.4 14.0%
android.stackexchange.com      125.7 108.5  17.3 13.7%
security.stackexchange.com     127.8 110.4  17.4 13.6%

Considering that you must get tens of millions of hits a month, probably this can translate to real bandwidth savings or improved response times. Now, I am aware that the time it takes to get rid of the newlines and whitespace may be longer that actually rendering the page, but probably you can improve your templates so that they are served with less superfluous stuff.
Does this make sense or is it akin to polishing a cannon ball?
Edit:
Thanks for the answers. Conclusion: it is like polishing a cannon ball.

A:

You're neglecting gzip in your scenario it appears.  Once you factor it in, you're only going to see savings of 10% or so over already gzip'd content (the savings of gzip vs. ungzip'd is something like 70%, for comparison).  This is based on just looking at the home page, I suspect the savings are just as lean (if not leaner) on the rest of the sites' pages.
Weigh this against the implementation of stripping out white space.
You've basically got to re-parse the HTML (either as you're writing it out, or after the whole page has been rendered) to figure out what white space is truly safe to strip.  You've got make sure this parsing is fast enough to not affect page load times (which we're very serious about), and robust enough to deal with anything a person might manually enter into a post.
It's an expensive proposition, for not a lot of gain, basically.

A:

Per some tests I did a long time ago:
http://www.codinghorror.com/blog/2007/03/reducing-your-websites-bandwidth-usage.html

Realistically, whitespace and linefeed removal is doing work that the compression would be doing for us. We're just adding a dab of human-assisted efficiency:
                 Raw              Compressed
Unoptimized CSS  2,299 bytes      671 bytes
Optimized CSS    1,758 bytes      615 bytes

It's only about a 10 percent savings once you factor in HTTP compression.

Personally I find that  ...

destroying the readability of view source
the potential performance penalty of running this real time on every page output
the risk of getting the whitespace/linefeed removal wrong and causing invalid HTML

... is not worth a measly 10% reduction in bytes over the wire.
It really feels like a micro-optimization since gzip gets you 90% of the way there.

