Stop feeding your website donuts. Image: D. Sharon Pruitt/Flickr.

That’s bad for pretty much everyone, but doubly so for mobile users with constrained bandwidth.

Fortunately for mobile users, the network increasingly seems to see large page sizes as damage to route around.

Services like Instapaper, Pocket or Safari’s Reader have long offered an easy way to strip out extraneous content. Now mobile web browsers are increasingly taking it upon themselves to speed up the bloated web.

The recently unveiled WebKit-based Opera Mobile borrows Opera Mini’s proxy-based Turbo Mode, or “Off Road” mode as it’s known now. Once only deemed necessary for feature phones (Opera Mini’s primary market) proxy-based browsing will soon be available in all Opera browsers.

Google’s Chrome for Android browser is getting ready to follow suit.

The beta channel release of Chrome for Android recently introduced an experimental data compression feature which Google says will “yield substantial bandwidth savings.” Chrome’s compression is nowhere near the level of Opera’s, but it does roughly the same thing — puts a proxy server between the user and the bloated site in question and then applies various speed improvements like using the SPDY protocol and compressing images with WebP.

To turn on the compression head to chrome:flags and look for the “enable experimental data compression” option.

Here’s Google’s description of the various optimizations:

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

In other words, Google and Opera are doing what web developers ought to be doing but aren’t. Just like developers should have been making reader-friendly pages, but weren’t, so “reader” modes were born.

It works too. In the video embedded below Google’s Pete Le Page shows how Chrome’s new proxy options take a page from The Verge and reduce it from a husky 1.9MB to a still fat, but somewhat better 1.2MB.

Want to make sure the internet doesn’t see your site as damage it needs to route around? Check out developer Brad Frost’s article Prioritizing Performance in Responsive Design, which has a ton of great advice and links, including what I think is the most important thing developers can do: Treat Performance As Design. In other words, if your site isn’t svelte and fast, it’s not well designed no matter how pretty it might look.

[Note: It is not ironic to post about web page bloat on a page that is, arguably, pretty bloated.]

Tracking Webmonkey. Image: Screenshot/Webmonkey.

Developer Marko Dugonjić takes responsive design’s emphasis on you to new levels of interactivity with his experiment in typesetting by face detection.

Using a very cool JavaScript headtracking library — which taps WebRTC and getUserMedia to access your webcam — Dugonjić’s app calculates how close you are to the screen and adjusts the font size to make text more readable.

To see it in action, head on over to the demo page and grant it permission to use your webcam. For the most useful example, check out the onload-based implementation, but for a better sense of how it works be sure to try the “Realtime” version.

It may not be the most practical experiment and how well it works depends on plenty of factors well beyond the control of the site (how good your eyes are, whether or not you’re wearing your glasses and so on), but it’s not hard to imagine how this could be very useful in some situations — for example, bumping up font-size when your site is displayed on a television.

When you’re done playing with the resizing demo be sure to check out Dugonjić’s more practical and more immediately useful Typetester.

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the BostonGlobe.com and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

The basic elements of responsive design — fluid grids, flexible media and CSS media queries — are key to building successful websites that work across platforms and devices, but these three components are not the end of the responsive design story. In fact, as developer Brad Frost argues in the talk embedded above, there is, or should be, much more to it than that.

While many would call the broader approach “adaptive” design, Frost wants the phrase “responsive web design” to go the way of Corn Flakes, as he puts it. That is, to become a more general term that can “encompass all the things that go into creating a great multi-device web experience.” That means things that go beyond fluid grids, flexible media and media queries — things like performance, device support, device optimization and future-friendly designs.

In Frost’s analogy responsive design is the tip of the adaptive design iceberg, where all the good stuff is under the water. “Below the waterline, that’s where the true opportunity is,” says Frost, “that is where we actually have the potential to basically reshape what the web is, what it can do, where it can go and who it can reach. And that is powerful.”

Just what’s below the waterline and how do you roll these broader ideas into an actual website? Well, be sure to watch the video — Frost walks through an example of a mobile-first responsive design, which you can also read about on his site. If you prefer a tutorial sans video, Frost’s write-up from last year is available on HTML5Rocks.

Unlike progressive JPEGs, you just never know what a baseline image is going to be until it loads. Image: rickastley.co.uk

Everything old eventually becomes new again and lately that’s meant a revival of interest in something most web developers probably abandoned long ago — progressive JPEG images.

Progressive JPEGs offer some advantages over their more common “baseline” counterparts, including potentially smaller file sizes and faster perceived load times. But there are trade offs to bear in mind before you start converting your back catalog of images.

If you happened to have missed the pixelated image loads of the circa 1999 web, here’s a brief refresher: There are two primary types of JPEG images, baseline and progressive. These days the vast majority of photos you encounter are baseline JPEGs, which means they start loading with the fully rendered top of the image and then continue to draw in the rest of the image as the data is received.

Progressive JPGs on the other hand load the full photo right off the bat, but with only some of the pixel data. That means the image briefly looks pixelated and then appears to sharpen focus as the rest of the data loads. This was the generally recommended way to optimize images back in the days when 56K dial up was considered smoking fast.

Lately, with mobile devices bringing bandwidth limitations back to the web, there’s been something of a resurgence of interest in progressive JPEGs. The Web Performance Advent Calendar even ran a piece entitled “Progressive JPEGs: a new best practice.” Here’s developer Ann Robson’s take on why you should use progressive JPEGs instead of baseline:

Progressive JPEGs are better because they are faster. Appearing faster is being faster, and perceived speed is more important that actual speed. Even if we are being greedy about what we are trying to deliver, progressive JPEGs give us as much as possible as soon as possible.

If you’re building responsive websites, progressive JPEGs are also appealing because you can avoid the content reflow that happens when baseline images are loaded after text content. With progressive JPEGs, because some data is loaded right off the bat, text doesn’t jump around (you can avoid this for non-responsive images by specifying the image dimensions).

Be sure to read Robson’s full article for some important caveats regarding progressive JPEGs, including the fact that browser support is less than ideal. All browsers will render progressive JPEGs just fine, but many of them — Safari, Mobile Safari, Opera and IE 8 — render progressive images just like baseline JPEGs, meaning there is no speed difference.

Another strike against progressive JPEGs is that they must be rendered multiple times as more data arrives. So while they may be marginally faster and possibly make users feel like the page has loaded faster, they hit the CPU pretty hard. That makes them potentially slower than baseline JPEGs in one of the use cases they’re supposed to be ideal for — underpowered mobile devices.

But perhaps the most questionable aspect of progressive JPEGs is whether or not users actually perceive a fully loaded, but blurry image that eventually comes into focus as faster than an image that takes longer, but renders all at once. Unfortunately I haven’t been able to find any actual usability studies addressing that question. I suspect that how you feel about progressive JPEGs is probably, among other things, a good indicator of how long you’ve been using the web, which is to say that if you’re all-too-familiar with progressive JPEGs from watching them slowly sharpen into focus over painfully slow dialup it’s hard to see them as anything but an annoying anachronism.

So, should you switch to progressive JPEGs? As with most things in web design there is no right answer. First you should look at your site’s stats, see which browser and devices your visitors are using and whether or not those browsers even render progressive JPEGs progressively. Assuming they do and you want to test progressive JPEGs, check out this old, but still very relevant, post from Yahoo YSlow developer Stoyan Stefanov, who has some data on when, where and how to use progressive JPEGs.

So many screens, so many images (testing responsive sites with Adobe Shadow). Photo: Adobe

The average webpage is now 1.2 megabytes and around 60 percent of that rather large payload comes from images. That’s a lot of data, whether you’re handling images responsively or just trying to speed up a desktop site.

You might think, if images are the bulk of what your browser is downloading, that browsers would be working hard to speed up the image downloads, perhaps trying alternate, space-saving image formats, but you’d be wrong.

You might also think that, as Google’s Ilya Grigorik writes, “innovating on better image formats would be a top agenda item” for the web. But again you’d be wrong. The web is still using the same image formats it’s been using virtually since the first images appeared online.

Grigorik thinks it’s high time that changed and we agree.

In a recent post looking at what it would take to deploy new image formats on the web, he writes, “if we really want to make an impact on web performance, then image formats is the place to do it… there is absolutely no reason why we shouldn’t have dozens of specialized formats, each tailored for a specific case and type of image.”

Of course no web developer wants to deal with dozens of specialized image formats. Nor should they need to — that’s a job for servers. “In a world with dozens of image formats,” continues Grigorik, “the human solution does not scale — read, markup does not scale… whereas computers are fantastic at doing exactly the kind of optimization work required to solve the problem.”

Grigorik isn’t alone in calling for new image formats, nor is he the first to suggest handing these tasks off to the server. Developer and responsive images proponent Matt Wilcox has argued for a similar solution, as have others.

The basic premise of these arguments is that deciding which image to serve up to which device and browser should be a server-side problem. And in fact there’s already a way to solve this problem with HTTP headers, namely the Accepts header, which tells the server which image formats the browser supports. Based on that information the server could then “re-encode, recompress, resize, strip unnecessary metadata and deliver the optimal format.”

The problem is that web browsers (with the exception of Opera) don’t actually send useful information in the Accepts header.

Thus, the first step in creating a server-side solution for smaller images is to get other browsers to send useful Accepts headers.

The Accepts header isn’t a magic bullet by any means, but it’s a problem that’s not hard to solve provided browser makers prioritize it. But to really get server side image solutions working the web would also need new server tools (fortunately, several already exist). There are other stumbling blocks as well. Grigorik addresses half a dozen potential problems and objections that you can read through in his post.

Even if browser makers come around to the idea and do start improving Accepts headers, bringing better image formats to the web is going to be an uphill battle. But Grigorik is determined to chase the idea. “Some uphill battles are worth fighting,” he writes in a comment, “I think this a good one. Wish me luck.”

Webmonkey in “Ish” (not even remotely responsive-ish). Image: Screenshot/Webmonkey

Frost’s Ish is different in that it doesn’t showcase specific devices; instead the size options are small-ish, medium-ish, large-ish. Even better, clicking S, M or L will not always get you the same size viewport. Click small once and you might see your design at 320px, but click it again and it might change to 216px.

The point is to not get hung up on how something looks on the latest iPad or the new Nexus, but to make sure your breakpoints are suited to your content and that your design looks good no matter what screen it’s on. Here’s Frost’s reason for building Ish:

The real reason for this tool is to educate and to facilitate a mental shift. Many clients, designers and developers get hung up on specific device widths, which is why this tool doesn’t include any such language, device chrome or anything like that. Ish helps keep everyone focused on making a design that looks and functions great at any resolution.

Using Ish is simple; just head to the demo page and click the URL button in the upper left corner. Plug in your site’s address and once it loads you can start playing with the size button in the upper right corner to test how your site responds. Be sure to try the “disco” option, which will make the viewport dance around between sizes (and if you must, you can plugin a specific screen width).

If you’d like to grab the code behind Ish for yourself, head on over to GitHub.

The Responsive Images Community Group — a group of developers helping the W3C create a web standard for handling images across devices — has a new demo page showing off how the proposed HTML <picture> element will work.

If you’d like to see the still-very-draft <picture> proposal in action, grab a copy of the special Chromium build (OS X and Linux only) and head on over to the new Responsive Images Demo Hub.

There are five demos, showing off a variety of <picture> features. The first is the obvious use case — serving smaller images to small screens and larger images to large screens. There are more sophisticated use cases as well, like the so-called art direction use case where the crop (or even the entire image) changes according to screen size.

For example, imagine you have a large image of someone giving a speech. You served that image to any screen larger than 800px. But for smaller screens you might not want to just shrink that image down since the speaker would be too small to recognize. Instead the <picture> element can be used to serve up a separate, more tightly cropped image to smaller screens.

Other use cases include serving up a monochrome image for print and serving different images based on device orientation.

If you’d like to create your own demo, head on over to the Responsive Images Community Group’s Github page and fork the demo code.