WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001. Its flexibility, performance and thoughtful design made it the obvious choice for Chromium's rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the web platform’s growing capabilities since then.

However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.

This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.

In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.

Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.

To learn more about Blink visit our project page.

Posted by Adam Barth, Software Engineer

The Web Timing draft specification presents a standard set of metrics for measuring web page load time across browsers. We’re happy to announce that in Chrome 6, web developers can now access these new metrics under window.webkitPerformance.

Measuring web page load time is a notoriously tricky but important endeavor. One of the most common challenges is simply getting a true start time. Historically, the earliest a web page could reliably begin measurement is when the browser begins to parse an HTML document (by marking a start time in a <script> block at the top of the document).

Unfortunately, that is too late to include a significant portion of the time web surfers spend waiting for the page: much of the time is spent fetching the page from the web server. To address this shortcoming, some clever web developers work around the problem by storing the navigation start time in a cookie during the previous page’s onbeforeunload handler. However, this doesn’t work for the critical first page load which likely has a cold cache.

Web Timing now gives developers the ability to measure the true page load time by including the time to request, generate, and receive the HTML document. The timeline below illustrates the metrics it provides. The vertical line labeled "Legacy navigation started" is the earliest time a web page can reliably measure without Web Timing. In this case, instead of a misleading 80ms load time, it is now possible to see that the user actually experienced a 274ms time. Including this missing phase will make your measurements appear to increase. It’s not because pages are getting slower – we’re just getting a better view on where the time is actually being spent.

Across other browsers: Web Timing metrics are under window.msPerformance in the third platform preview of Internet Explorer 9 and work is underway to add window.mozPerformance to Firefox. The specification is still being finalized, so expect slight changes before the browser prefixes are dropped. If you’re running a supported browser, please try the Web Timing demonstration and send us feedback.

Posted by Tony Gentilcore, Software Engineer

Google is one of the Khronos member companies helping to develop the WebGL specification, bringing hardware accelerated 3D rendering to the web via the Canvas element. Today is the release of the initial public draft of the WebGL spec. We're happy to announce that Chromium contains provisional WebGL support on Linux (32- and 64-bit), Mac and Windows. This implementation was developed in close collaboration with Apple Computer and utilizes much shared code from WebKit.

See Getting a WebGL Implementation for instructions on getting a Chromium build and enabling WebGL support. This is an early version with many caveats, but with it you can get a taste of the new functionality coming to the web.

Here are a few demos to whet your appetite:

• San Angeles futuristic cityscape demo
• Shiny teapot demo illustrating compositing of 3D graphics with the web page
• Particle system demo showing how to use the GPU to animate particles

The WebGL wiki is the central location for information about the evolving specification, including the draft spec, introductory articles, tutorials, mailing lists and forums. See the WebGL demo repository for more demos and instructions on how to check out their source code.

We're looking forward to finalizing the WebGL specification and making this functionality available to web developers, and look forward to your feedback. For Chromium-specific questions, use the Chromium-dev mailing list, for more general WebGL questions, use the WebGL forums or WebGL public mailing list.

Posted by Ken Russell, Software Engineer

Starting in the Google Chrome developer channel release 4.0.249.0, Web Sockets are available and enabled by default. Web Sockets are "TCP for the Web," a next-generation bidirectional communication technology for web applications being standardized in part of Web Applications 1.0. We've implemented this feature as described in our design docs for WebKit and Chromium.

The Web Sockets API enables web applications to handle bidirectional communications with server-side process in a straightforward way. Developers have been using XMLHttpRequest ("XHR") for such purposes, but XHR makes developing web applications that communicate back and forth to the server unnecessarily complex. XHR is basically asynchronous HTTP, and because you need to use a tricky technique like long-hanging GET for sending data from the server to the browser, simple tasks rapidly become complex. As opposed to XMLHttpRequest, Web Sockets provide a real bidirectional communication channel in your browser. Once you get a Web Socket connection, you can send data from browser to server by calling a send() method, and receive data from server to browser by an onmessage event handler. A simple example is included below.

if ("WebSocket" in window) {
  var ws = new WebSocket("ws://example.com/service");
  ws.onopen = function() {
    // Web Socket is connected. You can send data by send() method.
    ws.send("message to send"); ....
  };
  ws.onmessage = function (evt) { var received_msg = evt.data; ... };
  ws.onclose = function() { // websocket is closed. };
} else {
  // the browser doesn't support WebSocket.
}

In addition to the new Web Sockets API, there is also a new protocol (the "web socket protocol") that the browser uses to communicate with servers. The protocol is not raw TCP because it needs to provide the browser's "same-origin" security model. It's also not HTTP because web socket traffic differers from HTTP's request-response model. Web socket communications using the new web socket protocol should use less bandwidth because, unlike a series of XHRs and hanging GETs, no headers are exchanged once the single connection has been established. To use this new API and protocol and take advantage of the simpler programming model and more efficient network traffic, you do need a new server implementation to communicate with — but don't worry. We also developed pywebsocket, which can be used as an Apache extension module, or can even be run as standalone server.

You can use Google Chrome and pywebsocket to start implementing Web Socket-enabled web applications now. We're more than happy to hear your feedback not only on our implementation, but also on API and/or protocol design. The protocol has not been completely locked down and is still in discussion in IETF, so we are especially grateful for any early adopter feedback.

Posted by Yuzo Fujishima (藤島 勇造), Fumitoshi Ukai (鵜飼 文敏), and Takeshi Yoshino (吉野 剛史), Software Engineers

We've introduced a new way for web developers to take advantage of Google Chrome's multi-process architecture, as of version 4.0.229.1. Google Chrome already uses separate OS processes to isolate independent tabs from each other in the browser, so that crashes or slowdowns in one tab won't affect the others. Google Chrome even switches a given tab's process if you type a different site's URL into the Omnibox.

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.

To cause a link to open in a separate process from your web page, just add rel="noreferrer" and target="_blank" as attributes to the <a> tag, and then point it at a URL on a different domain name. For example:

<a href="http://www.google.com" rel="noreferrer" target="_blank">Google</a>

In this case, Google Chrome knows that the page will be opened in a new window, that no referrer information will be passed to the new page, and that the window.opener value will be null in the new page. As a result, the two pages cannot script each other, so Chrome can load them in separate processes. Google Chrome will still keep same-site pages in the same process, to allow them to share caches and minimize overhead.

We hope you find this useful on your own sites!

Posted by Charlie Reis, Software Engineer