All posts tagged ‘Mobile’

Mobile Browsers Help Users Avoid Bloated Webpages

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

Websites are getting fatter, dramatically fatter, with the average page size of sites tracked by the HTTPArchive now nearly 1.3 MB. If the current rate of page size increase continues, that number will reach 2MB sometime early next year.

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

File Under: Mobile, Web Basics

Bandwidth and the Mobile Web Browser

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.

File Under: Browsers, Mobile

Opera Mobile for Android Gets ‘SPDY’

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.

File Under: Mobile

Create an ‘Open Device Lab’ With Help From LabUp

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.

File Under: Browsers, Mobile

Mozilla Delivers Faster Firefox for Android

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

Mozilla has released a major upgrade to Firefox for Android, the company’s open source web browser for Android phones.

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.