Today we launched Chrome 27 on the Beta channel. This release introduces smarter behind-the-scenes resource scheduling and a few new features for web developers. Unless otherwise noted, updates apply to desktop versions of Chrome and Chrome for Android.

Faster page loads

Web content now appears on screen 5% faster (on average) thanks to changes in Chrome’s resource scheduler. Starting with this release, the scheduler is more aggressive about using an idle connection and demoting the priority of preloaded resources so that they don’t interfere with critical assets. We’ve also added Speed Index values from webpagetest.org to the list of metrics we use to measure improvements in page load time.

Elegant HTML5 date and time <input> forms

The month, week, and date <input> types now feature a simple, elegant user interface on desktop versions of Chrome, as shown in these screenshots from the datalist demo page:

Live audio input to Web Audio API

Starting in today’s Beta, you can use live audio as input to the Web Audio API for extremely low-latency local audio manipulation and playback. When combined with the recent hook up of Web Audio and WebRTC PeerConnection, it enables analysis and manipulation of the input signal to WebRTC. For now this feature is only available on Mac and Windows.

Dock-to-right supports vertical split view, and you can now right-click resources in the Network tab to “Copy as cURL”. The network panel has been improved as well: you can now customize what columns are shown, including the new “domain” one. Finally, console messages can be filtered by source and impl-side painting events are properly displayed in the timeline.

Other web platform features in this release

Unprefixed support for the allowfullscreen attribute for <iframe> allows embedded video players like YouTube’s to go fullscreen.

The User-Agent field is now sent in WebSocket opening handshake headers.

The ch CSS unit can be used to match the width and spacing of the "0"-glyph in the current font.

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.