Anyone who has had the task (or, perhaps more insanely, given himself the task) of measuring the relative performance of various Web browsers knows how impossible it is to convince everyone of the validity of his chosen metrics. (Guilty as charged.) Some folks settle for running a Sieve of Eratosthenes algorithm in JavaScript; others will call up Google’s V8 benchmark page which always seems to give tremendous numbers for Chrome; and still others prefer loading google.com 100 times, averaging the load times, and concluding there’s not much to conclude.
Since last June, W3C has taken up the task of creating a uniform specification for all browser manufacturers to adopt. This specification includes a suite of JavaScript APIs that enable browsers to determine how much time certain fundamental tasks may consume – changing the active page, loading a page into memory, downloading any discrete amount of data from a server.
The goal is not just to give speed freaks like me a new and unchallengeable method of measuring how long it takes to load a Web page. When a script loaded into a browser is capable of measuring the workload capacity of that browser, it may be able to tailor the workload to suit the browser. This is especially critical, W3C determined, in a broadening environment where Web apps designed to be capable of running entire factories can run on smartphones.
In a test case published last month by Microsoft, which co-chairs the W3C’s Web Performance Working Group, a browser becomes capable of determining when the monitor is ready to receive the next frame of animation, using a new API called requestAnimationFrame. The technique is similar to what developers use today with JS statements such as setTimeout and setInterval, explained IE Program Manager Jatinder Mann. “The key difference is that it notifies the application when the browser needs to update the screen, and only when the browser needs to update the screen. It keeps Web applications perfectly aligned with the browser’s painting, and uses only the necessary amount of resources.”
When W3C fully standardizes this API function, browsers will be able to implement it without use of brand-specific prefixes, which various manufacturers use for safety reasons. The final form of that function in a JS instruction looks something like this: if (window.requestAnimationFrame) window.requestAnimationFrame(draw);, where draw points to the single callback function that executes the drawing.
“Resource Timing, User Timing, and Performance Timeline specifications are all in the Last Call phase of specification,” Mann wrote today. “Last Call is a signal that the working group believes the spec is functionally complete and is ready for broad review from both other working groups and the public at large. This Last Call period extends until September 15, 2011.”
Mann is the co-author, along with Working Group chair Arvind Jain of Google, of the latest draft of the Page Visibility specification, whose Last Call phase expires September 8. The Performance Timing and Navigation Timing specs work in concert to enable scripts to effectively time the complete page loading phase, rather than wait for the entire JavaScript content to be loaded first – which is the current situation. Although W3C specifications clearly state, “The interface provided by this work does not intend to be used as any sort of performance benchmark for user agents,” you can bet that this is precisely what it will be used for the moment it’s made public.
In celebrating the first year of the Working Group’s operation, Microsoft’s Mann wrote, “It’s encouraging to see how much progress we’ve collectively made in just one year. These APIs are a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers.”
