Steve Souders has released a nice little tool called Cuzillion which has the tag line of ‘cuz there are zillion pages to check, although it could also be that there are a zillion ways to do Web development!
The tool lets you test out different techniques for optimizing performance in browsers, and these tests can be saved and shared by the community.
Steve explains how the tool came about:
I’m constantly thinking of or being asked about how browsers handle different sets of resources loaded in various ways. Before I would open an editor and build some test pages. Firing up a packet sniffer I would load these pages in different browsers to diagnose what was going on. I was starting my research on advanced techniques for loading scripts without blocking and realized the number of test pages needed to cover all the permutations was in the hundreds. That was the birth of Cuzillion.
Here Steve talks about some examples:
A great example of how Cuzillion is useful is looking at the impact inline scripts have when they follow a stylesheet in Internet Explorer. Typically, a stylesheet followed by any other resource results in both resources being downloaded in parallel in Internet Explorer. (In Firefox stylesheets block parallel downloads, so this performance optimization is only applicable to IE.) Here’s a Cuzillion page that shows this: stylesheet and image downloading in parallel. Both the stylesheet and image are configured to take 2 seconds to download. Since they download in parallel the page takes about 2 seconds to load as shown by the “page load time”.
But look what happens if we put an innocent inline script between the stylesheet and image: stylesheet, inline script, and image. Now, in Internet Explorer the stylesheet and image are downloaded sequentially, which means the page load time goes from 2 seconds to 4 seconds. If the inline script is simply moved above the stylesheet the two resources are downloaded in parallel again, and the page load goes back down to 2 seconds: inline script, stylesheet, and image.
This was a great discovery. But immediately my officemate asked if inline style blocks had the same effect. No problem. With Cuzillion I just do some clicks and drag-and-drop, and can test it out: stylesheet, inline style block, image. It turns out inline style blocks don’t cause stylesheets to block downloads.
The findings from a tool like Cuzillion are really valuable. The lessons learned from poking at inline scripts and stylesheets can save hundreds of milliseconds on page load times. And it’s a common problem. eBay, MSN.com, MySpace, and Wikipedia all suffer from this problem.
Much thanks to Google for letting me release this code under Open Source. It’s not currently on Google Code but if you want to contribute let me know and I’ll do that. Try it out and send me your feedback. And share your insights with others. We all want the Internet to be faster!
Steve is talking at Web 2.0 Expo today at 1:30pm in room 2002. If you are in town, check it out and see Cuzillion in action!
Test lets you simulate every major DOM event, as well as some combination events like Write and Drag, simulate Ajax, and use assertions. It runs functional and unit tests in a separate console window. Another nice feature is that if you use it with the Controller plugin, helper methods are automatically created that simulate each controller action's event, such as TodoClick.
The study rightfully claims that object detection to determine whether a user agent is capable of supporting a certain interface is not enough. You also need to make sure that the browser supports the right look and feel - in other words that the CSS you will apply can be rendered as intended.
I've done similar things in the past, reading out the offsetWidth of an element to determine if the browser is in standards or Quirksmode but Filamentgroup's test script goes a lot further than this. It tests for the following CSS support:
Box model: make sure the width and padding of a div add up properly using offsetWidth
Positioning: position a div and check its positioning using offsetTop and offsetLeft
Float: float 2 divs next to each other and evaluate their offsetTop values for equality
Clear: test to make sure a list item will clear beneath a preceding floated list item
Overflow: wrap a tall div with a shorter div with overflow set to 'auto', and test its offsetHeight
Line-height (including unitless): test for proper handling of line-height using offsetHeight, primarily to rule out Firefox 1.0
For example the right box model support is tested with this script:
When you start a new JavaScript library, how do you layout the source files, the tests, the distribution files? Do you have support scripts to generate distributions from source files? Run your JavaScript unit tests? Generators to create new unit test HTML files?
This is why Dr. Nic created newjs, a Ruby script that sets you up to do the right thing by your pet project. No longer will you crack open a .js file and slice and dice your JavaScript willy nilly. Instead, you will use newjs to:
Setup your directory structure for src, tests, documentation, distribution
Start building unit tests using unittest.js
Generate test files
Run unit tests and get nice HTML output
Package up your src for distribution
Create a website for your project (wait. is this maven???? ;)
He talks about a new site, inursite.com that does one thing:
The premise is simple; enter a few of your sites and inursite will visit them once a day and run a markup validation service over the page. You then get a feed of the pass or failure status. It’s simple but brilliant. For example, I have this very site added to the service. If I put some invalid markup in this post, tomorrow morning I’ll get an item in my feedreader telling me of my mistake. I’ll get that every day until I fix the problem.
This green/red (pass/fail) type approach to simple tests is what I find most powerful about continuous integration systems like Cruise Control.
Gareth also has some ideas for improvement:
Has all the CSS been compressed using something like CSSTidy.
Has all the javascript been compressed using something like JSMin.
Does any Javascript pass the harsh taskmaster that is JSLint.
If my markup a little bloated? Maybe I could set a maximum size for the markup and get a fail is I go over that.
Ditto CSS file size.
Ditt Javascript.
Ditto images.
If pages have associated feeds, then validate them as well according to the relevant specification (probably RSS or Atom).
How many HTTP Requests does it take to load the whole page, including all the relevant assets.
How many hosts are required to load the whole page? I’d like to be able to set a maximum number and get a fail if I go over that.
Is the page gzipped on the server.
And just to keep this topical, does the page have either the IE8 meta element or the associated HTTP header set to a particular value.
This sounds like setting up YSlow to run in a continous manner.
Didier Durand wanted to check the compliance of various OpenSocial containers, so he decided to create a tool, IGCheck, that will do the checking for him:
The purpose of IGCheck is to test and report which functions of the Google Gadget API (i.e., prefixed with _IG_ in their Javascript name) are available in which containers. IGCheck then produces a report comparing the current test with reference data.
To get current status, check this page to see the most current result that we can produce concerning igoogle, orkut, hi5 & ning.
As the number of opensocial partners that are open for tests remain limited as of now, the following conclusions can be drawn as of now :
Hi5 does the same and as such seems to have "outsourced" the task of running its opensocial container to Google (see the line "host" in the result array)
Ning has followed a more independent approach by implementing a fully independent container named "proxy.ning.com" (see the line "host" in the result array)
The choice of Ning has currently drawbacks: IGCheck finds only 6 _IG_ functions whereas 55 are present in the others. (see the line "count" in the result array)
Ning seems to have created its own function(s) with _IG_Prefix: a function "G_Tabs" is present in the Ning container but nowhere else(see the line "_IG_Tabs" in the result array).
The conclusions above are preliminary results only:
the current and future containers will have to converge after the current pioneering phase in order to reach the promise "Write Once, Run Anywhere" although the fact that IGCheck itself is a proof of partial achievement (IGCheck source code is unique for all containers)
the opensocial initiative will have to get more precise on Google Gadget API requirements: the debate on this topic is currently hot on the opensocial discussion group as nothing (at least to my knowledge...) has been clearly and officially stated in this area until now . A poll is under way. The target is to get opinions of developers and eventually to define to which extent opensocial containers have to implement the _IG_ API.
See the current results, and help Didier get this running in other containers.
assertEquals('text', String.prototype.trim.call(' text \n ');
}
What is Crosscheck?
Crosscheck is an open source testing framework for verifying your in-browser javascript. It helps you ensure that your code will run in many different browsers such as Internet Explorer and Firefox, but without needing installations of those browsers. The only thing you need is a Java Virtual Machine.
, Showcase
