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.]

Your website’s view of the tubes. Photo: Stig Nygaard /Flickr

High-resolution screens on mobile devices present web developers with an interesting conundrum — the screens are capable of displaying very high-res images, but on a mobile device bandwidth may be limited. What’s a web developer to do?

The answer, for now, is that there is no good answer; be it bandwidth or image quality you’re going to have to compromise somewhere.

That’s why mobile expert Peter-Paul Koch thinks browsers need to start broadcasting the connection speed of the device. “Browsers, especially mobile ones, should give information about the speed of the connection they’re on,” writes Koch in a recent blog post exploring just what that might look like and how web developers might use that information.

Here’s what Koch thinks developers need:

1. We need an HTTP header, so that a server-side script can use the information to decide whether to send the lowsource or high-res images. Let’s call it X-Connection-Speed for now.
2. A JavaScript property, say navigator.connectionSpeed, also makes sense.
3. Chris Coyier proposed a bandwidth media query with matching min-bandwidth and max-bandwidth. Sure, why not?

Check out Koch’s post for full details on other aspects like units, how connections speed might be calculated and what to do with edge cases — like when the connection speed changes between read and page load (Koch’s scenario imagines a user on a phone in a train with a good connection that deteriorates when the train enters a tunnel).

Koch’s post isn’t a proposal; rather its an exploration of the idea and he’s looking for feedback. There are already some great comments from other developers, including several that question whether web developers should be allowed to decide how much bandwidth a site uses.

While developers might like to be able to control bandwidth and deliver the images they’d like to be seen, that just might be a decision best left to users. For example, I may have a great 4G connection, but my data plan might be a mere gigabyte a month and I may not want to waste it on your high-res images. As David Ellenwood points out in the comments, a YouTube-style approach, choosing a sensible default and then offering up links to higher-res content (e.g., the 480, 720, 1080 options on most YouTube videos) might be the more user-friendly approach.

For now not only do browsers not broadcast connection speed, most don’t even have access to that information at the device level. But there are already proposals to add some sort of bandwidth info to HTTP (like the HTTP Client Hints proposal from Google’s Ilya Grigorik or Mozilla’s proposed Network Information API) and it seems likely that something along these lines will be added before too long. Be sure to read through Koch’s post for some more background and details. If you’ve got ideas, leave a comment on his site.

Opera Mobile 12.1. Image: Scott Gilbertson.

Opera Software has released a new version of Opera Mobile for Android phones. This update doesn’t offer many visible new features, but under the hood there are quite a few improvements that make Opera Mobile 12.1 well worth the upgrade.

You can grab the new Opera Mobile 12.1 for Android from the Google Play Store. Unlike some Android browsers, which only support the latest Android release, Opera Mobile has you covered all the way from Android 1.6 Donut to the latest and greatest, Android 4.1 Jelly Bean.

Like Opera 12.10 for the desktop the new Mobile 12.1 adds support for the SPDY protocol, WebSockets and a host of new HTML APIs. Opera Mobile’s support for the SPDY network standard, which promises to be even faster than the HTTP protocol, is especially welcome since it means speedier page loads on SPDY-enabled sites like Twitter and Gmail.

Opera Mobile 12.1 also introduces support for more “unprefixed” CSS rules, including transitions, transforms, gradients, animations and flexbox, all of which will now work without the -o- prefix. For now any code you have with an -o- prefix will still work as well, but make sure you’re including the unprefixed rule too since eventually Opera (and every other browser vendor) will drop support for the prefixed versions.

This is the first mobile release to introduce support for some -webkit- prefixes on poorly coded sites that don’t use unprefixed versions of stable CSS properties. Opera’s decision to support another browser’s CSS prefix has caused considerable outcry among web developers and members of the CSS Working Group, which created vendor prefixes. While the controversial -webkit- prefix support has been around in preview versions of both desktop and mobile builds, this the first official mobile release to support it.

For complete details on how Opera’s -webkit- prefix support works, as well as the details on everything that’s new in Opera Mobile 12.1 — like support for Drag and Drop, the Clipboard API and the Page Visibility API — be sure to read Opera’s blog post.

Planning to pay for all those devices? (testing responsive sites with Adobe Shadow). Photo: Adobe

One of the biggest roadblocks to building a website that works well on any device is that you need to test it on, well, every device. Collecting every new device that gains a foothold in the worldwide market is beyond the budget of most web developers, which means we use imperfect methods like emulators or test on a limited set of devices.

But there’s a better way — just head to your local Open Device Lab (ODL).

Open Device Labs are places anyone can come and test their websites on dozens of devices. The idea started in Europe, but there are now several Open Device Labs in the U.S. as well. You can check this list of Open Device Labs around the world to see if there’s anything nearby.

Nothing near you? That’s where the newly launched LabUp! wants to help. LabUp is helping to get even more ODLs up and running. The site aims to be a centralized place for listing open device labs and a resource for anyone looking to start up their own Open Device Lab.

Here’s how LabUp! describes itself:

LabUp! is here to help people around the world in establishing nonprofit Open Device Labs which helps others access a large number of mobile devices for testing, leading to an ultimate improvement of the mobile web and app experience both for developers and consumers.

For more info on how you can help, or how to set up your own local Open Device Lab, head on over to LabUp! and be sure to follow @LabUpOrg on Twitter.

Firefox for Android, burnin’ up the tubes. Image: Scott Gilbertson/Webmonkey

To test out the new Firefox for Android, just install it from the Google Play marketplace.

This release is not only significantly faster than previous versions, it features a ground-up redesign using Android’s native user interface widgets and controls.

The result is a web browser that’s a bit more Androidy and a bit less Firefoxy. But that’s just fine with us because the significant speed boost more than makes up for the fact that it looks a bit different than desktop Firefox.

In fact, not only was Firefox 14 faster than previous releases, it was faster than most of the rest of the browsers installed on our Galaxy Nexus running Android 4 Ice Cream Sandwich (though it’s worth noting that, unlike Chrome for Android, Firefox for Android will run on pre-ICS phones).

That might be somewhat surprising if you experimented with the first few releases of Firefox for Android, which were disappointingly slow. Those first few versions all used the standard XUL-based interface that powers Firefox on other platforms. But, while the XUL interface meant Firefox on Android looked like Firefox, it seriously lagged at basic tasks like scrolling, zooming and panning.

Toward the end of last year Mozilla decided to ditch the XUL-based interface and go native on Android. The company also stepped up its efforts to optimize performance (which has been a focus for some time in the desktop version of Firefox as well). The work has paid off in this release (and the recent betas), which starts up nearly instantly and remains snappy even with a number of tabs open. Particularly noticeable is the smooth scrolling when swiping down very long pages.

Speed isn’t the only appeal of course, much of what’s great about Firefox on the desktop is also present in the latest mobile version. In some cases there are minor differences, for example the Awesome Bar becomes the Awesome Screen on a phone, but functionality remains the same. As with previous releases, Firefox Sync will automatically bring all your browsing history, bookmarks, passwords and form data to your Android phone.

And yes, Firefox for Android supports Adobe’s Flash plugin.

One thing that’s quite a bit different in this release are the browser add-ons available for Firefox for Android. Ditching the XUL interface might have made Firefox faster, but it also means that any desktop add-ons that use XUL won’t work in the mobile version. At the moment that means there aren’t many add-ons for Mobile Firefox, but now that it’s out of beta we expect more developers will begin building for the platform.

The big question for most Webmonkey readers is whether or not Firefox trumps Google’s Chrome for Android. The answer is … it depends. Both are fast — pretty close to identical in my testing — and both have excellent support for the latest web standards. In the end sync becomes the killer feature. If you use Chrome on the desktop, stick with Chrome on Android. If you use Firefox on the desktop the good news is that Firefox for Android will no longer leave you wanting.

Firefox for Android isn’t sitting still, either. If you don’t mind living on the edge you can try the nightly builds, which are less stable, but will get planned features like the coming tablet UI, the new tabs pane, find in page, bookmarks/history import, reader mode and more before they arrive in the stable version.

Adobe Shadow makes it easy to test your site on multiple devices at the same time. Photo: Adobe

Today’s web shows up on a tremendous variety of screens — desktops, televisions, tablets, phones and lately “phablets” (whatever those are). Testing your site on even a fraction of the devices available can seem like a full time job. Tools like Adobe Shadow simplify the process somewhat, refreshing your local site across devices with the click of a button. But Shadow has limitations, for instance, it only works with WebKit browsers.

If you’ve got a wide array of devices to test with you’ll probably want a local network solution — that is, serve your site over your local network and connect all your test devices to that virtual host domain.

Unfortunately setting up a local network and connecting to it can be a pain, which is where the curiously-named Xip.io comes in. Xip.io is a wildcard DNS service that makes it drop-dead simple to set up a network and connect any device to your local test site.

The service is really just a custom DNS server you can easily tap into. So, for example, if your LAN IP address is 10.0.0.1, using Xip.io, mysite.10.0.0.1.xip.io resolves to 10.0.0.1. With the DNS taken care of you can access virtualhosts on your local development server from any devices on your local network, zero configuration required.

Xip.io is a free service from 37signals, whose Sam Stephenson says, “we were tired of jumping through hoops to test our apps on other devices and decided to solve the problem once and for all.” Xip.io might not work for everyone, but if you’ve ever struggled and failed to set up and test sites on a local network, Xip.io might be able to help.

Can you hear me now? Photo by Aramolara/Flickr.

Opera’s numbers were gathered in conjunction with mobile research firm On Device Research and are pulled from some 34,000 users in 22 different countries across four continents over the course of one year (Nov. 2010 to Nov. 2011).

There are two lessons for web developers in this report. First, globally, mobile is not the future of the web — it’s the now of the web. And second, hiding content on the mobile version of a website means a significant number of users will never see that content at all since they only access sites via a mobile device. Consider your hidden-from-mobile content non-existent content.

Naturally every website’s audience and needs are different. If your site is U.S.-centric then Opera’s report may have very little bearing on your users, but for those who’d like to expand to, or are already serving a global market, clearly making sure your site works well on mobile devices is key.

Delving into the Opera-centric portion of data offers some insights for developers as well, namely that building WebKit-only sites is not a good idea.

It’s one thing to know that building sites that only support the -webkit browser prefix is bad form, it’s another thing to realize it may be costing you money.

Not only are Opera Mobile and Mini the most widely used mobile browsers worldwide — which means not supporting them excludes the majority of mobile users from your site — according to Opera’s white paper, 55 percent of Opera users make purchases on their mobile devices. Only 43 percent of people without Opera installed do the same. In other words, websites that don’t support Opera on mobile may well be losing money.

Unfortunately, Opera is going forward with its plan to support -webkit, so possibly WebKit-only websites may work in Opera Mobile at some point in the future. But if you want to support Opera (and other browsers) today be sure to use all the various browser prefixes when writing your CSS. You can even take advantage of automated prefixing solutions to do all the hard work for you.

For more info on Opera’s data be sure to check out the actual white paper (.pdf) which also provides some more country-by-country data for those interested in what mobile trends look like in specific parts of the world.

Adobe Shadow makes it easy to test your site on multiple devices at the same time. Photo: Adobe

To try out Adobe Shadow, head on over to Adobe Labs and grab the desktop app and Chrome browser plugin, along with the Android and iOS offerings.

If you’ve never tried testing your site simultaneously on multiple devices, the fact that Shadow consist of four separate apps should give you some idea of how difficult it generally is. Thankfully, once you have all the pieces installed, Shadow makes the rest of the testing process as simple as hitting refresh. In fact, much of the time you don’t even need to do that — Shadow will automatically mirror whatever you’re doing on the desktop to the rest of your connected devices.

Though it’s still a beta release, Shadow may well be the most useful thing Adobe has ever built for web developers, particularly those that have embraced responsive design. It’s no secret that, while responsive design allows developers to easily target a wide range of screen sizes, it adds a considerable amount of work to the development process. But with Shadow mirroring your website across dozens of devices at the same time, testing becomes simple and easy. It’s a bit like synchronized swimming for web browsers. You can even debug and make changes directly in Chrome and then see the results on each device. To get an idea of how Shadow works, check out this overview video from Adobe:

There are two small problems with Shadow. The primary problem is that Shadow will only test your site in WebKit mobile browsers. We’d hate to see Shadow become yet another reason for developers to ignore non-WebKit browsers. So, while Shadow is great, it won’t give you the whole picture right now.

The good news is that Shadow is a beta release and a work in progress. I spoke with Bruce Bowman, Senior Product Manager of Shadow and, while he stopped short of committing to anything, Bowman made it clear that Adobe plans to keep expanding Shadow’s capabilities as the project progresses.

The other problem with Shadow isn’t actually a problem with Shadow directly, but its usefulness is nevertheless directly related to the number of iOS and Android devices you have on hand. Obviously those that will benefit most from Shadow are large web development shops with the budget to invest in dozens of mobile devices. Shadow is no less handy for individual developers with only one or two devices, though the results are of course limited.

Should Shadow prove popular, perhaps it will help spur the sort of device swap gatherings we’ve heard mobile expert Peter Paul Koch suggest — a group of web developers pool their resources, bring together a wide range of mobile devices and take turns testing websites. Shadow could make that process considerably easier and faster thanks to its live editing capabilities.

Mozilla announced today that it has partnered with mobile network operator Telefónica to deliver a complete mobile operating system built around standards-based web technologies. They plan to bring the platform to market later this year on a prototype device that they are developing in collaboration with Qualcomm.

The new operating system, which is called the Open Web Devices (OWD) platform, is based on Mozilla’s Boot2Gecko project. Mozilla launched B2G last year with the aim of building a Linux-based mobile computing environment with an application stack that runs entirely in Gecko, the HTML rendering engine that is used in the Firefox web browser.

Photo illustration by Aurich Lawson/Ars Technica

According to a statement from Mozilla, Telefónica was already evaluating the feasibility of creating its own web-centric mobile platform when the B2G project was first announced. Telefónica subsequently decided to bring its ideas to B2G and join Mozilla in a cooperative development effort.

Their initial target is to produce devices with smartphone-like capabilities that can be built inexpensively and sold at the price of a common feature phone. Telefónica believes that the unique advantages of a platform built around web technologies will potentially reduce development and production costs, enabling the company to make devices that are a good fit for regions where smartphones have historically been too expensive for widespread adoption.

“From our experience in Latin America we know that a huge part of the market is not being catered for by current smartphones,” said Telefónica Digital product development director Carlos Domingo in a statement. “With new open web devices we will be able to offer a smartphone experience at the right price point for these customers.”

As we recently reported in our hands-on look at B2G, Mozilla is introducing a number of new JavaScript APIs that expose device functionality to web content. These include APIs for measuring device battery level and communicating with a device’s cellular radio.

Mozilla has been working with the W3C to turn its new APIs into open standards with the hope that the technology will be embraced by other browser vendors. In today’s announcement, Mozilla revealed that it plans to take this effort one step further by turning the whole OWD platform into an open standard.

“Because of this initiative’s commitment to openness, this reference implementation will be submitted for standardization to W3C,” Mozilla told us in an e-mail. “The objective is that there are no proprietary APIs within the device architecture, making phones developed using it the only truly open devices on the market.”

The initial OWD prototype device will be built around a Qualcomm chipset, but the exact specifications have not yet been disclosed. In light of the focus on low cost, it’s likely that the specs will be modest. Mozilla contends that OWD is lighter than some other mobile platforms because its simple HTML-on-Linux architecture eliminates the need for a lot of the intermediate layers that would otherwise be necessary.

According to Mozilla, this lack of overhead will allow OWD to run efficiently on less-expensive hardware than its rivals. But HTML rendering engines are hardly lightweight — it is still unclear whether a user experience built entirely with HTML and JavaScript will be able to fully match the performance and responsiveness of native code on a mobile device.

It does seems clear, however, that the extensive use of HTML will help accelerate OWD development and vastly simplify the sort of customizations that mobile network operators typically make. Mozilla was able to get its B2G home screen interface up and running very quickly due to the strengths of HTML as an environment for creating interactive user experiences.

Another question that is left unanswered is which handset manufacturer will actually build the launch device for Telefónica. A number of rumors that have circulated over the past few days suggest that LG will be involved in building the first handset based on the B2G project. It’s possible that LG is involved, but that hasn’t been confirmed yet.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Just a few of the many screens on the web

Last time we sent you over to Brad Frost’s blog it was for a slideshow about building a future-friendly web. Now Frost is back with some more tips for web developers in a post entitled Support vs Optimization, which tackles the thorny subject of what to do about the wide range of mobile browsers on the web.

As Frost points out the mobile world is more than just the WebKit-based iOS and Android browsers that often grab all the headlines. In fact the most widely used mobile browser is not even a WebKit browser (it’s Opera) and there are dozens of other mobile browsers out there as well. And, as the tablet market begins to expand beyond the iPad, there will likely be dozens more coming in the near future.

Faced with the diversity of the mobile browser market developers can either stick their heads in the sand and develop exclusively for WebKit browsers, or, as Frost suggests, we can be more considerate to other browsers. It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers? (For a more far-future look, check out Scott Jenson’s The Coming Zombie Apocalypse).

The solution, according to Frost, is to recognize the difference between supporting a browser and optimizing specifically for it.

The typical argument against supporting older BlackBerry browsers or Nokia’s WebKit fork, for example, is that these browsers don’t support nearly the number of features that iOS and Android browser’s offer. While that’s true, as with most things on the web, it doesn’t have to be an either/or choice. It can actually be both. That’s what Frost means be the difference between support and optimization:

You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.

For some practical advice on how you can take a more supportive approach to the wide range of mobile browsers on the market, head over to Frost’s site and read through the post. Be sure to check out the links to the various mobile emulators and brush up on the ideas behind progressive enhancement.

It’s a big web out there, with dozens of browsers and an ever-increasing number of devices connecting to it. If you want your site to be part of the future it’s going to have to work everywhere — perhaps not perfectly optimized, but at least working.

[Photo by Jeremy Keith/Flickr/CC]