What Google Chrome Already Means to the Web

Nearly everyone was surprised (not shocked, but surprised) over the weekend to find out that Google had been building its own browser for months now, named Chrome, slated for release today. The goal was ostensibly to rethink the typical web browser and build a new one from scratch designed to cater to the current and future generation of the web. No, that doesn't mean Web 3.0, and two demerits for even thinking that term. To communicate these changes, they even released a comic book to explain the thought process behind the features and system design.

When I heard about it, I immediately was biased against the success of any product called Chrome. Chrome is the part of the web browser that doesn't change -- the address bar, the back button, etc. In doing UI and UX work, I'd adopted the term "chrome" to refer to the seldom-changing part of the site that users are trained to gloss past, such as the header, the nav, etc. So immediately, in addition to trying to steal someone else's market, they're stealing valuable terms from my lexicon. Nevertheless, it's high time someone else with some weight got into the browser game, and I was excited to see what Google and its all-star cast could do.

When Google moves into an established space with a completely new product offering, you know they're not messing around, and Chrome definitely deserves to be taken seriously. Even its announcement has already started to change the way we think about the web. Here's how:

Performance

It's easy to see that one of Google's main motivations behind the Chrome project was performance. Google's web apps are some of the most demanding on the web, loading up on all sorts of DOM scripting to make their apps familiar and easy to use. As they push their apps, they are also pushing the limits of the web browsers most of us use, which tend to have relatively poorly-performing javascript engines.

UXers should know by now that performance is critical to the user experience. Users would rather use a site that is responsive than one that isn't, even if the former case requires more clicks or even more time. Google wanted to make sure that dragging 500 messages from folder to folder in Gmail would be as smooth as doing it in Thunderbird (I would have said Outlook, but...). So, rather than borrow from other projects, they went ahead and wrote an entire JS parser from scratch.

Not only does the new engine interpret JS, but it compiles it into binary just like a typical language like C would be compiled. Compiled code is far faster than interpreted code the second time around, so for apps like Gmail or Google Maps, which use many of the same functions over and over again, this should be like lightning in a tarball.

Additionally, Chrome has a panel that allows you to see which tabs are consuming memory and CPU cycles excessively. This is the first significant time that individual sites have been held accountable for the performance of the browser. Since we all complain about how browsers slow down after use, and we typically blame the browser, now we'll start blaming inefficiently-written apps for hogging up our memory and our processors.

Until recently (until this weekend for many), web designers and developers haven't been paying too much attention to the performance of their sites' front-end. Sure, they didn't want it to beachball, but it was taken as a matter of fact that drag and drop actions would tend to be a bit sluggish. Now that they're accountable, I expect this to change sooner rather than later.

And if you were one of those who worried about performance, the potential success of Chrome could give you back a number of UI tools that you'd tossed aside for lack of acceptable performance and responsiveness.

Here at Viget, we've been paying attention to this for a while now, and have been focusing on performance both at the javascript and CSS levels, writing script and code that takes advantage of the way browsers read the page, seeking to provide a more responsive UI for the user. We're not yet quite where we one day hope to be, but we're getting closer.

Sites Become Apps

Not only does Chrome display a panel that handles tabs like your process manager handles application processes, but it actually does handle tabs as separate processes. In the short term, this means that each tab takes up a fairly significant amount of resources, as each has its own rendering engine instance, javascript engine, etc. As the browser is used, though, the separation of processes means a few things:

• A crash in one tab shouldn't take down the whole browser.
• A memory leak in one tab is cleaned up when you close it.
• Tabs operate in their own sandboxes, keeping out of the affairs of other tabs.

Chrome has a number of other niceties, such as a solid API and proper garbage collection, that makes the browser more like an application platform. It treats a web site like your operating system treats an application, and even the UI gets out of the way, eschewing common UI elements like the status bar.

With all these changes, your web apps are going to start feeling a lot less like web sites and a lot more like normal applications. Now you need to make sure they actually act like applications.

Advanced Standards Compliance

Chrome is based on Apple's WebKit rendering engine, which is what is used in Safari, on the iPhone, and on Google's Android mobile platform.

Unlike IE and even Firefox's Gecko engine, WebKit is at the forefront of standards adherence. Not only does WebKit properly parse CSS2 properties, but it also handles an ever-increasing number of CSS3 properties, such as corner radii, drop shadows, columns, and much more. That means fewer images to fake effects, and yes, therefore more responsive page loads.

Contextual UI

Remember how I mentioned that they got rid of the status bar? They replaced it with a bubble that appears when necessary. They did that with a number of things, offering users the tools they need only when they need them, eliminating clutter from the UI at other times. As webapps feel more like real apps, this is something we can take away: not everything needs to be there all the time. Consider displaying only the parts of the app relevant to the user at any given time, and you might find your app feeling simpler, easier, and more responsive as a result.

Performance is a Big Part of UX

The twitterverse had a lot of folks claiming that Chrome is simply a performance play, and not a UX or UI play. Sure, its UI isn't dramatically game-changing, but that doesn't mean users will experience the web the same way. Just like Firefox's success came from showing that features and bloat don't seal the deal, Chrome is taking it yet a step further and focusing on providing a great user experience through a very fast and responsive interface.

It's all kinds of design, from system design, to product design, to UI design, to visual design working for each other to create a package that masks its incredible complexity in simplicity. It's a big deal, but it plays it off like it's no big deal, and that's awesome.