At Google, we're always working to make the web faster. The SPDY protocol, which is now the foundation of the upcoming HTTP 2.0 protocol, is a significant step forward. However, despite increasing bandwidth, round trip time (RTT)--which is ultimately bounded by the speed of light--is not decreasing, and will remain high on mobile networks for the foreseeable future. To continue improving network performance we need to decrease the number of round trips, something that is difficult with protocols that currently rely on the Transmission Control Protocol (TCP).

QUIC (Quick UDP Internet Connections) is an early-stage network protocol we are experimenting with that runs a stream multiplexing protocol over a new flavor of Transport Layer Security (TLS) on top of UDP instead of TCP. QUIC combines a carefully selected collection of techniques to reduce the number of round trips we need as we surf the Internet. You can learn more in the design document, but here are some of the highlights:

• High security similar to TLS
• Fast (often 0-RTT) connectivity similar to TLS Snapstart combined with TCP Fast Open
• Packet pacing to reduce packet loss
• Packet error correction to reduce retransmission latency
• UDP transport to avoid TCP head-of-line blocking
• A connection identifier to reduce reconnections for mobile clients
• A pluggable congestion control mechanism

We've been working on both a QUIC client implementation and prototype server implementation in the open source Chromium repository for the past few months. Early tests of UDP connectivity have been promising, but we have learned from past experience that real-world network conditions often differ considerably. Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY. Users shouldn't notice any difference--except hopefully a faster load time. If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards. 

You can learn more about QUIC in our FAQ. Our hope is that what we learn from QUIC will ultimately help us to deliver a much faster... er... QUICker Internet!

Posted by Jim Roskind, RTT Reduction Ranger, Google

Today's release of the Dart SDK and Editor is the first beta release, and contains performance and productivity improvements across the platform. This latest release helps Dart developers automate code evolution, produce smaller JavaScript code and deploy Dart web apps.

The Editor's analysis engine, responsible for reporting warnings and errors, is completely rewritten and is 20% faster at parsing and analyzing. Now, there’s no need to run all the unit tests just to discover a typo. The Dart Editor watches your back as you type.

In addition, Dart Editor makes it easier for developers to manage an evolving app. Some of the new features include:

• "Rename Library" refactoring
• "Convert Method to Getter" and "Convert Getter to Method" refactorings
• "Import Library" quick fix
• "Create Class" and "Create part" quick fixes

Code completion has also improved. For example, completion is now camelcase aware. Type iE and Dart Editor finds isEmpty.

Compiling Dart to JavaScript now results in smaller code. For example, some Dart programs that use reflection and HTML can compile to JavaScript that is 3.7x smaller than previous compilation sizes.

Dart VM performance has also improved. Compared against the previous release of Dart, DeltaBlue is 33% faster and Tracer is 40% faster. This release also includes full SIMD acceleration in Dart VM.

Finally, deploying a Dart web app is now easier, with the beta pub deploy command. It creates a directory with your app's code and assets and prepares it for hosting on your favorite web server. You can use this command from Dart Editor or the pub command-line utility.

That's just the highlights - there are more improvements across the platform. You can read the full release notes for more details and changes. You can download the latest version of Dart Editor, including everything you need for Dart development, from dartlang.org. We look forward to your feedback!

Dan Rubel
Productivity Enhancer, Dart Editor team

The main goal of the Chromium project has always been to help unlock the potential of the open web.  We work closely with the industry to standardize, implement and evangelize web technologies that help enable completely new types of experiences, and push the leading edge of the web platform forward.

But in 2009, many people were using browsers that lagged behind the leading edge. In order to reach the broadest base of users, developers often had to either build multiple versions of their applications or not use the new capabilities at all. We created Chrome Frame — a secure plug-in that brings a modern engine to old versions of Internet Explorer — to allow developers to bring better experiences to more users, even those who were unable to move to a more capable browser.

Today, most people are using modern browsers that support the majority of the latest web technologies. Better yet, the usage of legacy browsers is declining significantly and newer browsers stay up to date automatically, which means the leading edge has become mainstream.

Given these factors we’ve decided to retire Chrome Frame, and will cease support and updates for the product in January 2014. If you are a developer with an app that points users to Chrome Frame, please prompt visitors to upgrade to a modern browser. You can learn more about these changes in our FAQ.

If you’re an IT administrator you can give your employees the full capabilities of a modern browser today, even if you depend on older technology to run certain web apps. Check out Chrome for Business coupled with Legacy Browser Support, which allows employees to switch seamlessly between Chrome and another browser. Chrome is secure, stable and speedy, and runs on all major desktop and mobile OSs. IT admins can also configure 100+ policies to make Chrome fit their needs.

It’s unusual to build something and hope it eventually makes itself obsolete, but in this case we see the retirement of Chrome Frame as evidence of just how far the web has come.

Posted by Robert Shield, Google Chrome Engineer

Cube Slam is a Chrome Experiment built with WebRTC, an open web technology that lets you communicate in real-time in the browser (and in this case, play an old-school arcade game with your friends) without downloading and installing any plug-ins. In this post, we wanted to explain a bit about how Cube Slam works.

Cube Slam uses getUserMedia to access your webcam and microphone (with your permission, of course), RTCPeerConnection to stream your video to a friend, and RTCDataChannel to transfer the bits that keep the gameplay in sync. If you and your friend are behind firewalls, RTCPeerConnection uses a TURN relay server (hosted on Google Compute Engine) to make the connection. However, when there are no firewalls in the way, the entire game happens directly peer-to-peer, reducing latency for players and server costs for developers.


Cube Slam is the first large-scale application to use RTCDataChannel, which provides an API similar to WebSocket, but sends the data over the RTCPeerConnection peer-to-peer link. RTCDataChannel sends data securely, and supports an "unreliable" mode for cases where you want high performance but don't care about every single packet making it across the network. In cases like games where low delay often matters more than perfect delivery, this ensures that a single stray packet doesn't slow down the whole app.

RTCDataChannel supports unreliable mode in desktop Chrome today. We're working on implementing the latest WebRTC spec, where we'll use the standard SCTP protocol to support reliable mode as well. WebRTC will also be available on Chrome for Android later this year, and you can try it now by flipping “Enable WebRTC Android” in chrome://flags. Several browsers are currently working on implementing WebRTC, and we’re looking forward to the day when you can have a Cube Slam face-off against your friends on any browser and any device.

To learn more about the tech in Cube Slam, you can check out our technology page and source code. Disable the shields! Destroy the screen! Have fun!

Posted by Justin Uberti, Software Engineer and Channeler of Data

You may have seen our recent demo of Racer at Google I/O, and wondered how it was made. So today we wanted to share some of the web technologies that made this Chrome Experiment “street-legal” in a couple of months. Racer was built to show what’s possible on today’s mobile devices using an entirely in-browser experience. The goal was to create a touch-enabled experience that plays out across multiple screens (and speakers). Because it was built for the web, it doesn’t matter if you have a phone or a tablet running Android or iOS, everyone can jump right in and play.
Racer required two things: speedy pings and a consistent experience across screens. We delivered our minimal 2D vector drawings to each device’s HTML5 Canvas using the Paper.js vector library. Paper.js can handle the path math for our custom race track shapes without getting lapped. To eke out all the frame rate possible on such a large array of devices we rendered the cars as image sprites on a DOM layer above the Canvas, while positioning and rotating them using CSS3’s transform: matrix().

Racer’s sound experience is shared across multiple devices using the Web Audio API (available in latest iOS and Android M28 beta). Each device plays one slice of Giorgio Moroder’s symphony of sound—requiring five devices at once to hear his full composition. A constant ping from the server helps synchronize all device speakers allowing them to bump to one solid beat. Not only is the soundtrack divided across devices, it also reacts to each driver’s movements in real time—the accelerating, coasting, careening, and colliding rebalances the presence of every instrument.

To sync your phones or tablets, we use WebSockets, which enables rapid two-way communication between devices via a central server. WebSocket technology is just the start of what multi-device apps of the future might use. We’re looking forward to when WebRTC data channels—the next generation of speedy Web communication—is supported in the stable channel of Chrome for mobile. Then we’ll be able to deliver experiences like Racer with even lower ping times and without bouncing messages via a central server. Racer’s backend was built on the Google Cloud Platform using the same structure and web tools as another recent Chrome Experiment, Roll It.

To get an even more detailed peek under the hood, we just published two new case studies on our HTML5 Rocks site. Our friends at Plan8 wrote one about the sound engineering and Active Theory wrote one about the front-end build. You can also join the team at Active Theory for a Google Developers Live event this Thursday, June 13, 2013 at 3pm GMT for an in depth discussion.

Posted by Pete “Spinout“ LePage, Developer Advocate

Last week we launched Roll It, a Chrome Experiment that links phones to computers and gets people out of their chairs and swinging. We wanted to share how we built a physical game experience with no dedicated hardware. It requires just the web, your computer and a phone.

Here’s a look at the APIs and browser-based features we used to create it.


Roll It is a three-dimensional (3D) experience, from the swing of your phone’s accelerometer right up to the virtual models rendered on your computer’s HTML5 Canvas. On the phone side, we hooked into browser events like DeviceOrientation and DeviceMotion to detect the speed and direction of a swing. On the computer side we rendered our scene using Three.js and plugged in Physijs to add physics to the ball and environment.

To sync the phone to the computer we employed WebSockets which enable rapid two-way communication between devices via a central server.

For extra stability we built our backend on Google Cloud Platform:

• Our Google App Engine application, built in Go, dynamically balances users across our relay servers.
• A Google Compute Engine server maintains game state across synced devices.
• Google Cloud Storage speedily serves up the static assets.

We couldn’t have brought this experiment to life without a great team. The theme for Roll It was composed by Mr. Tim Healey. Legwork Studio developed the interfaces and game environment, and teamed up with Mode Set for the development.

To dig deeper into the technology behind Roll It, check out the HTML5 Rocks Case Study, or join the team for a Google Developers Live event this Friday, June 7, 2013 at 5pm GMT for an in-depth discussion.

Posted by Pete LePage, Developer Advocate and Boardwalk King