urls

Caching URLs with Query Strings

Posted by Mike Brittain on June 11, 2009
WWW / 1 Comment

A common method for breaking a cached object, or for specifying a version of an object, is to put a version number into a query string or some other part of the file name.  I’ve been wary of using query strings in URLs of static assets that I cache, either in browser cache or on a CDN.  I hadn’t seen much hard evidence, but generally felt query strings provide another area of uncertainty in a network path that you already have little control over.

Today, I just found Google’s recommendation for leveraging proxy caches, which states, “to enable proxy caching for these resources, remove query strings from references to static resources, and instead encode the parameters into the file names themselves.”

What is a good alternative?  One method I like is to use a version number that is part of the URL path:

  /12345/css/site.css

The “12345” is prepended in your page templates using a variable.  The value can be taken from anywhere you want… it could be part of a timestamp, a revision number in your source control, or maybe even manually changed in a constants file anytime your are updating files in your “css” directory.  If you’re using Apache, this portion of the path can be easily stripped off the request using mod_rewrite.

  RewriteEngine On
  RewriteRule ^/\d{5,}(/.+)$ $1

With this method, you’re not literally using directories with version number in them.  Rather, you just use your regular old /htdocs/css directory. The same can be applied to JavaScript, images, or other directories with static assets.

What you gain is the ability to break your cached versions of files when necessary, but to also set long-term cache times on these assets (while they’re not changing) and expect cache servers between you and your users to properly store these objects.

More to come…

I’ll be speaking at Velocity in two weeks about how to optimize caching with your CDN.  I have a lot of content that I’d like to present, but only 20 minutes to do it.  Over the coming weeks I’ll be writing a number of posts covering topics that don’t make it into the presentation.

Tags: , , ,

Selecting a Mobile Web Site Domain: Choose Wisely

Posted by Mike Brittain on January 08, 2009
Mobile / Comments Off on Selecting a Mobile Web Site Domain: Choose Wisely

I recently did some research on the web addresses (or, host names) that companies use for their mobile web sites.  Turns out, there are quite a few varieties.  That isn’t helping anyone who is trying to find on of these sites on their phone, which can be a painful experience as typing is more difficult and network latency (for mobile) is high.

This all stems from a discussion I was having recently about one company in particular who uses the subdomain “pda” for their mobile web site.  “pda” seems to be somewhat of an outdated name for mobile devices.  I’m not even sure that the “pda” subdomain was ever in vogue.

What I came to understand is that the term “pda” was used heavily by the company, maybe stemming from internal use.  I’ve seen this sort of thing happen before — corporate vernacular turns into marketing speak.  Often, the only people who understand the lingo are inside the company.  On their own web site, this company referred to their mobile site as their “mini browser”.  For me, a “browser” is a piece of software and not a web site.

I initially assumed that “m.example.com” and “example.mobi” were becoming the heavy favorites in this area.  When I started digging around, I also found some other URLs that turned up frequently: “mobile.example.com”, “example.com/mobile”, “www.example.com/m”, “iphone.example.com”.  The last is obviously device-specific, but worth noting.

The term “wap” is also used by some companies in their hostnames (“wap.example.com”).  It stands for “wireless application protocol”.  This is not very consumer-friendly acronym, and should be avoided.

I also looked at a list of “top mobile domains” (I forget where I found this) and the sites that came up were:

  • m.google.com  (google.com/m and google.com/mobile are also used for some of their mobile services)
  • m.twitter.com
  • m.cnn.com
  • m.flickr.com
  • m.yahoo.com
  • m.myspace.com
  • wap.aol.com/moviefone/  (I don’t know how anyone would guess this one)
  • restaurantrow.com/avantgo  (“avantgo” was one of the original mobile products back in 1998-ish)
  • mobile.answers.com
  • foreca.mobi
  • weather.mobi  (also hails under “xhtml.weather.com”, which is another terrible acronym to use in a domain name)

Notice some of the trends here?

The mobile industry is still quite young.  Usage of mobile sites is on the rise.  To be found, companies need to make sure they select the right URLs for their mobile sites.  Help out your customers — don’t buck the trend.  Additionally, you should be casting your net wide.  It’s not technically difficult to pick up three of four of these URLs and forward them to your primary URL (and I don’t care what your IT department says, it’s not).

My guess is that within two years, you’ll see 90% of mobile sites operating under “m.example.com” or “mobile.example.com” (“m” being short, it’s easier to type on a little bitty keyboard).  These will stick with consumers the same way that they figured out what URLs were back in the ’90s.  Remember the first time you saw “http://” somewhere and thought, what the hell does that mean?

With any luck, I’ll be able to find your mobile web site in one guess of the address.

Tags: , , , ,