Making TinyPlazer more Tiny

I set up TinyPlazer.com a few months ago as a mobile-device-friendly way to update my [[Plazes]] geo-presence. I targetted it for my [[Nokia N95]] and because I use it without a data plan in Canada, its “tinyness” assumed a wifi connection. In other words, I wanted it to be lightweight, but I wasn’t counting the bytes.

Here in Copenhagen I do have a data plan on my mobile: it costs me 0,02 DKK per kilobyte of data transfer (this is 0.004 CAD, which makes Canadian Rogers Wireless pre-paid data 12.5 times more expensive than Danish Telia pre-paid data).

So today I used TinyPlazer.com for the first time over an actual GSM data connection. The process of identifying and confirming my Plaze, entering my status message, and receiving a confirmation cost me 0,30 DKK. Or about 6 cents CAD.

Which is certainly reasonable, and about 1/3 the price of updating my presence by SMS (0,20 DKK).

But, I ask myself, could it be even less?

The Web Developer add-on for Firefox told me the weight of all of the objects on the initial TinyPlazer.com page was 3KB: 1KB for the HTML itself, 1KB for the logo and 810 bytes for the CSS.

I was able to reduce the size of the CSS file from 810 bytes to 321 bytes just by removing styles I wasn’t actually using, consolidating some styles together, and removing whitespace. Similarly, I chopped 200 bytes out of the page itself by shortening class names, removing whitespace, and making better use of CSS, taking it from 1070 bytes to 848 bytes. I changed the logo from one big graphic to a small Plazes logo following by text, reducing the weight to 593 bytes.

The result was a total reduction in page weight to 1762 bytes.

The second “select your Plaze” has a varying weight depending on the number of Plazes returned. Because experience has shown I almost always pick from the top 5 displayed, even though I display 10, I reduced this to 5 selections.

Testing my changes with an actual GSM “plazing.” I found the combined effect of all of these changes lowered the per-Plazing cost by GSM data from 0,30 DKK to 0,22 DKK, or by about 25%.

This charge suggests a total data transfer of 11KB. My N95’s log (Applications \| Tools \| Log) shows 5KB sent and 5KB received:

Presumably Telia is doing some “round up to the nearest KB” to get the 11KB data charge.

Looking at the Apache server logs for this session, I see a record of five transactions, four GETs and one POST. Total data transfered: 3272 bytes. But this doesn’t count the HTTP send and response headers.

Looking at a sample HTTP transaction in more detail, the request for the CSS file, using cURL’s “trace” option, I find that the request for the 321 bytes of the file itself involves 242 bytes of send headers and 283 bytes of response headers, meaning that 321 bytes actually takes 846 bytes to transfer.

I traced the total data transfer for each of the five transactions:

So for what I’m able to count, I get a total sent data of 1365 bytes (vs. my phone’s 5KB counter) and a total received data of 4534 bytes (again, vs. 5KB counted by my phone), for a total of 6899 bytes. Which is not 11KB.

To try and see if there’s some sort of uncountable overhead involved with GSM data, I used Profimail to pick up my IMAP email over a GSM connection, and reset its data counters before I did. Profimail counted a total of 0.3KB sent and 5.69KB received, for a total of 5.99KB. My phone’s own log, however, shows 1KB sent and 8KB received, for a total of 9KB, which is 3KB more than Profimail reports. Telia billed me 0,20 DKK for this session, or 10KB.

This suggests that the data counting is happening at some deeper level, beyond my ability to measure, and perhaps involving the overhead of using TCP/IP over GSM. This “premium” appears to be about 50% of the data transfer that I can calculate, so that:

I’d welcome any insight others might have into this issue, and any suggestions you might have for reducing either the measurable or the “invisible” data transfer payload.