dotMobimobiThinkingmobiForgemobiReadyDeviceAtlasgoMobi
background image

The mysteries of mobile data plans or It’s all about Page Weight

Ronan_Mandel's picture
Posted by Ronan_Mandel - 01 Jul 2008
Twitter share icon Facebook share icon Google Plus share icon

So I have to make a confession (seems like I’ve been doing that a lot recently…) For the first time in my life I received a mobile phone bill with data charges on it. What you say? Are you some sort of imposter? Have you not been using mobile data all these years? Well, here’s the thing: I’ve been using it for free (we’ll, it’s all been on the company’s dime that is) so it never really hit me how much it really cost.

I’m an AT&T customer here in the states (out of convenience sake). My mobile and data bill are still on the company tab, but the Mrs. has recently started using her device as a data modem. There have been all sorts of stories about crazy mad data charges such as this gem from The Register Man uses mobe as modem, rings up £27k phone bill but I never though it could happen to me (famous last words). Fortunately my wife is neither a YouTube addict nor a P2P junkie, and was just accessing her email from a work site that did not provide her with a data connection. I figured how bad could it be… We had an extra $16 tacked on to our bill this past month. Ok, not so bad, but then I looked at the amount of data we actually used: 1.6 MB. So they’re charging $.01/kb. I’m sure to the average Joe, that number sounds pretty cheap. Heck, I’m only going to browse around every now and again, so at a penny a k, no big whoop. Does anyone really pay attention to the size of the pages they download (in kb that is)? I’d think not.

In light of the fact that the operators are pushing ‘open web browsing’ it’s worth looking at the sizes of pages out there in the wild. A 1200 word blog entry on the c|net news.com site weighs in at 457k. On my current data plan, just viewing that one page would cost me nearly $5. Suddenly those transcoding proxies don’t sound so evil anymore. Now before I piss off the folks around the corner from me here in San Francisco, let me add that there is also a mobile specific version of this very same page delivered from m.cnet.com which comes in at a total weight of 87k (of which 76k are images). Still, I’m looking at nearly a buck to read that story. For that I could have gone out and downloaded the latest track from Katy Perry… Actually it’s just one of the images that’s the offender weighing in at a whopping 67k. Now come on, that’s my money for the candy machine, and I’d much rather have that Twix than higher resolution screen shot of an Android phone. Compressing images for the purpose of delivery via the web (mobile or otherwise) is certainly nothing new. Using the out of the box tools from any one of the major image editing tools vendors (Adobe included… ? ) will easily crunch that image down to something on the order of 9k and without loss that would make any difference.

What else can you do to lighten the load (and the bill) on your end users? Well, think about the CSS that you’re delivering. While true that inline style may be more efficient from a performance perspective, it’s clearly less manageable than external style sheets and results in redundant code and bloat. Even when you move to external, linked style sheets, make sure that you prune out the styles that are not going to be used by your pages or are relevant only to the desktop version of your site. Along those same lines, be sure to leverage the inheritance properties of CSS rather than re-defining properties that could have just as easily been inherited or grouped. Specifically code like

	.myContent {
		font-size: smaller;
		margin-left: 2px;
		color: red;
	}
 
	.myOtherContent{
		font-size: smaller;
		margin-left: 2px;
		color: green;
	}

Can be more efficiently delivered as

	.myContent, .myOtherContent{
		font-size: smaller;
		margin-left: 2px;
		color: red
	}
 
	.myOtherContent{
		color: green;
	}

Sure, maybe you’re only saving a couple of lines here, but if you spread this thinking across all of your pages, it starts making sense. Also, remember to set the cache-control on your style sheets so that they live on locally and therefore can be leveraged across your entire site, thus further reducing the tax on each page.

Sure, flat rate data is all the rage these days, but assuming that it’s in place for all of your users could be costly for them, and as a result, costly for you in the long run. I’m not advocating anything new here, as these concepts are covered in sections 4.2.3 and 4.2.4 of the Switch On! Guide, but I do think that they’re worth reiterating and it’s always good to think about the cost to the end user of your service. While I can pretty much guarantee that no individual end user is going to pour back over their browsing history to find the bloated sites that plumped up their data bill, they’re much more likely to stop browsing all together, so not only do you lose a user, you could be poisoning the punch for everyone out there…


Posted by Ronan_Mandel - 01 Jul 2008

Ronan_Mandel's picture

Ron Mandel has extensive experience in mobile. After 8 years in the industry working for Openwave he is now with Adobe.

Posted by James Pearce 6 years ago

Here's quite a clever CSS optimizer which compresses file sizes and can even be made to optimise the selectors used.

(What the world probably needs is one of these that also strips out any selectors or properties that the client device is known not support anyway...)

Posted by jonarne 6 years ago

Good post! Important to point the spotlight in this direction! Wrote a post on the data cost issue my self: http://dev.mobi/blog/fighting-data-cost

-- Jon Arne S.

Posted by dean.collins 6 years ago

I totally agree with you.

Too many mobile website developers aren't taking into account either page weight (or more importantly session download volume) and or bandwidth speeds.

I work for Amethon the worlds first mobile specific analytics company.

Since we launched in October 2007 one of the key reports we implemented is tracking session download volumes, this along with abandonement rates for large files (because we use server side packet sniffing to build our analytics we can actually see when large files are abandoned halfway through downloading eg. a video file might be taking to long to download and your user abandons the download - meaning you should consider re-encoding into a lower bitrate) and not just tracking 'page views'.

Whats worse is the number of mobiel web developers who aren't tracking the top 3 screen resolutions visiting their site and therefor not creating the best UI experience for the most popular handsets visiting their specific content.

As we know....not all visitors are going to be looking at your content with iPhones.

Cheers,
Dean Collins
www.Amethon.com