Google Chrome is a browser that combines a minimal design with sophisticated technology to make the web faster, safer, and easier.

To know more about Google Chrome, view the handy GoogleBook here, or read the transcript below!

----

Behind the Open Source Browser Project

Today, most of what we use the web for on a day-to-day basis aren't just web pages, they're applications.

People are watching and uploading videos, chatting with each other, playing web-based games... All these things that didn't exist when the first browsers were created.

Wouldn't it be great, then, to start from scratch, and design something based on the needs of today's web applications and today's users?

First, browsers need to be more stable. When you're writing an important email or editing a document, a browser crash is a big deal. Browsers also need to be faster. They need to start faster, load pages faster, and for web apps, javascript itself can be a lot faster.

They need to be more secure. Given what's known about mass browser exploits, browsers need architectural changes to disadvantage malware.

And we want browsers to find that sweet spot between too many features and too few, with a clean, simple, and efficient user interface.

Finally, Google Chrome is a fully open source browser. We want others to adopt ideas from us, just as we've adopted good ideas from others.

Stability, Testing and the Multi-Process Architecture

When we started this project, the gears guys were saying that one of the problems with browsers is that they're inherently single-threaded.

For example, once you have javascript executing, it's going to keep going, and the browser can't do anything else until javascript returns control to the browser.

So developers write APIs that are asynchronous, and every now and then the browser locks up because javascript is hung up on something.

The Gears guys were thinking about a multi-threaded browser, but that led us to talk about, well, instead of multiple threads, what if we have multiple processes? Each having it's own memory and it's own copy of the global data structures.
We're applying the same kind of process isolation you find in modern operating systems.
So, separate processes render separate tabs.

And now you have separate javascript threads as well. One tab can be busy, while you're still using all the others. And if there's a browser bug in the renderer (and our experience is that it's almost impossible to eliminate all bugs), we still only lose the one tab.

When one tab goes down, you get a 'sad tab', but it doesn't crash the whole browser.

A multi-process design means using a bit more memory up front. Each process has a fixed additional cost. But over time, it will also mean less memory bloat.

In a traditional browser, you only have one process and one address space that you keep loading web pages into. When you have too many tabs open, you can close some to free up memory. When you bring in another tab, you use the memory that was previously used.

But as time goes on, fragmentation results -- little bits of memory still get used even when a tab gets closed. Either we have memory that nothing can refer to again, or there's a piece of de-allocated memory we still have pointers to. So when the browser wants to open a new tab, it can't fit it in the existing space, and so the OS has to grow the browser's address space. And this problem grows all day, as the lifetime of the browser extends.

But when a tab is closed in Google Chrome, you're ending the whole process, and all that memory gets reclaimed. Open a new tab now, and you're starting from scratch.

So as you browse, we're creating and destroying processes all the time. If there's a crazy memory leak, it won't affect you for that long because you'll probably close the tab at some point and get that memory back.

And we're taking it one step further. Suppose you navigate from Domain A to Domain B. There's no need for any relationship between the two sites, so now we can throw away the old rendering engine, the old data structures, the old process. So even within a tab, we can be collecting and tossing out the garbage, recycling the whole process.

And just like with your OS, you can look under the hood with Google Chrome's Task Manager to see what sites are using the most memory, downloading the most bytes, and abusing your cpu. You can even see the plug-ins within the tab, since they appear in chrome's task manager as separate processes. So when things start freaking out, you'll finally have some insight into who's misbehaving and why, and eliminate 'em. Placing blame where blame belongs.

Google Chrome is a massive, complicated product that will need to load billions of different web pages, so testing is critical. Fortunately, here at Google, we have an equally massive infrastructure for crawling web pages. Within 20-30 minutes of each new browser build, we can test it on tens of thousands of different web pages. Each week, "Chrome Bot" tests millions of pages, giving our developers early results they'd otherwise have to wait until external beta for.

The key is catching problems as early as possible. It is less expensive and easier to fix them right away. After a few days, it is harder to track them down. And catching them early helps engineers write better code. They say, "Oh, this mistake is part of a pattern" and the next time, they're less likely to make it.

Of course, there are billions, maybe trillions of webpages out there. If each build is tested against a million sites, which million do we use? Fortunately, we have a unique take on this problem also. We already rank pages based on which pages the average user is most likely to visit. At the very least, we'll make sure we wont' be broken on the kinds of sites people use on a day-to-day basis.

There are several ways we test each check-in. From unit tests of individual pieces of code, to automated UI testing of scripted user actions like "Clicked back button... went to page...", to fuzz testing: sending your application random input.

In layout testing, Webkit found that producing a schematic of what the browser thinks it's displaying is a more precise way to compare layouts than taking screenshots and creating a cryptographic hash. When we started we were passing 23% of Webkit's layout tests. Moving from there to 99% has been a fun challenge and an interesting example of test-driven design.

There are limits to what we can do with automated testing. We can't test websites that require a password, for example. And it's not the same as a human being walking around and misusing things. We are using the browser in the way we've designed it to be used.

It's hard to cover 100%, but that's what we're trying to do. I don't care if there's one fewer cool feature. I just want this product to be rock solid.