Ajax Performance
IE8: The Performance Implications
March 7, 2008 on 1:25 am | In ajax | No CommentsMix08 is here, and with it the first beta of IE8. John has a great roundup of the JS/Dom work, noting that “Internet Explorer 8 is our release.” He’s right.
I’ll run through a few of the items that have particular implications for performance.
- This one is the most exciting for me: the IE team has finally upped the connection limit to 6 per host from the default of 2. I’ve talked before about DNS tricks to get around the 2 connection limitation, but having this support out of the box will be a great assistance in the war on round-trip latency as it’s easier to make more expensive network calls in parallel. This is especially sweet for Comet and the like where the persistent connection could previously monopolize half of the connections to your site. As you would expect, Joe Walker of DWR is happy.
One thing I haven’t seen mentioned anywhere is the total connection limit. Previous versions supported 2 per host and 6 total. Is the new version 6 per host / 6 total or 6 per host / 18 total. I really doubt it on the latter, but if no one has the answer I’ll grab the beta this weekend and test it out.
- w3c Selectors API — Last month I discussed the work Firefox and WebKit have done to implement the new Selectors API spec, and it’s nice to see Microsoft is joining the list. I share John’s concern that these black boxes have a significant potential (make that inevitability) of browser bugs, so smoothing over these will, as always, remain the job of libraries. But it’s nice to have that blazing speed under the covers.
- DOM Storage and offline events are techniques still on the fringes of relevance. DOM Storage in Firefox 2, as well as Google Gears and its less nerdly cousin Dojo Offline, have a lot of promise, but to this point they’ve lacked a killer app due in no small part to the chicken and egg problem. Having Microsoft on board finally offering these HTML 5 features may help push us to widespread adoption.
- I’ve dinged Microsoft for the lack of a Firebug-like tool since, well, I first used Firebug, and they finally have a clone. A clone in serious need of a makeover. Yeah, I’m shallow. For those keeping score at home, the sexiness hierarchy goes Webkit Inspector > Firebug > IEBug (or whatever it’s eventually called).
- For the truly performance obsessed, there are a collection of optimizations to common low level functionality, such as string concatenation and array manipulation.
Include, a new JS compression wrapper
February 27, 2008 on 10:45 am | In ajax | No CommentsEarlier this week, I talked about a tool which removes much of the tedium from generating CSS sprite maps. In a similar vein, Brian Moschel of the JavaScriptMVC Project pointed our good friends at Ajaxian to Include, a wrapper around Dean Edwards’ excellent JS compression tool, Packer.
Include is itself a fairly small chunk of JS which is designed to run within the browser of development and production users. This approach has some nice advantages: there’s no need for server side compression scripts and it’s easy to create many different compressed files depending on the different library requirements in different parts of your application. Expanding on that last point, you can select at browser load time which library to use within a specific page giving you runtime flexibility.
The one thing I don’t like is that Include is packaged as a separate .js file. As I’ve discussed here many times, performance in modern broadband networks is dominated by latency. The round trip time to request the initial include.js, which is only 3kB, will offset some of the gains from compressing and concatenating library files. In most use cases, the best performance approach will be to use include.js to compress your libraries only during development time, replacing all include.js references in production with a single compressed library call per page.
