All posts tagged ‘performance’

File Under: Web Basics

Put Your Site on a Diet With Google’s Image-Shrinking ‘WebP’ Format

WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google

Webpages are constantly getting bigger.

Massive JavaScript libraries and endless sharing buttons aren’t helping, but the main culprit behind most of the bloat is the good old image. According to the HTTPArchive, images account for roughly 60 percent of total page size. That means the single biggest thing most sites can do to slim down is to shrink their images.

One way to do that is with alternate image formats like Google’s WebP, which can yield images between 25 and 34 percent smaller than more popular image formats. Despite the astounding space-saving potential of WebP it, like JPEG 2000 and other efforts before it, has not completely caught on with browsers.

So far only Google Chrome and Opera support WebP (both also automatically convert all images to WebP for their respective proxy browsing mobile services). Mozilla objected to WebP when it was first launched, but all of the issues raised in that post have been addressed as WebP has evolved. Firefox still does not support WebP. Nor does Internet Explorer.

However, as Opera’s Bruce Lawson recently pointed out, using some cutting-edge CSS wizardry you can serve WebP images to Chrome and Opera, while still offering JPGs to the rest. Here’s what the code would look like:

.mybackgroundimage {
    background-image: url("image.jpg");
    background-image: image("image.webp" format('webp'), "image.jpg");
}

This code uses the new Image Fallbacks syntax, which is part of the CSS Image Values and Replaced Content Module Level 4. The format qualifier is borrowed from @font-face and ensures that browsers won’t download the WebP image if they don’t support it.

Of course this only helps with CSS background images, which probably aren’t the majority of the images most sites serve up. For content images there’s currently no easy way to do the same thing, though there might be in the future if browsers begin to support the proposed <picture> element. Because <picture>‘s syntax is roughly analogous, you would be able to do something like this:

<picture>
    <source src=image.webp type=image/webp >
    <source src=image.png type=image/png >
    <img src=image.png alt="alt text "> <!-- fallback content -->
</picture>

That would cover almost all the bases: browsers that support WebP and <picture>, browsers that support <picture> but not WebP and browsers that support neither. Unfortunately it’s going to be a while before this pseudocode becomes real.

WebP has other problems worth considering before you dive in. For example, when users save an image they may have trouble getting a WebP image to open in their favorite desktop app.

Still, while WebP may have a little ways to go, the potential to significantly reduce page size appears to be winning converts. If you’d like to learn more about WebP and how you can use it, check out the video below from Google’s Making the Web Fast series.

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: Web Basics

A Guide to Understanding Page-Speed Tests

Photo: tobias.munich/Flickr

Anyone who’s ever tried to optimize a website has faced the very basic question — how long does your site take to load?

The answer seems like it would be easy to discover: Load your site in a page speed crawler like WebPagetest and soon you’ll have your numbers. But that’s just it; you won’t have a number, you have numbers and figuring out which numbers to listen to is trickier than you might think.

Strangeloop’s Joshua Bixby recently tackled the performance metric question in a blog post titled a Non-Geeky Guide to Understanding Performance Measurement Terms. The whole article is well worth reading, but perhaps the best advice is to make a video of the page load. “If you want to get a ground-zero look at your site’s performance,” writes Bixby, “capturing videos and filmstrip views of your pages’ load times are one of the best ways to go.”

The filmstrip view Bixby refers to is part of the WebPagetest results and shows what the visitor sees in a progressive series of page captures. To create a filmstrip or video test of your website, head over to WebPagetest and select the “visual comparison” tab.

Some common performance mistakes Bixby cautions against include using “response time” and “load time” interchangeably and “not realizing that ‘response time’ can mean any number of completely different things.”

To help those unfamiliar with the nuances of loading metrics, Bixby then breaks down and defines all the terms, including what exactly is meant by “start render” or “time to first byte,” as well as some caveats to bear in mind when going over the numbers for your website.

While Bixby’s post can be extremely helpful, especially to those who are just starting out in the often confusing world of website optimization, bear in mind that testing sites like WebPagetest are no substitute for real-world tests. “As a matter of due course, you always need to gather large batches of data and rely on median numbers,” writes Bixby, “but you also need to periodically get under the hood and take a real-world look at how your pages behave for real users.”

File Under: Software & Tools

Chrome is Fast, But Not That Fast

Just how fast is Google’s Chrome browser? JavaScript performance-lover (and Mozilla employee) John Resig ran some tests that show Chrome may be fast, but other browsers aren’t that far behind.

When Google released Chrome, it included benchmarks that show its browser zipping away from the competition at light speed. There’s no doubt Chrome is fast and we think it’s already changed the web. It seems, like with most statistics, it all depends whose benchmarks you believe.

Resig works for the company that creates the rival Firefox browser, so you might take his results with a grain of salt. But unlike Google’s charts, Resig’s don’t show one browser incredibly faster than others (except for Internet Explorer, the obvious slow-poke).

SunSpider test of browsers

According to Resig, Chrome really shines in the recursion-heavy benchmarks Google provided. Even the above tests are JavaScript-only, and don’t include DOM manipulations, the basis for a lot of new web interfaces. To test this, Resig used Dromaeo, a Mozilla-created project. Again, put the bias detector on.

Dromaeo test of browsers

The results show Chrome is still fast, though bested by its WebKit cousin, Safari. Firefox is close behind, especially when TraceMonkey (no relation!), its JavaScript supercharger coming in 3.1 is included. Resig points out that TraceMonkey has been in development for two months, while Google’s V8 engine apparently represents two years of work.

Yes, Chrome is fast, but it may not be that fast. For now, it’s probably best to assume everyone’s stats are a little skewed in their own direction. Don’t be surprised if Microsoft comes out with their own benchmarks that show Internet Explorer is faster than all other browsers. Okay, be a little surprised.

Possibly the best thing that could come from the release of Chrome is that all browsers–yes, including the behemoth from Redmond–pay attention to the performance needed to run today’s web apps.

See also:

File Under: Software & Tools

Firebug Flies Out of Beta

Firebug logoIf you’ve been waiting for an official release to install the latest Firebug, wait no more. Version 1.2 of the popular web developer extension for Firefox is no longer in beta. You can download Firebug at the Firefox add-ons site.

John Resig, one of the new Firebug team members, has a great rundown on what’s new. Resig is always on the lookout for performance issues and he brings up an important one with JavaScript debugging. Whenever script debugging is on anywhere, every page runs JavaScript about 25% slower, even those without Firebug enabled. Now you can right-click (or ctrl-click) the Firebug icon and choose “suspend Firebug” when you’re done using the script console. Expect the Firebug team to look into this performance issue.

Those who haven’t been enjoying the beta will need to completely remove the previous version before installing Firebug 1.2. Otherwise, the update is just a click (maybe three) away. If for some reason you’ve avoided Firefox 3, the new Firebug even works in Firefox 2, but you’re still missing out on FF3.

Want to get down to business with Firebug and learn how to use Firebug extensions, too? We have an excellent Firebug tutorial.

See also: