One of the larger issues when trying to create a truly responsive site is the content. Or rather, “what to send to whom…” (I am not trying to coin the next Ajax, but I am lazy, so I’m going to refer to this as WTSTW (what stew?) from here on…)
 

The reason WTSTW is such a pain is simple: connection speed.  You can only fit so much turkey through the tubes at one time.  If someone is on a crappy connection (be it a mobile network, dial-up (yes, people DO still use that), satellite, DSL, cable, slow proxy server, doesn’t matter), 500kb worth of whatever is going to take longer than on a good connection.  Basic, right?  Good.

Phone Home, IE (sorry, Chrome, you just didn’t rhyme right…)

One of the first swings people took at improving speed across slow connections was to reduce HTTP Requests (the number of times a user’s browser asks a web server for something).  We now combine our CSS files into a single CSS file.  We do the same for our JS.  Then we crunch those files into un-(humanly)-readable code to squeeze every last unnecessary byte we can from them.  And we scrunch all our design graphics into a single image file.  Or we use CSS magic to create images out of thin air!

Where in the World is…

Next, we took advantage of several server techniques.  We now serve our site assets via a CDN so users in Mumbai didn’t have to wait for a roundtrip to Palo Alto to get an icon.  And we set Expire Headers and Last Modified dates so browsers don’t even have to ask for assets if they already have a current version.

And all of this is really good stuff, all proving to be really worthwhile!

My Phone is DYING!  But Nice Background Image…

Next, we started looking at the images we were serving people.  A JPG that is 400×400, still pretty small by desktop standards, is pretty big on a mobile phone, and can really clog the tubes on a slow connection!  So people started looking at responsive images, and there are some really clever ideas out there, from trying to create new elements to handle this, to simply using JavaScript to fetch what is needed, if anything at all.

Again, moving the right direction, though I’m sure we aren’t there on this one just yet.

Why is My Monitor Sideways?

Then came layout: what happens when a page designed for a 1280×1024 screen hits a 320×480 screen?  Or when that typical horizontally-oriented desktop layout hits a vertically-oriented mobile phone?  Well, @media queries soon became the darling of the ball, getting plenty of use, and, like any good drug, abuse.

You Can’t Do That Here…

Somewhere amongst all the above happenings came Progressive Enhancement, the immaculate offspring of Graceful Degradation, that says “start out doing dead-simple stuff, and if the user’s device can handle cooler stuff, add it”.  So, we started writing basic CSS and JS, then building on that in such a way that devices that could understand the new stuff would get it and use it, but the simpler devices would just run right past that stuff and still look okay, and still work okay, no-harm, no-foul.

Which is f-ing fantastic, exactly the way we should be doing things!  Right?

So, WTSTW?

But the real trick comes with content (and I’m using “content” to represent anything that appears in any page that ends in something like “.html” or “.php” or the like).  Should people on slower connections be forced to download all of the stuff that someone on a faster connection has to download?

This is the question that has been dancing around my head lately, in my spare time, like when I’m sitting on the bus or not paying attention to the movie I’m watching…

Well, it seems to me that something like Progressive Enhancement for content is needed…

The basic concept that I’d like to discuss is to make an initial page that is lightweight, indexable by search engines and readable by screen readers and devices with poor connection speeds, and can be enhanced into a better experience based on the device’s connection speed, screen size, and capabilities.

This is really the core of what has been talked about some time now as Mobile (or Content) First.  But how do you go about this, exactly?  I mean, sending a basic content file to someone on a Nokia phone makes a lot of sense, but to someone on a 24″ LCD with a T3 connection?  That seems like underkill to me, and besides, we do still want to make money and stuff, right?

Though still through a good bit of haze, I can picture something like a JSON “config file” of component URLs and horizontal and vertical DOM builds.  Once the proper components arrive, build both the horizontal and vertical layouts as DOM fragments, store both in memory so they could easily be switched on orientation change, and innerHTML the current orientation’s layout to the existing DOM.

Much the same way general assumptions are made using @media queries, assumptions could be made to create “standard blocks” of pre-built HTML that could be combined, minified and fetched as a single HTTP Request.  These standard blocks might also include the CSS and JS necessary for them on arrival, especially now that we have scoped CSS on the horizon…

The essential criteria to me would be:

1. The main content must initially be in-page, so it is indexable by search engines, readable by screen readers, and viewable on primitive devices/connections
2. As few files as possible are fetched, in a performant manner, so we are not killing the experience we are trying to save
3. Maintenance should be minimal, so we aren’t spending 4 times the hours building and caring for our sites

This is Where You Come In…

As I’ve alluded to, this is far from a fully-developed thought, just ideas that have been bouncing around in my cranium, and I wanted to get a feel for what the smart people of the world thought…

Does this make sense?  What limitations / pitfalls would you see with this approach?  What improvements / alterations / adjustments would you make?

Thanks,
Atg

Top⇪