Reversing Code Bloat with the JavaScript Knowledge Base

JavaScript libraries let developers do more with less code. But JavaScript libraries need to work on a variety of browsers, so using them often means shipping even more code. If JQuery has code to support XMLHttpRequest over ActiveX on an older browser like IE6 then you end up shipping that code even if your application doesn't support IE6. Not only that, but you ship that code to the other 90% of newer browsers that don't need it.

This problem is only going to get worse. Browsers are rushing to implement HTML5 and EcmaScript5 features like JSON.parse that used to be provided only in library code, but libraries will likely have to keep that code for years if not decades to support older browsers.

Lots of compilers (incl. (JSMin, Dojo, YUI, Closure, Caja) remove unnecessary code from JavaScript to make the code you ship smaller. They seem like a natural place to address this problems. Optimization is just taking into account the context that code is going to run in to improve it; giving compilers information about browsers will help them avoid shipping code to support marginal browsers to modern browsers.

The JavaScript Knowledge Base (JSKB) on browserscope.org seeks to systematically capture this information in a way that compilers can use.

It collects facts about browsers using JavaScript snippet. The JavaScript code (!!window.JSON && typeof window.JSON.stringify === 'function') is true if JSON is defined. JSKB knows that this is true for Firefox 3.5 but not Netscape 2.0.

Caja Web Tools includes a code optimizer that uses these facts. If it sees code like

if (typeof JSON.stringify !== 'function') { /* lots of code */ }

it knows that the body will never be executed on Firefox 3.5, and can optimize it out. The key here is that the developer writes feature tests, not version tests, and as browsers roll out new features, JSKB captures that information, letting compilers produce smaller code for that browser.

The Caja team just released Caja Web Tools, which already uses JSKB to optimize code. We hope that other JavaScript compilers will adopt these techniques. If you're working on a JavaScript optimizer, take a look at our JSON APIs to get an idea of what the JSKB contains.

If you're writing JavaScript library code or application code then the JSKB documentation can suggest good feature tests. And the examples in the Caja Web Tools testbed are good starting places.

By Mike Samuel (Caja), Lindsey Simon (Browserscope)

Introducing Page Speed

At Google, we focus constantly on speed; we believe that making our websites load and display faster improves the user's experience and helps them become more productive. Today, we want to share with the web community some of the best practices we've used and developed over the years, by open-sourcing Page Speed.

Page Speed is a tool we've been using internally to improve the performance of our web pages -- it's a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn't actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.

Page Speed's suggestions are based on a set of commonly accepted best practices that we and other websites implement. To help you understand the suggestions and rules, we have created detailed documentation to describe the rationale behind each of the rules. We look forward to your feedback on the Webmaster Help Forum.

We hope you give Page Speed a try.

By Richard Rabbat and Bryan McQuade, Page Speed Team

Rob Campbell: Debugging and Testing the Web with Firebug

The sixth Web E^xponents tech talk features Rob Campbell's presentation on Firebug. Rob works at Mozilla. He's one of the developers that Mozilla dedicated to the Firebug effort last July. Rob is one of the main drivers of the Firebug project, starting and heading up the weekly concalls, and closely tracking bugs and releases. As one of the founders of the Firebug Working Group, I'm excited to see Mozilla taking a more active role in Firebug. The benefits are clear as we see more features and greater stability with each Firebug release. Here's the video of Rob's presentation as well as a link to his slides.



Rob starts by highlighting what's new in Firebug 1.4 alpha. It's a joy for me to see that activation (enabling and disabling) has been simplified. Rob points out that the firebug icon serves also as a menu. One of the menu items is "Open With Editor", which developers will find useful for saving changes to their pages. A much needed UI change is flipping the tabs and buttons. The tabs used to be below the buttons. Putting them at the top is closer to what users expect from working with other tabbed UIs.

The new "pause" button will be useful for anyone debugging JavaScript. This implements "break on next" functionality, making it easier to stop when event handlers are called. Firebug's Net Panel has had significant improvements. The UI is better (colors!), but there's even more. The underlying timing information has been improved to give more accurate results. There are also markers for DOMContentLoaded and OnLoad, to show where those fire in relation to network requests.

Firebug Extensions provide a way for developers to add functionality that can be shared with others. Rob mentions several extensions including:

• Firediff - tracker for changes made to DOM and CSS
• FireCookie - cookie manager
• FirePHP - console logging from PHP
• YSlow - performance tips
• FireRainbow - JavaScript syntax highlighting

Writing an extension is a great way to explore future directions for Firebug.

Rob talks about future roadmap. Firebug 1.5 will focus on extensions - making them easier to build and use. Firebug 1.6 will change the underlying JavaScript debugging mechanism in Firefox to support new features. Add Rob's blog to your RSS reader to find out about these future releases and other improvements to Firebug.

By Steve Souders, Performance Evangelist

Web Exponents

Over the last few months, I've started inviting web gurus I know to give tech talks at Google. It's been great to kick off this speaker series with such luminaries as John Resig, Doug Crockford, and PPK. (I snuck in there, too.) The biggest benefit from these talks is the release of the videos and slides. The videos are popular, with thousands of viewers. The videos make it possible to share these insights with a wider audience who might not be at the next tech conference or workshop.

For various reasons (t-shirts, YouTube playlist), it's beneficial to give this speaker series a name. I've decided to call it Web E^xponents. I use "exponents" in the sense of "a person who actively supports or favors a cause". The cause, in this case, is evangelizing innovation and best practices in web development. And now, thanks to fellow Googler Mark Chow, we have the Web Exponents playlist on YouTube. You can find all the past and future videos there.

Web E^xponents speakers coming up next include Rob Campbell (Firebug) and Nicholas Zakas (Yahoo! JavaScript expert). I'll write a blog post for these and other future talks, and you can subscribe to the playlist to make sure you catch all the videos.

And now for the mandatory cheesy tagline: Web E^xponents - raising web technology to a higher power.

By Steve Souders, Performance Evangelist

Cuzillion: Check your zillion web pages

By Dion Almaer, Google Developer Programs

Steve Souders, member of the performance group at Google, has released a new open source tool called Cuzillion. Steve was constantly creating sample test web pages that he used to test out theories on Web site performance. He realized that he was repeating a lot of the same steps, so why not create a tool that would enable him to build the samples quickly. Thus, Cuzillion was born.



If you take a look at the UI above, you will see that it is mimicking a Web page, with a <HEAD> and <BODY>. On the left hand side you select types of elements; such as images, scripts, CSS, and other resources. You add these elements to the mini page on the right, and then you can select that element to set more properties on it. For example, you can quickly set the domain that it is running on, which allows you to test splitting our content on domains.

We sat down with Steve and produced the video below in two parts. It starts off with him discussing the project, and then delves into a screencast of the product itself. He gives us an introduction, and then shows how he used it to solve an issue with Orkut.