What about Web sites that send cookies using the HTTPonly flag so that cookies aren't readable via JavaScript?

Have the Feds, or any other major service, looked at using DOM Storage as an alternative to cookies? DOM Storage allows for more data to be stored, and it removes extra data being transferred via every HTTP request. Yes, it is only available in modern browsers, but that need not stop its use, or at least making policy towards its use.

CSP is effectively server-side NoScript. And it isn't exactly new either. This has been in development as a Firefox extension for at least a year. The article mentions it being first crafted back in 2005.

The issue I take with this article is that they suggest this feature could even possibly be integrated into eBay or MySpace. These two giants seem like the exact opposite type of market that would use this -- any site that allows users to post their own data is not going to possibly survive the wrath they would catch if users had to explicitly allow the domains they want scripts to run on. For a corporate Web site yes, but for something for the masses or those of us that run a CMS? I don't see that as happening anytime soon.

I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.

Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.

I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.

1. Defer, though being a part of the HTML 4.01 spec, is only supported by IE. And even if other browsers supported it they could not use it because they need to know that the content had been loaded before they execute the tracking code.
2. The vast majority of developers just copy and paste the code as given. This code is an internal script tag that derives the protocol that is currently being used to then refer to the HTTP or HTTPS file using document.write, and then a second internal script tag that starts the tracking using your unique id while inside of a try/catch block.

Honestly, I believe Google is trying to piss people off with Google Analytics. First the code that they present that every developer just copies and pastes because Google tells them to loads the code in a blocking manner, and then a little while back they have turned off gzip compression so they file took even longer to transfer. Heck, I'd forgive them for the second if they would at least update the code they tell developers to copy and paste to load GA in a non-blocking manner. Yeah, it's a bit more code to tell developers to add to their pages, but the improved user experience makes it worth the extra few bytes. All you need to do is create a script element with the src attribute pointing to the URL for the via JavaScript, append the DOM node to the head, and then create a timer that checks to see if the GA code has finished transferring (which you'll know by testing to see if _gat is undefined) before you run initialize your tracking code, then kill the timer.