So I tweaked the test ever so slightly to print out timing info in the document.title and after the page is done.

The test is essentially how does a slow print stylesheet affect the rendering of the page on the screen.

<link rel="stylesheet" href="screen.css" media="screen">
<link rel="stylesheet" href="print.css"  media="print">

In the experiment I have screen.css delayed with 5 seconds and print.css delayed 10 seconds.

Results 5 years ago

Browsers blocked rendering waiting for print.css. Some took 10 seconds (downloading print.css and screen.css in parallel), some took 15. Why, oh why? It's a print CSS, you don't need this sh...eet.

Results today

Good guy Opera, doesn't even wait for screen.css. After some timeout, O renders unstyled page and restyles after screen.css arrives. Yes, brave O takes rendering risks this way, all others wait for the screeen.css before styling anything. Still, onload fires in ~10s, so this is bad. All your onload JS code is blocked on a useless print.css

FF blocks rendering on the print.css. Boo! Nothing renders for 10 seconds. And it fires onload after ~10s. Boo-boo! At least it loads both stylesheets in parallel. Galaxy (Android) waits for print.css too. How often do you print from a mobile device? Same in IE8 and IE9. Even more retarded in IE is DOMContentLoaded event also waiting for 10 seconds. speech=less.

Safari, Chrome, Mobile Safari - render after 5 seconds, meaning only after screen.css. There is hope for the humanity. However the onload fires in 15 seconds. So the two CSS files are downloaded sequentially. Kinda makes sense, print.css is low priority and should give way to everything else. Still could start earlier if there are no other downloads competing for precious resources.

So on the wall of shame - IE worst, FF yuck, Webkit bad, O least bad.

Recommendation

Ditch media="print" if you have one! (Hey why isn't this a yslow/pagespeed rule?). Ditch it because in the best case scenario it will only block onload. In the worst case it will block initial paint, onload and DOMContentLoaded. Sitting in front of a white page with no feedback is the worst possible user experience.

Put all (should be minimal anyway) print rules inline in your normal screen stylesheet.

@media print {
  body {font: fit-to-print}
  .big-ads, .sidebar, .menu {display: none}
}

What's a webmaster to do? All I need is a simple PLAY button next to each link

While I was aware of SoundManager, I accidentally stumbled across sound.js yesterday and thought I should give it a chance. Tiny (3K), it should give me an easy way to do x-browser playing with the help of some SWF for IE, I assume. Dropped the JS from their CDN (nice), but then what? "Online documentation" points to API docs which I don't feel like reading. Demos don't give you the code. Next.

Sound manager has a nice "basic template". Awesome. Replace the sound.js js with SoundManager's. Load in FF. It's looking for an swf. In FF. Why? Because FF doesn't play mp3. Well, I'd rather convert the MP3 than have the user load SWF. But anyway, I drop the swf. For whatever reason (like you need a reason!) I've disabled flash in FF and forgot about it. So no sound in FF. And maybe I'm not the one. Requiring SWF in FF feels unnecessary, although I'm sure Sound Manager probably has way around it. I'm sure. I've met the author, he's brilliant. But... I still need to write some JS to initialize the playing. And if I'm to write code, might as well go solo.

Here's what I came up with, hope it helps.

Disclaimer: I haven't tested in IE, and I mean at all. Should probably work in newer IEs

Demo

http://anacondalimousine.com

Codez, how they work

Everything in an immediate function. Unobtrusive. Bail if (IE) browser doesn't know about Audio.

(function () {
  if (!Audio) return;

  // ...

}());

Codes for play and stop:

var playsym = "▶", stopsym = "■";

Some browsers play mp3, some OGG, so let's just change the extension and have both .mp3 and .ogg on the server

var extension = new Audio().canPlayType('audio/mpeg') === '' ? 'ogg' : 'mp3';

Loop though all links on the page, find the ones that point to .mp3

var dl = document.links;
for (var i = 0; i < dl.length; i++) {
  if (dl[i].href.split('.').slice(-1)[0] !== "mp3") {
    continue;
  }
  var p = document.createElement('button');
  p.innerHTML = playsym;
  p.onclick = play;
  dl[i].parentNode.insertBefore(p, dl[i]);
}

Forgot to mention, my markup is as simple as it gets:

  <p><a href="virus.mp3">Virus</a></p>
  <p><a href="yesterday.mp3">Yesterday</a></p>
  <p><a href="parting.mp3">Parting</a></p>
  <p><a href="faultline.mp3">Faultline</a></p>

So all I'm doing is insert a PLAY button right before the link. Onclick it should play.

The play() function initializes Audio with the appropriate extension, based on what the browser supports:

  function play(e) {
    var button = e ? e.target : window.event.srcElement;
    button.innerHTML = stopsym;
    var a = new Audio(button.nextSibling.href.replace('mp3', extension));
    a.play();

And if you click the same button as the music plays, you stop it and reset the button click handler:

    button.onclick = function() {
      a.pause();
      button.innerHTML = playsym;
      button.onclick = play;
    };
  }

That's it

So simple and tiny, it's all inline, no extra requests, not a SWF in sight. Support for 72.3% of all browsers. The other 30% can still download the file and play it with a separate program.

SoundManager and, I assume, sound.js have more features, events and other shiny, but for my simple purpose I'm so happy with the result I'll even blog about it

For full source - view source at http://anacondalimousine.com

Moarr info:

• Article on Opera.com
• MDN

p.s. about the mp3 to ogg conversion... ffmpeg ftw:

$ ffmpeg -i in.mp3 -acodec vorbis -aq 60 -strict experimental out.ogg

jsdrama.com is live though. Enjoy and feel free to add more next time.

(image from wikipedia)

Here's a cover of We Wish You a Merry Christmas I just did. It's in a Bulgarian (and other Balkan countries) style in 7/8 tempo (and 9/8th at one place). This is me channeling my inner Goran Bregovich

We Wish You a Merry Christmas (7/8th and 9/8th)

Continuing the tradition (why did I skip last year?! oh I know, because 7/8 is damn confusing and I failed last year), here are the others:

• Feliz Navidad 2009
• Jingle Bells 2008

It's amazing to look back over the years and see how little I have grown as a musician and recording technician

Imagine there's no quirksmode
It's easy if IE6 dies
No Trident below us
And all the data URIs

Imagine all the web devs coding for today

You may say I'm a dreamer
But I'm not the only one
I hope some day you will upgrade
And the world will browse as one

The web performance and operations conference, Velocity Europe, is just around the corner. This always sold-out event is making its EU debut this year in Berlin.

Get your ticket now (with 20% discount no less) or punish your users and clients with slow user experiences

Info:

• url: http://velocityconf.com/velocityeu/
• cost: €600 after 20% discount (ow €749)
• discount code: veu11sts
• when: Nov 8-9
• where: Berlin
• hashtag: #VelocityConf

Some highlights from the program:

• Jon Jenkins will be talking about Amazon Silk.
• Browser sessions from Chrome, Firefox, and Opera.
• David Mandelin talking on JavaScript engines.
• Jeff Veen talking about Designing for Disaster.
• Estelle Weyl on Mobile UI Performance.

Full list of speakers here

Full disclosure: I'm in the program committee for the US event

Task: get me a 16x16 favicon for yahoo when all you have is the Yahoo search page

1. goto yahoo search, right click the icon, Inspect
   
2. Download the sprite:

   $ curl http://a.l.yimg.com/pv/i/us/sch/gr5/metro_sprite_20110907.png > ys.png
   

   here it is:
   

3. While inspecting the CSS you noticed

   width: 16px;
   height: 12px;
   background-position: -117px -95px;
   

   This helps us cut precisely as opposed to guess the coordinates

4. Crop it:

   $ convert ys.png -crop 16x12+117+95 yfavicon.png
   

   The result is a 16x12 image:
   

5. And because we have this arbitrary requirement that we want all favicons to be 16x16 because our design says so, let's resize it to fit a 16x16 box and center it inside the box

   $ convert yfavicon.png -background transparent -gravity center -extent 16x16 y.png
   

   Here:
   

6. And just because, let's make it 160x160 with colored background to make sure the command works

   $ convert yfavicon.png -background orange -gravity center -extent 160x160 yorange.png
   

   

7. Enjoy the rest of your day having saved some time by doing things on the command line instead of dealing with UI that gets in the way

Facebook now offers a new asynchronous snippet to load the JavaScript SDK, which lets you load social plugins (e.g. Like button) among doing other more powerful things.

It has always been possible to load the JS SDK asynchronously but since recently it's the default. The code looks pretty damn nice (I know, right!), here's how it looks like (taken from here):

(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) {return;}
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));

Some nice steal-me JS patterns here:

• immediate (self-invoking) function so not to bleed vars into global namespace
• pass oft-used objects (document) and strings ("script", "facebook-jssdk") to the immediate function. Sort of rudimentary manual minification, while keeping the code readable
• append script node by using the first available script element. That's 99.99% guaranteed to work unless all your code is in body onload="..." or img onload or something similar (insanity, I know, but let's allow generous 0.01% for it)
• assign an ID to the node you append so you don't append it twice by mistake (e.g. like button in the header, footer and article)

All buttons' JS files

Other buttons exist, most notably the Twitter and Google+1 buttons. Both of these can be loaded with async JavaScript whether or not this is the default in their respective configurators.

So why not make them all get along and shelter them under the same facebook immediate function? We'll save some bytes and extra script tags in the HTML. For G+/T buttons all we need is a new script node. Google+'s snippet has some additional attribs such as type and async, but these are not really needed. Because type is always text/javascript and async is always true. Plus we kinda take care of the async part anyways.

The end result:

  <div id="fb-root"></div>
  <script>(function(d, s, id) {
    // fb + common
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) {return;}
    js = d.createElement(s); js.id = id;
    js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
    fjs.parentNode.insertBefore(js, fjs);
    // +1
    js = d.createElement(s);
    js.src = 'https://apis.google.com/js/plusone.js';
    fjs.parentNode.insertBefore(js, fjs);
    // tweet
    js = d.createElement(s);
    js.src = '//platform.twitter.com/widgets.js';
    fjs.parentNode.insertBefore(js, fjs);
  }(document, 'script', 'facebook-jssdk'));</script>

So this thing loads all three JS files required by the three buttons/plugins.

Additionally we can wrap the node creation/appending part into a function. So all the code is tighter. Here's the final snippet:

<div id="fb-root"></div><!-- fb needs this -->
<script>(function(d, s) {
  var js, fjs = d.getElementsByTagName(s)[0], load = function(url, id) {
    if (d.getElementById(id)) {return;}
    js = d.createElement(s); js.src = url; js.id = id;
    fjs.parentNode.insertBefore(js, fjs);
  };
  load('//connect.facebook.net/en_US/all.js#xfbml=1', 'fbjssdk');
  load('https://apis.google.com/js/plusone.js', 'gplus1js');
  load('//platform.twitter.com/widgets.js', 'tweetjs');
}(document, 'script'));</script>

All buttons' markup

Next is actually advising the scripts where the widgets should be rendered. Facebook offers XFBML syntax, with tags such as <fb:like>, but it also offers pure HTML(5) with data-* attributes. Luckily, so do all others.

Here's an example:

<!-- facebook like -->
<div class="fb-like" data-send="false" data-width="280"></div>
<!-- twitter -->
<a class="twitter-share-button" data-count="horizontal">Tweet</a>
<!-- g+ -->
<div class="g-plusone" data-size="medium"></div>

G+ requires a div element (with g-plusone class name), Twitter requires an a (with a twitter-share-button class name). Facebook will take any element you like with a fb-like class name (or fb-comments or fb-recommendations or any other social plugin you may need)

Also very important to note that you can (and should) load the JS files once and then render as many different buttons as you need. In Facebook's case these can be any type of plugin, not just like buttons. Economy of scale - on JS file, many plugins.

All together now

So here's the overall strategy for loading all those buttons.

1. Copy the JS above at the bottom of the page right before /body just to be safe (G+ failed to load when the markup is after the JS). This will also help you make sure there should be only one place to load the JS files, although the snippet takes cares of dedupe-ing.
2. sprinkle plugins and buttons any way you like anywhere on your pages using the appropriate configurator to help you deal with the data-* attributes (FB, G+, Tw)
3. Enjoy all the social traffic you deserve!

To see it all in action - go to my abandoned phonydev.com blog. Yep, those buttons play nice in mobile too.

You get an input:

<input>

You add an x-webkit-speech attribute

<input x-webkit-speech>

And voila!

Or if you don't have a recent Chrome version, here's what these who have a recent Chrome version see:

Nice.

Textareas

Speech inputs - gotta love them. But in textareas - you can't have them. So you can put an input and a textarea and copy over the content.

html:

<textarea id="txt"></textarea>
<input x-webkit-speech id="mike"/>

With some CSS you can remove the border, add pointy cursor, etc make it look like not an input.

#mike {
    font-size: 25px;
    width: 25px;
    height: 25px;
    cursor:pointer;
    border: none;
    position: absolute;
    margin-left: 5px;
    outline: none;
    background: transparent;
}
#txt {
    height: 150px;
    width: 150px;
}

Finally a little JavaScript to a/ unfocus the input and b/ carry over the content from the input to the textarea

var mike = document.getElementById('mike');
mike.onfocus = mike.blur;
mike.onwebkitspeechchange = function(e) {
    //console.log(e); // SpeechInputEvent
    document.getElementById('txt').value = mike.value;
};

That's all there is. Click over to the demo.

Here's what you should see in Chrome:

You can see that console.log() there - it's definitelly worth exploring. The thing is a SpeechInputEvent type of object is passed to the handler of the onwebkitspeechchange event. This object has some interesting properties, such as the array results[] which is number of guesses what you've said and confidence (0 to 1 it seems) in the guess.

Enjoy and go ahead and add these all over the place!

Billy Hoffman (@zoompf) is the founder and CEO of Zoompf, a web performance startup whose scanning technology helps website owners find and fix performance issues which are slowing down their sites. Previously Billy was a web security researcher at SPI Dynamics and managed a research team at HP. He can open a Coke can without using his hands.

(tl;dr: Images make up the majority of the Internet, yet we consistently fail to apply the most basic of optimizations. Even big sites like Twitter are completely screwing this up. Furthermore, there are huge unexplored areas when it comes to image optimization which would provide significant savings. We should stop worrying about esoteric performance optimizations when there is so much other low hanging fruit.)

Images constitute the bulk of content on the Internet, both in terms of content size and number of resources. Using data from the wonderful HTTP Archive we see that 60% of the bytes that make up an Alexa Top 1000 website are images. The average webpage references 81 external resources, and 64% of these are images. And the dominance of images is growing. In the last 6 months, total page content size increased by 70 kB. 75% of that increase (52 kB) came from images.

We know that lossless image optimization tools reduce content size anywhere from 5-20%. Occasionally you will see 70% savings or more, but that only happens when the image contains an embedded thumbnail. That level of savings doesn't sound all that impressive. After all HTTP compression can save 60-70% on real world text resources like HTML, JavaScript, or CSS. However text resources only make up on average 188 kB, or 24% of total content size. Saving 66% on 24% of content saves about as much as 5-20% savings on 60% of the content. In fact, if you could reduce images by 25%, that would have more of an effect on reducing total content size than using HTTP compression!

If you work in front-end performance, none of this should be a surprise. Obviously any front-end performance strategy needs to include image optimizations. Image optimization is an old topic. Shouldn't we instead be focusing on more esoteric optimizations, like refactoring CSS rules so that external fonts render faster on Blackberry Webkit? No, we shouldn't, because sadly we collectively suck at optimizing images.

Give PNG a Chance? Nope.

One of the most basic image optimizations that you can make is converting GIFs to PNGs. PNGs can do everything that GIFs can do and more, and the browser issues with PNGs are larger a problem of the past. Even without applying additional lossless optimization tools on the PNG, converting a GIF file will almost without exception create a smaller PNG. This is because the fundamental way graphics data is compressed in a file PNG, using the DEFLATE algorithm, is more efficient than GIF's LZW compression scheme. Once you apply lossless tools on the converted PNG they get even smaller. Animated GIFs are the exception here, as PNGs are not animated and alternatives for simple animations (MNG, Flash) are either not widely supported or result in larger files. So what is the break down of image formats on the web today?

37% of images on the Alexa Top 1000 websites are GIFs. That makes no sense given what we know about PNGs over GIFs. 37% of the images on the Internet are not animated "Under construction" icons or Ajax status thumper animations. People are not being intelligent about file formats they use for images.

The Internet, now with more bloat!

Applying lossless image optimization tools is one of the simplest optimizations to do. Take an image, run a program, get an optimized image. Stoyan and I love optimizations like this because they are so easy to automate. Just add a step to the website build process or to your staging-to-production publishing process that automatically optimizes images. It should be transparent, something you setup once and forget about. So how are we doing?
82% of Alexa Top 1000 websites contain images which were not losslessly optimized. Apply lossless optimizations across all the images from the Alexa top 1000 would reduce file size by an additional 15%.

Surely there are just a few number of smaller sites which aren't properly optimizing images which are pulling down the statistics right? Sadly no. Twitter, the ninth largest website in the world by traffic, doesn't losslessly optimize any of their images. 33% of total page load bytes could be eliminated solely by applying lossless image optimization. Let me phrase that a different way: 1 byte of our every 3 bytes Twitter sends you is unnecessary! This is an incredible waste.

Unplowed Fields

It's clear we are not applying the image optimizations we already know about. However there is much more work to be done with images. This is a largly unresearched or unadvocated area which needs more attention.

Consider choosing the correct image format. Are people saving images as a PNG when they should be saved as a JPEG? Indeed they are. Tumblr's background image is a 76 kB PNG image and it would be 33 kB (55% smaller) if it was a JPEG. This is better than their old 827 kB PNG background image, which would be 47 kB (94% smaller) if it was a JPEG. Unfortunately I know of no other tool besides Zoompf's free performance scan which identifies PNG candidate images for conversion to JPEG.

What about JPEGs saved with a high quality setting? This is a large enough topic for its own blog post. To quickly summarize, JPEG "quality" is an arbitrary, non-linear scale, quality is not a percentage of anything, and "quality of 80" does not mean "discard 20% of graphics data." Thought leaders like Adobe recommend a quality setting of 70-80 for JPEGs published on the web. Zoompf found that 36% of Alexa Top 1000 images have a quality setting over 80, and reducing them to quality 70 would on average reduce image size by 48%! While all of these images might not be able to be reduced in quality, surely some of them can. Again, this is an area that needs more attention, more best practices and guidance, and more tools to help validate.

Not "Instead of" but "In addition too"

I am not saying other performance optimizations are not important. Zoompf checks for over 380 performance issues and we are adding more all the time. Many of them are esoteric and low impact. We flag things like duplicate cookies, unnecessary HTTP headers, and even when your <META> contains duplicate keywords. However these checks are for when you have handled all the other important checks. Image optimizations, and research into new image optimization techniques should be not done instead of other work, but in addition to it. Just remeber to prioritize what you are working on so that it will affect the most number of people in the largest possible way.

Conclusions

Images are a huge component of the web and modern web performance. This importance is only growing. Sadly, there are only one or two widely recognized image optimizations techniques. Unfortunately, these most basic optimizations are ignored, forgotten, and not uniformly applied by even the largest of websites today. Additionally, there are a lot of unexplored areas of image optimization, including lossy image optimization, with no clear recommendations or best practices and virtually no tool support. Some areas for further research include:

• Lossy image optimizations
• Comparison of JPEG encoders
• PNG-to-JPEG and GIF-to-JPEG best practices, recommendations, and processes
• Image quality for Desktop vs. mobile browsing experiences
• Better PNG24 to PNG8 conversion guidelines. (I converted all the figures in this blog post from PNG24 to PNG8 and reduced file size by 52%)
• Viablility of WebP and automated delivery to supported browsers

I will be discussing many of these topics this week during my presentation Take it all Off! Lossy Image Optimization at Velocity 2011 on Wednesday. I hope you all can make it.