Anyway, to break the ice here are a few articles that have recently caught my attention.

Why is getElementsByTagName() faster that querySelectorAll()?

I love articles like this. There’s so much attention paid to the surface we plaster over the core JavaScript language, I eat up anything that looks at the core. Shedding light on which natives are faster and why allows us to both speed up the abstractions and simply know which way to go when the situation calls for writing Plan Old JavaScript™.

jQuery Regular Expressions Review

I’ve read a bunch of the jQuery source, so I was familiar with some of these already having parsed through them- just to drive myself mental and/or torture folks who fear regular expressions. The difference between being able to write safely matching regular expressions and writing efficient ones is pretty big and not many people can really do the latter. It’s nice to get a peek into the process.

Are your performance goals audacious enough?

I just love the sentiment. I also love the fact that Google is aiming for 100ms for a page load. It’s a crazy number if you break it down. The engineering and hardware gymnastics involved are considerable and the margins are so slim things like the speed of light will come into play, but the mere fact they’re talking about it is enough for me to applaud.

The number, by the way, doesn’t come out of thin air. 100ms is the limit where an interaction with a computer stops feeling instantaneous. Very little we do on the web actually feels instantaneous. Google wants everything they do to feel that way.

Sandboxed Natives

Series of screencasts about the core idea behind FuseJS. I clearly remember the Dean Edwards post that started it. Funny how the reaction to a technical musing could grow to such an impressive project. Interesting stuff.

Render first. JS second.

Interesting line of thought. It follows clearly from the work people have been doing with the deferred loading of scripts. I’m looking at doing a lot of this kind of work on my current project. We’ll see how it all shakes out.

WebP, a new image format for the Web

While I love the idea, this one will be a long time coming, considering the presumed ongoing (eternal?) lack of support in Internet Explorer.

Promote JS

A nice little project designed to get better links in front of people searching on Javascript topics.

It’s actually be a lot of fun as I’ve dived deeper into Ant than I would ever have had to normally. I feel like I’m pretty handy with it now and watching my initial work get improved upon by other folks has been fun all by itself.

I’m working on a write up of what I did and how to use it. I’ll share it here soon.

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

Next year, I’m going.

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

Minified is good. Using the Google CDN is good. One thing that’s not so good is the fact that the above file is set with the following headers:

Date: Wed, 23 Jun 2010 18:26:27 GMT
Expires: Thu, 17 Jun 2010 14:26:58 GMT
Age: 2045
Server: GFE/2.0

Notice anything about the expires headers? Yeah, it’s actually set in the past. That’s uncacheable. That makes sense as the purpose of that link is to get the freshest version so you don’t want the browser to hold onto an old version. Thing is, when you’re building a site you want the browser to hold onto a file like that, since it’s the site equivalent of plumbing.

So, instead of using the generic “latest” link format, pin it down to a specific version number

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

Here are those headers:

Content-Type	text/javascript; charset=UTF-8
Last-Modified	Mon, 15 Feb 2010 23:30:12 GMT
Date	Wed, 23 Jun 2010 17:26:41 GMT
Expires	Thu, 23 Jun 2011 17:26:41 GMT

That files expires 1 year from access. That’s what you want.