I think a lot of you are seriously missing the point when you're suggesting c/c++/asm, or even c#/VB.NET/Delphi as suitable languages. The idea is not to start them on the shortest path to them to become the perfect programmer with impeccable knowledge of the machine and computer science principles, but rather to spark a passion in them for programming that they will continue of thier own volition. Let them get interested first, then they can learn to program properly later.
The problem with using low level languages, or widely used commercial languages is that the languages are too complicated, the libraries are too big (Java, .NET etc have huge base class libraries full of useful stuff but its way to overwhelming when starting off) or the tools/ides themselves are too complicated (try explaining the ins and outs of eclipse or visual studio to a kid).
Thinking back to when I learned to program in QBasic I think the ideal language is one that is simple to make stuff happen on screen (Most kids start programming so that they can make games, so you need something which gives them the impression, at least initially that graphics and interactivity is an achievable goal),is fairly limited in its base libraries (this forces you to learn to solve common comp sci problems, or at least think about solutions to them as the libraries won't do it all for you), and has a slow execution environment (this forces you to think of better ways to do things and work within the constraints of the language).
My suggestion is javascript/HTML, the IDE is the most familiar app to most computer users - the browser, you don't need any dev tools, its totally cross platform, you have access to a powerful and pretty easy to understand display engine with html/css and you can write anything from a picture gallery to a text adventure, to a mario clone depending on your skill level.

The Aptimize website accelerator (www.aptimize.com) does exactly this, except its implemented as an output filter on your webserver so content is dynamically optimized as it is sent to the user, obviating the need for a separate optimizing deployment process. It does things like combining css and javascript references on a page, inlining css background images, and combining images into css mosaics to reduce request counts, minifying css and javascript files, and adding proper cache headers to all page resources to reduce redundant requests on warm loads of the page. Typically this can reduce page load times by 50% or more, especially over high latency connections.

Most of the optimization suggestions in TFA are going to offer no real performance benefit. With gzip on, whitespace, long ID's & viewstate make pretty much no impact on the final page weight, but doing these "optimizations" is going to make your page a hell of a lot harder to maintain. Don't believe me, go to webpagetest.org and have a look, HTML accounts for only around 5% of the final page size. The best thing these guys could do to optimize the site would be to

• combine the css and javascript files.
• minify the javascript (as it is its taking up around 20% of the page weight)
• perform more aggressive css spriting of the gif and jpeg images to slash the request count further.
• remove ETag headers and add far future expiry headers to the images to speed up repeat page views and cut down on 304 responses from the server.

Who cares about a 30 byte http header when your page is over 800k and ~45 requests, there's plenty of low hanging fruit to pick first. Interesting thing is in the post above a tool called the rpo is mentioned, it seems to do most of the important optimizations automatically.