Future of the Web
Without a doubt, the biggest public goal of the Chrome team can be described as "making mobile web better." Making Chrome (in general but particularly on mobile) faster, more capable, and supporting apps that are well-designed and generally more "appy."
Which makes total sense. Web on the desktop is already pretty awesome, and getting awesome-er. And, as Sundar Pichai mentioned in the day one closing keynote, mobile is the first computing platform that's going to reach a majority of the human beings on the planet. That's not a small deal.
There are three main places web apps can suffer relative to their native cousins on mobile platforms: performance, capability, and distribution. Google is putting huge efforts into addressing the first two (I'll get to the third later).
Mobile Web Performance
First, performance. The magic number is 60 (or 16). Google is doing everything it can to get mobile web to 60fps, which gives you about 16ms per frame to do everything you need to do. It's hard to even enumerate all the different ways they're working on this. From speeding up paint to putting more workload into the GPU to providing flame charts (so cool!) in DevTools so you can figure out what causes that jank.
We all know that animating transform and opacity goes smoothly, and everything else goes terribly. Google thinks that's a bummer and wants to fix it. However, they warn that the rendering changes required are so fundamental that it may be difficult for other vendors to match. Expect that to play out over a few years.
Mobile Web Capability
I'm defining capability pretty loosely as "having the ability to easily build native-like experiences on mobile web." That includes things you'd expect (like push notifications) but also things you might not (like Polymer).
We've already one big step forward in this department: web applications are much closer to first-class citizens in Android L. Each tab gets its own place in the new app switcher. In addition, theme-color in combination with icons from the new app manifest make for a very attractive experience. While "Add to Homescreen" remains a somewhat buried and somewhat arcane practice today, speakers expressed an interest in surfacing that capability better in the future.
If a single technology was the talk of the summit, it would be ServiceWorker, and with good cause. If you haven't heard about or gotten excited about it yet, you should start! Like right now! It is seriously, majorly awesome. Jake Archibald's presentation from Perf Like a Pirate is a great introduction. In a nutshell, ServiceWorker gives you the power to program the network layer of the browser. It's a comprehensive low-level technology that can completely solve the offline problem. Offline is a big deal, it's one of the most defining features of native apps vs. web in today's climate. As Alex Russell put it in his talk: "It isn't an app if it doesn't run when you tap." Google is very excited about ServiceWorker, and it'll be shipping in Chrome stable around the end of the year.
Once ServiceWorker lands, it's only a short time later that we'll see Push Notifications in the browser (they use ServiceWorker to coordinate). This will mean that, with a simple permission opt-in, a website will be able to notify you days, weeks, or months after you visit it. With the growing importance (and interactive nature) of notifications on mobile platforms, it'll be great to see the web get to participate.
When you look at native apps on Android or iOS side by side (as was demonstrated in one presentation) they're remarkably similar in their use of common components. This isn't by accident: mobile vendors provide both UI guidelines and an SDK full of ready-to-use components for building interfaces. Web apps, organically evolved from simple documents, haven't had the same tools. Web Components and Polymer are Google's answer to that problem, a common SDK for modern web app development.
The big news out of the Dev Summit for Web Components is that Polymer now has a production roadmap. Polymer 0.8 is in a preview branch today and includes massive performance and payload improvements gained by streamlining for the most common cases. The heavyweight binding system will now be opt-in, making elements built with Polymer lighter weight and easier to integrate with other frameworks.
As Polymer lead Matt McNulty put it, Polymer started as an experiment, but the experiment is over. Polymer is already used by Salesforce and News Corp as well as dozens of internal Google projects. Polymer 0.9 will be considered production-worthy for those who can stand a bit of risk, and 1.0 will land mid-2015, signaling the true beginning of the Web Components era.
It's clear that Google cares deeply about improving the mobile web experience. Personally, I tend to believe that the native app pendulum has swung out about as far as it can, and in the next few years we'll start seeing it swing back toward web tech again.