Thomas A. Valletta

What is a cookieless domain? A cookieless domain is a domain like any other. It is used to serve assets that will not use cookies. It is common to serve images, styles, and scripts from a cookieless domain.

Setting up a cookieless domain is simple. For a site located at www.mydomain.com one might consider registering www.mydomainassets.com as a cookieless domain. The name of the new domain is not important. The new cookieless domain may be configured to resolve to the same place as the original domain. All of the static files that will not use cookies may then be served from the new cookieless domain by simply changing the source location of that asset.

The value of a cookieless domain may seem small. All of the cookies for a single site are typically less than 10 kilobytes combined. So why go through the work for such a small gain? Because the cookies are sent with every request for every asset. A quick look at popular online news outlets showed an average of 150 requests were made to load the home page. One of the sites, http://msnbc.com, made 265 asset requests in order to load the main page. If 10 kilobytes of cookies were sent with every one of those requests, user’s browsers would be uploading more than 2.5 megabytes of cookies to request assets that would never use those cookies.

Uploading data that will never be used is particularly bad because client requests are not compressed like client responses. Server responses can be compressed to an average 25% of their original size. And many users have asymmetrical internet connections that provide download speeds that are up to 20 times greater than upload speeds. When these circumstances are stacked, 150 kilobyes of upload can take longer than 5 megabytes of response data.

The HTML 1.1 specification limits the number of connections that a browser can establish to a single domain to two connections. Most current browsers disregard this limit and allow for between four and eight connections per domain. Cookieless domains allow browsers to download twice the number of assets simultaneously by adding the extra domain.

Its cheap, easy, and improves the site performance. Win, win win.

I was trying to come up with a presentation demo that would show off the iOS gyroscope api.  At first the best that I could come up with was a scrolling marquee.  I thought that it would be cooler than it actually was.  You know those spinning LED toys that you pick up at county fairs, amusement parks and sporting events.  Something like that.  The plan was to show text far larger than could fit on the screen.  As the screen moved the text would essentially stay in place.  So waving a device back and forth should show the entire message.  Problem: sliding horizontally does not register on the gyroscope.

My second plan was a little better.   I could use the device as a remote control for a web bowling game.  The iOS gyroscope and accelerometer data together could provide a pretty decent bowling controller.  It would not be as accurate as a Wii or PS3 controller because those controllers have the benefit of an external camera that tracks their location.  But I could calculate a swing, rotation, and twist.  So I did it.  And it works.  The swing calculations could use some tweaking for sure, but here is the gyroscope and accelerometer code:


var ballGrab = function(e) {
  e.preventDefault();
  e.stopPropagation();
  playr.orient = [];

I have left out some bits of code here. The trimSwing() function goes backward through the orientation data to dump all except the data for the last forward swing. Then the calcSwing() turns the swing data into four basic values: power, acceleration, rotation, and twist.

The values are sent via socket.io to a Box2Djs front end that throws the ball into the pins. Box2Djs is equally cool. I will save that for another post. If you would like the complete code, you can find it on .