In case you missed it the latest Internet Explorer 9 Platform Preview is out and it’s a thing of beauty. It added Canvas support so the first thing I did was run it through some demo code. It’s faster than Chrome. Visibly faster. No benchmarks needed. It’s such an incredible difference from the current Internet Explorer family which are many times slower than the good browsers out there.

The good news doesn’t stop there. There’s actual standards support.

PPK enthuses:

In the past few days I’ve been revising the CSS compatibility table with information about the latest crop of browsers. There’s no doubt about it: this is IE9’s show. It just supports nearly everything. No hassle, no buts.

And then enthuses some more:
Read the rest of this entry »

With more and more people embracing the idea of producing HTML5 mobile web apps, research like this is becoming vital. There are a lot of gotchas in this article, especially if you’ve been ignoring this space.

You should read the whole article, but I just want to point out a pair of findings before I send you on your way. One has been a known issue for a while (it’s a ySlow rule, after all,) but it’s still worth pointing out. The other… wow… my emphasis.

Results varied wildly across the three most recent versions of iOS. Astonishingly, Mobile Safari on iOS 3.1.3 did not cache components of any size, despite having an apparently unlimited page cache size. This is troubling since it means iOS 3.1.3 users are likely getting a suboptimal browsing experience, especially if they aren’t using wifi. The unlimited page cache size does little good here, since it only comes into play for back/forward navigations. This behavior is a significant change from what others observed in previous iOS releases and I can’t imagine any good reason for it, so I suspect this may be a bug.

Mobile Safari on iOS 3.2 (which is only available on the iPad) does not exhibit this bug. Its 25.6KB component limit and ~281.6KB total cache limit are better than nothing, but they still seem paltry compared to the other devices tested. Uniquely among iOS devices, the iPad appears to limit the size of pages in the page cache to 25.6KB, the same as its component size limit.

Read the rest of the article:

Mobile Browser Cache Limits: Android, iOS, and webOS

I’m going to be picking off presentations whenever the opportunity presents itself. Want to play along at home? Blip.tv to the rescue:

Next year, I’m going.

I’ve seen this a few times over the past few months:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>

What that basically says to Google is “give me the latest 1.* branch version of jQuery and make sure it’s minified.”
Read the rest of this entry »

One of the reasons I’m drawn to the performance side of the business is that it’s one of the few pieces of of your site or application where you can really know when you’re doing the right thing.

There are a lot of questions that can run through your head during a site build. Is the design right? How about the feature set? do these labels make sense? Is the language correct for my audience? Does this visualization truly illustrate the underlying data and add meaning? Was I right to use canvas? Should we be using web storage?

Those (and many other examples) are the things that can (and should) your thoughts. You can leverage experience and best practices throughout, but there are always mistakes, miscommunications and surprises waiting around the corner, so sweating the details of a design or interaction model can make or break an application.

One aspect that brings a little bit of certainty is the question of speed.

The site is either fast, or it isn’t.

There are certainly degrees of “fast,” a full featured application won’t be as fast as Google.com, but once you’ve defined a speed goal there are plenty of ways to know if you’re hitting your marks which makes it a bit more satisfying than the stuff that’s a little more nebulous (or takes a little longer) to measure.

Front End Performance for the Common Man: Practical Strategies to Speed Up Your Site from rob larsen on Vimeo.

Follow along with the presentation. (PowerPoint presentation)

Here’s the sample ant build script referenced in the deck. (Zip file)

And here’s the article mentioned in one of the early slides:
Why Front End Performance Matters to Everyone, Not Just the High Traffic Giants

I presented at Bocoup last night. It went really well. As always great people showed up and I think I did okay with my side of the bargain. I shot some video, we’ll see how that turns out. If it’s of reasonable quality I’ll be sure to share.

For anyone interested, here are a couple of downloads from last night.

Here’s the deck.

And this is the sample ant build script referenced in the deck.

I’m going to write up the build script in a little bit more depth some time over the next couple of weeks.

I’m in the middle of finishing up my presentation, so I figured I might as well make an effort to get some people to show up to see the results of my hard work

Here’s the write up:

Front End Performance for the Common Man: Practical Strategies to Speed Up Your Site

Day: Wednesday May 19th 2010
Time: 6:30pm – 8pm
Cost: Free

Rob Larsen will examine the core concepts and techniques behind the performance of the web’s fastest sites and will translate them into practical examples. This talk will cut across several technologies (JavaScript, CSS, Ant, Apache and more) to present a suite of tools any developer can use to speed up their site- no matter the size or budget. RSVP to The Event Page.

It’s going to be a really good talk- full of practical examples and advice for every flavor and level of web developer. You should totally go.

I promised one last post on HTML elements. This is it. This one will be a quick tour through some of the new semantic HTML5 elements. I’ve been using them regularly for a while now and I’m still trying to wrap my head around the best way to use some of them (in this, I’m not alone.) Hopefully sharing what I’ve learned will help jump start your own work with the new stuff and will help my clarify my own thoughts on the new elements.

This should really be fun.

header

This is one of the most straightforward of the new elements. <div id="header"> becomes <header>. Done. When I’ve presented on HTML5 people just nod when I point this element out. Hopefully this one just makes sense.

One experimental note

One thing we’ve been experimenting with at work is using multiple headers on a page. The pattern looks like this:
Read the rest of this entry »

I started doing some writing for Isobar/Molecular.

My first post:

An Introduction to HTML5

HTML5 is the latest version of the language that serves as the foundation of the web. It’s the first major revision in over 10 years and as it’s gotten closer to its final form and more and more browsers begin to implement its features it’s become a source of intense interest and contention in the technology community. This article hopes to explain the realities of HTML5, dispel a couple of myths and shine some light on the future of the web.

To begin we’ll need to define what we’re talking about when we say “HTML5.” There is a specification to refer to and much of what falls under the HTML5 name lives in that spec. In addition, there are several related specifications and APIs that are lumped together and called “HTML5″ when people talk about these things informally.

So, conversationally, HTML5 consists of the following:

New Semantic Elements

HTML5 has introduced several new elements. They aim to introduce more meaning to markup and codify existing web development patterns. Some examples of these new elements are nav (for navigation), article, header and footer.

Read the rest of this entry »

I also added a few bits and bobs to our our front-end development best practices, a doc which has been making the rounds a little bit over the past week.

Check ‘em out.