Google Chrome Process Manager

About the just-leaked Google Chrome browser:

Google also say they’re using a “multi-process design” which they say means “a bit more memory up front” but over time also “less memory bloat.” When web pages or plug-ins do use a lot of memory, you can spot them in Chrome’s task manager, “placing blame where blame belongs.”

If this is true and there’s a process manager which allows you to see how many resources are being consumed by a particular browser tab (including plugins!) this will be a 100% killer browser feature.

It simply isn’t possible to implement with current browser architectures which brings up two points: 1) Browsers haven’t tackled it due to the extreme amount of code rewrite that it would cause and 2) that there’s a general consensus that this architecture will actually consume more resources than the current architectures.

This is important. Since there’s no sharing going on between the tabs of the browser it’s not possible to easily reduce the amount of duplicate resources. For example, within the Mozilla Gecko engine there’s a lot of code reuse occurring, which allows for significantly reduced memory consumption (and optimized memory collection and defragmentation).

But here’s the rub.

The blame of bad performance or memory consumption no longer lies with the browser but with the site.

By implementing this feature a browser is completely deflecting all memory or performance criticism off to individual site owners (“Yikes, my browser is using 300MB of memory! Actually it’s just youtube.com consuming 290MB of it, they should fix their web site!”). This is going to be a monumental shift in the responsibilities of web developers – and one that will serve the web better, as a whole.

Of course there will still be overhead associated with the core browser – but, presumably, this will be marginalized.

This is an incredibly devious (in the best sense of the word) tactic and it’s one that browser vendors will be forced to respond to. How the response will occur is another matter entirely.

Once the response occurs, though, two things will happen: Browsers will begin to compete on reducing specific memory/performance numbers for specific sites (it happens now – but with the numbers made obvious users will beg for it) and browsers will be enticed to lie.

Since the browser is the new harbinger of the de-facto “accurate performance metrics” (it’s no longer the Window Process Manager, for example) they’ll have to take every opportunity to exaggerate those number to their benefit.

On so many levels this new feature will change the way browsers are constructed and how they communicate to the user. Even if Google Chrome launch does nothing but fall off the end of the runway in a fiery explosion, users will be intrigued, and the seed will be planted: Browsers must find a way to respond.

Update: A screenshot has been posted showing the task manager:

It’s quite small (and, seemingly, quite spartan) but it appears to detail three properties of every tab: CPU usage, memory usage, and network usage.

It’s going to be fascinating to see what type of user-centric UIs come around this. Tabs that use a lot of CPU turn red? if they consume a lot of memory they grow larger? It seems like there’s a bunch of ways in which the quality of the tabs could be appropriately communicated.

Posted: September 1st, 2008


Subscribe for email updates

105 Comments (Show Comments)



Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.


Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.