The Future of Web Performance at Google I/O: JavaScript

By Steve Souders, Member of Technical Staff

This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next month, we'll be highlighting sessions and speakers to give Google Code Blog readers a better sense of what's in store for you at the event. - Ed.

In April I announced that I'm starting another book. The working title is High Performance Web Sites, Part 2. This book contains the next set of web performance best practices that goes beyond my first book and YSlow. Here are the rules I have so far:

1. Split the initial payload
2. Load scripts without blocking
3. Don't scatter scripts
4. Split dominant content domains
5. Make static content cookie-free
6. Reduce cookie weight
7. Minify CSS
8. Optimize images
9. Use iframes sparingly
10. To www or not to www

I'm most excited about the best practices for improving JavaScript performance (rules 1-3). Web sites that are serious about performance are making progress on the first set of rules, but there's still a lot of room for improving JavaScript performance. Across the ten top U.S. sites approximately 40% of the time to load the page is spent downloading and executing JavaScript, and only 26% of the JavaScript functionality downloaded is used before the onload event.

In my session at Google I/O I'll present the research behind rules 1-3, talk about how the ten top U.S. web sites perform, demonstrate Cuzillion, and give several takeaways that you can use to make your web site faster.

Guido van Rossum releases Mondrian-clone: Rietveld

By Dion Almaer, Google Developer Programs

Guido van Rossum, Python creator and member of the App Engine team, gave a talk on Mondrian which is the tool he created to work with the code review process at Google.



The Mondrian tool itself was tied to internal technology, but he took the time to built an inspired version on App Engine. Part of the work was having it work with Subversion as the SCM. The name of the tool is Rietveld, and here is what Guido said on the Python mailing list to announce it:

I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google.

What I'm announcing now is the next best thing: an code review tool for use with Subversion, inspired by Mondrian and (soon to be) released as open source. Some of the code is even directly derived from Mondrian. Most of the code is new though, written using Django and running on Google App Engine.

I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out.

Brady Forrest has a nice write-up of the announcement and Joe Heck pointed out that this is not the same as another open source solution called Review Board.

For more details on the tool check out Guido's article.

Google Developer Podcast Episode 15: Google App Engine

By Dion Almaer, Google Developer Programs

Using iTunes?

We had the pleasure to talk to some of the Google App Engine team to discuss the recent launch that Dick uses the tagline as "Your apps, our servers". We get to chat with tech lead on the project Kevin Gibbs, product manager Pete Koomen, and Guido van Rossum. I don't think we need to introduce Guido!

The podcast starts out answering why Google App Engine was created, and why Python was chosen as the first language. We then hear about the work that goes into making a language hardened for the platform itself.

Of all of the APIs that we expose in the App Engine back-end, we feel that the Database API is probably the most foreign for the majority of developers. Many are used to the relational model for datastores, and our datastore is different. Kevin talks about these differences, and the ramifications that come with a schema-less store. We then delve into the practicalities of having libraries such as SQL Alchemy support GQL which is a functional subset of SQL.

What about lock-in? This was one of the big questions that came out of the community when we launched App Engine. You can see how open the team is to other solutions, and how they like seeing work such as AppDrop that shows how you can do this. The choice to make the SDK itself fully open source says a lot.

Guido discussed how the Python runtime is indeed the full language, but how some libraries are not there. He talks about the reasons behind the choices, which are mainly related to security. As time goes on more libraries that developers really need will make it into the system, often with equivalent implementations. Although a traditional file system doesn't make sense in the cloud, we could very well see a virtual file system implemented.

We go on to discuss a lot more, including:

• What restrictions are there for serving your applications?
• What Web frameworks are available?
• Can you develop Web services as well as Web applications? How about gadget and widget?
• What kind of traffic can be expect with the free accounts?
• Can I run these applications on my domain, and integrate with Google Apps?

If you want to see more of the team and play with App Engine, come by a hackathon when it get to your neck of the woods, or hear more at Google I/O.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).

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.