Home page » Software

Search:

Refine search for Software

I think it’s safe for me to say that Google Chrome, the company's newly-released web browser, took pretty much everyone by surprise when it was launched a couple of weeks ago now. In an industry that seems to live on leaks and rumours, a company of Google's size keeping a project of Chrome's scale under wraps is a commendable achievement. Having had a while to play with, and learn about Chrome, now, it seems a prudent time to pass on a few thoughts and observations about Google's browser.

That Google has decided to make a web browser isn't really that strange an idea. Discounting such programs as Google Desktop, Google Chat and Google Earth, Google lives on the Internet and, therefore, in our browsers. No matter what Google does on its server side, as long as it can't control how its users interact with those servers, it will never be able to fully optimise its services. Chrome then is, in theory, the browser that a website admin would build, given the chance.

Under its rather shiny skin, Chrome runs using the same Webkit rendering engine as Apple's Safari (including iPhone/iPod touch flavour Safari) and Google's Android mobile platform does. According to the development team, this decision was made for two main reasons: not only is Webkit pretty darned fast and efficient, but it is also open source, just like Google wanted Chrome to be.

The rendering engine is a pretty small part of what makes a browser, though and Chrome isn't 'just another Webkit-using browser' - far from it. The most fundamental change Google made is what separates Chrome from any other browser out there, specifically the way Chrome splits each browser window, or tab into its own separate process, all managed by a lightweight 'browser' process. Chrome has a built-in process manager for monitoring all of these processes, away from the clutter of Windows' own Task Manager.

---

---

That may not sound particularly groundbreaking, but the implications are actually quite huge. Probably the biggest benefit of this is Chrome's sandboxing ability. Each page is separate not only from every other page, but also from the operating system. If a web page wants to interact with the OS in any way, it has to send that request via the control process, which monitors for suspicious or 'dangerous' activity.

Another of the benefits of using separate processes for each page is one that anyone using a browser regularly will definitely appreciate. If a page breaks in Chrome, it won't - can't - take the browser with it, so although you will have to reopen that tab or window, you won't have lost anything else you doing in every other tab or window. Incidentally Chrome also allows dragging tabs apart, to create separate windows, or vice versa - although it's a trick others have done before, it's good to see it redone here.

Yet another benefit to this type of processing is that it makes Chrome much better at handling memory than other browsers. In a traditional browser architecture, memory is allocated to a single process depending on how much each web page open at any one time needs. When pages are closed the browser should relinquish the memory that is no longer needed to the OS again for further use. Every now and again, though small pieces of that memory get 'fragmented' - lost in the system you could say. Over time, these small bits of fragmented memory - which now can't be used by anything - add up to a lot.

Chrome's processing architecture, however, means that when a page is closed, so is the process governing it and all the memory it was using is relinquished. Google admits that in some situations this can be a bit memory inefficient as memory isn't shared between multiple page instances (two reviews open on TrustedReviews for example), but the benefits outweigh the deficits.

Add your comment

© 2003-2009 TrustedReviews | About Us | Contact Us | Legal | Privacy | RSS