 Hi, everyone. I'm Kinko. I'm the tech lead of loading projects for the web platform in Chrome. And I'm Rudy. I'm the lead product manager for AMP at Google. This presentation is a developer preview of two upcoming APIs, web packaging and portals. With these APIs, we believe that you will be able to take that web flow friction nature to the next level and create zero friction user experiences. I hope you like it. Let's dive right into it. All right. So here's a slide showing a slide. To be more precise, this is one of those old school projector slides. In their day, slides like these were a useful way to communicate or held important memories for people. To view the slide's content, the projector needed to mechanically position it into place so that the light source would shine through it. And for those of you who might have watched one of these old school slideshows, you probably remember how tedious it was to progress through each slide. This kind of makes me feel like how we think about the web today, the same feeling. Just like progressing through cylinder slides, when you browse the web today, you can feel all the navigations. Today, the web is used a lot on the go, say in between meetings, in an elevator, or maybe you're on a poor connection. When I've got limited time focused on my phone before the next distraction comes along, spending five seconds or longer staring at a white screen, waiting for the content to come in, for the page to be interactive, that's incredibly noticeable. Many of you may have observed we use some exaggerated long transitions on our own slide so far in this talk. Don't worry, we're going to put an end to that soon. Those were just one-second fades. Think of how used to the cycle of reading and then waiting, reading and then waiting, that we've kind of grown used to. We think it's time to do better, and we have some ideas to help you create seamless zero-friction user experiences, and that's what this talk's all about. So our desire to see seamless user experience on the web, it's not new. In Chrome 13, back in 2011, we launched a feature called Instant Search, which provided such a blissful user experience. It did so by rendering the search results. It would use that with the most likely click on. However, the feature only worked in limited scenarios for various reasons, in particular, for privacy reason. It only worked for the search results the user had already visited, and for which we had high confidence of user interest. Then in 2015, another example of such user experience was launched. I'm talking about AMP. Rudy is going to walk us through what it took and where things are headed. So as Kunuku said, advancing the state of the art in page loading has always been of intense interest to us at Google and for Google Search. We point users to a whole lot of web pages. And thinking about the totality of the experience that the user gets, we really wanted to feel as fast and as seamless as possible, even as the user goes off of search and into the whole great world of content that they're looking to explore. When we started AMP, we were intent on using the full power of the web platform that was available. But where we wanted to get was here, and we felt that what we could achieve on a scalable way on the web kind of just got us up to here. So we gave it a bunch of thought and came up with an architecture for instant loading that could work on today's web. It's still what we use today. First, there's the AMP JavaScript library. It helps to ensure that the experience is fast by default. And this is enforced by a validation step, which helps keep the experience fast even as the site is getting updated. The next layer was thinking about how server response times can vary a lot globally. And not every site is situated on great infrastructure. Also, as we've seen earlier, sticking huge images into pages intended for mobile viewing is still pretty common. And so for these reasons, we added the second layer of caching, where we can ensure that the content is pushed to the edges of the network for faster delivery, and we can do common sense optimizations. And last, truly the best thing we can do to get load times down to 0 milliseconds is to pre-render the content, use our psychic powers. As we just discussed, this was attempted in search before with Instant Search. However, you need to think really carefully about the privacy implications of such a design. And we had trouble scaling it. The cache will actually help us complement this pre-rendering very well. And Kanuka will explain more about that in a moment. So we got all of this stood up, and this is where we ended up. Most of what you're looking at here is what we call the AMP Viewer. That's the page you're visiting. It's responsible for displaying the content, served through the AMP cache for speed and privacy reasons. However, you'll notice by looking at the address bar that the URL is still saying Google.com in it. To help the user understand where the content they're viewing came from, we had to add an extra piece of UX to the top of the content area of the page. The idea of the instant loading was achieved, but the design constraints that we faced and the workarounds that we had to build for them ended up being put on full display in the product experience, and that wasn't great. So we hear a bunch of feedback on this, maybe even from some of you. So earlier this year, we started down this path to make the URLs for AMP pages better. And after having AMP in the wild for two years, we decided it was time to take all that we had learned and develop the necessary primitives in the web platform directly so we could make all the content across the web be able to benefit from this kind of technology. So this means that for the cases where you click on a link and search, and it's just a simple navigation, then we want the publisher's URL to be the one that shows up in the browser's address bar, while still having the instant or nearly instant loading experience. So I already talked a lot about how AMP has been pushing the goal of highly optimized user experience. There was a lot of special handling required because of the gap in the web platform. We are now taking inspiration from past efforts like AMP and the Instant Search and trying to eliminate this gap by extending the web platform. And by doing so, we also want to enable this zero friction user experience across all content on the web. We are working on multiple proposals to achieve this goal. But in this talk, we'll introduce two new primitives, web packaging and the portal. So let me start with web packaging. As the name implies, it's meant for packaging a piece of web content. We think we can enable various interesting use cases, but let me start first explaining how it can help instant navigations, both for AMP and non-AMP content. So stepping back, we've long wanted to make web content load instantly and reliably. Here's why it's hard. When you publish something on the web, in the simple setting, you'd have a server. And your content would be a project there. Then someone brought it to your content, but the server might be overloaded. And your content will load slowly. Then the experience is not good. So what could we do to improve this? One way would be to pre-fit your content. Suppose that your content is linked from a popular traffic source site. When a user visits the site, it can trigger a pre-fit when it thinks that the user is about to visit your content. Then, because the content is already in the user's cache, the navigation happens very fast. Unfortunately, the pre-fitted website can learn about the user's interest, even if they don't visit the website. One way to fix this would be for the referral site to add a cache here. Then the referral site could bootstrap your page load in a privacy-preserving manner, because it could let the browser pre-fit your content from this cache. This fix the privacy concern and the content load instantly. So is this the holy grail? No, not yet. As Ruti explained, this design is in full display in the product. The browser's address page shows the URL of the referral site instead of URLs, because this is where the browser thinks the content is coming from. This is confusing to the users. The issue is that the web platform doesn't provide a proper way to let others bootstrap your page loads. But what if your render-critical resources could be shared with popular traffic sources and were loaded on your behalf? This would let traffic sources bootstrap your page loads. And when the user navigates, it's just a regular page load from your servers only much faster. So how can we achieve this? The browser needs a way to verify the two original resources that are served by a fast cache. This can be done by adding a proof of origin on these resources, which is exactly what web packaging provides. So let's see the actual standard proposals. Web packaging is not the name of a single proposal, but an umbrella concept for multiple-spec proposals. The most important one is the sign exchange. It's basically a format that represents a single HTTP exchange or a pair of HTTP request response. Very simple, except that it's digitally signed so that the browser can verify the original resource. There's another proposal, building on top of sign exchange, called bundled exchange. This is a bundle of exchanges. Therefore, it can represent multiple resources in one package, like a whole web page. We think that bundled exchange will enable other interesting use cases, while we started with the sign exchange, since that's the key building block. And after a year of work, we're pleased to announce that we're starting an on-prem experiment of the future on Chrome 71, which is in beta now. You can play locally with it by enabling a flag or can join the experiment to enable it on your site. Please visit bit.ly-slash-try-hyphen.sxt to find out how. We'd love to get your feedback on this. That will help us improve this feature more quickly. So in order to create and publish signed exchanges for your resources, you need to first acquire a certificate that can sign exchanges. And host it at the public URL. Such a certificate can be created at Digisat today. Once you do that, you can generate signed exchanges for your resources by using an open source tool. This process is fairly manual, but we'll talk about easy options later in this talk. So the origin trial process is needed for sites that are going to link to signed exchange content. That could be your own site, but it also includes platforms like Google.com. So we've gone ahead and enrolled Google.com in the signed exchange origin trial, and we'd now like to show you a demo of using signed exchanges for delivering AMP content from Google Search. To walk you through it, please join me in welcoming us to the stage Sumo from 1-800-FLOWERS and Rustam from Cloudflare. Cool. Hey, thanks, Rudy. AMP has provided a prominent pathway for user discovery of results and brands. It could use a closer gap between discovery and speed to engage in thanks to an active developer community and thanks to a rollout of new web components. Web packaging further deepens the experience of providing a native UI while serving the benefits from the AMP cache. Today, we're excited to demo an example of web packaging live. Are you ready? Check it out. Let's search Christmas greens. Here we are. So notice, in the search result, there's an AMP badge. So it's prominently featured. So you note instantly that this is an AMP search unit. I click on it or tap on it. And instantly, as Rudy is mentioning, you see that there's no Google in the URL, which is pretty key over here, because now you instantly feel that you're natively on the website versus being on a separate cache. Importantly enough, you also see that there's no view ahead of. So it adds further to the prominence that you are actually on, in this case, when you have flowers.com. Furthermore, having attribution so seamless, it just adds to a much more confident realization for a lot of brands that now there will be absolutely wonderful attribution going from the SERP to the native site. And a big shout out, really, to the AMP team and to the Google mobile consultants team, who really have been pushing the boundaries of UI, UX, and Huntsman on really making sure that the web is taking all the strides possible to go to the next level. Rustam, you want to go through how this works? Sure. Thanks, Jamal. Cheers. So let's look under the covers and talk about how you would actually deploy something to support signed exchange. So at the top here, in green, we have the request flow from your origin through a front end proxy to your user's device. On the bottom, you have the request flow into the AMP cache. And in between, you have an AMP Packager. This prepares the documents for the cache and signs them to support signed exchange. Now, at Cloudflare, we sat down and thought about how to use our global programmable network to make this all simpler. And this is what we ended up with. We took all the logic necessary to support signed exchange and built it into a Cloudflare worker. This sits at our edge and supports both the cryptographic operations, the packaging operations, and the logic necessary to arbitrate between the user and AMP cache request flows. So you might be asking, what's a worker? And simply put, it's V8 running on the edge. This allows you to write JavaScript, targeting the server's worker's API, deploy it to our edge, and have it running instantly in 155 locations. Supporting signed exchange and this packaging experience is a great example of what workers is capable of. So in addition to releasing the code that supports this demo so that you can all build your own workers to try signed exchange, we also plan on building a full-fledged Cloudflare feature to support it at launch. Cool. Back to Rudy. All right. Thank you, Sumo and Rustam. So if you're publishing AMP content, we'd like to invite you to try out a developer preview of signed exchange AMP content in Search using the instructions that the link up on the slide, g.co. slash web package preview. You can learn more about creating packages and building an end-to-end flow like you just saw for your own AMP content. Thanks, lady. So we've seen the benefits that signed exchange bring to AMP publishers. But it's important not to forget that this will also benefit all pages on the web too. Now I want to show an additional example, a regular cross-page navigation on the flow network. The content will load slowly. On the other hand, the right side shows how it can be done with a prefetch with web packaging. You can see that the user is navigating to a page on a different site instantly. The prefetch is down from the cache of the referral site. So therefore, down in the privacy-preserving manner. So publishing how to use web packaging to realize the privacy-preserving instant navigations. But you know, we're still doing navigations, right? So it still feels like we are progressing through pages as a disjoint experience, not a nice seamless experience. And we've been wondering how it could improve this even further. And let me introduce our latest proposal, Portals. So let's see what we mean by navigation versus transition. Maybe it's not too surprising. Again, this shows a regular navigation. This loads slowly, depending on connectivity, and the brakes use the flow. And the right side shows an example of a transition. As you can see, when the user taps on the article, a nice and smooth animation triggered, creating a sense of continuity. The navigation just happened without being felt. The navigation is so subtle that it's worth taking a closer look. As you can be seen from the address bar, the user starts their journey from a page on feed.greed.me. And when the animation is finished, the user ends on another website, news.holler.jp. So it's a cross-site transition. Combining Portals and the signed exchanges enables these types of user experience while preserving the user's privacy. You might not be interested in it, but Portals are now limited to cross-website navigation. Let's take a look at how it can improve the user experience of a single website built with multiple-page architecture. I'd like to thank Hatena YoungJump Webcomics, our partners in Japan, whom we've worked with to create this early exploration for their reading manga on the go website, called Tonari no YoungJump. So let's see the user experience without Portals. When you reach the end of the chapter, you see an Insta-Style page. As you can see, it takes time to load the next chapter. That's because the website is using multiple-page architecture, and it needs to load a new page for each chapter. Now, let's see how that could look like with Portals. At the end of the chapter, we can preload the next chapter and make the transition seamless. Pretty cool, right? The beauty of this is that you can achieve this smooth user experience. Without having to re-architect your website into a single-page app, which is, as you know, a non-trivial amount of work. So what are Portals? Portals are like iframes. You can create one as an embedded element of a page using a portal tag. At this point, it looks pretty much the same as an iframe, and then navigate to an element by calling an Activate API. When that API is called, the element is detached from the page and becomes the new top-level page. You can also add animation to smooth out the transition. So what are the differences between Portals and iframes? The biggest difference is that Portals can be navigated into. Another interesting difference is that Portals are always created as top-level browsing context, while they can still be embedded in a page like iframes. Let's recap the benefits. Portals enable seamless page transitions like what you get with single-page apps but without having to re-architect your site, and even across different origins. So you can just build your website using multiple pages and can connect them with Portals. So here's the example called snippet of Portals. You can create a portal as an HTML element, and then can append it to the page to have it embedded. Then when the user touches the embedded portal, you can show a nice animation and cause activated API to make the actual transition. That's it. Exciting, isn't it? And you probably want to know the current status. We have an explainer on the GitHub, visit between Portals-Spec to learn more. Chrome implementation is in progress. We are aiming for an origin trial next year and eagerly awaiting your feedback that will help us refine this proposal. So that's basically all from us about low friction to zero friction, but I have one more topic, bundled exchanges. So remember that we hinted that bundled exchanges earlier. They allow multiple resources to be bundled in one package, and you might be wondering if about the current status of development. So while the Chrome team has started building a prototype to explore the possibilities, we think this could enable interesting use-cases scenarios like offline PWA installation and much more. Here's an example of a newsreader PWA. This is based on TOYDEM readup built by one of our awesome developer folks, and now runs on a custom Chrome build to use bundled exchanges. The app allows the user to read news articles in a reliable way by letting its service worker download and save the articles as bundled. If the news sites provide them so that the user can later read the saved articles from multiple sites, even while offline. Note that the articles are still shown as coming from the original news sites, and the sites keep maintaining the control over them. Here's another example. As you may know, loading a large number of resources costly and bundling them in one big JavaScript file using bundled like Wepac is a very popular technique. We did an experiment to see if bundled exchanges can be used there, which could allow the browser to process and cache individual resources in the bundle without executing the JavaScript. And one of the results looked like this while still preliminary. It looks promising. We think there's some potential. And we want to know what you think. All right, so let's go back to the main topic and wrap up this talk. So we talked about two new proposals for zero-friction user experiences. First, web packaging enables privacy-preserving instant navigations. And second, portals enable seamless transitions between pages or sites. Combined together, two enable zero-friction page transitions on top of any web pages, even across origins. And here's a look at our roadmap. Appliance to ship-signed exchanges are unstable by the middle of 2019 and also to start an origin trial for portals. Some time around then as well. And so for Google Search, we're really excited about both signed exchanges and portals as a path to building more zero-friction user experiences across the whole web. Following the footsteps of the demo you just saw earlier in AMP, we'd like to launch support for AMP signed exchanges next year. We're also actively working on how non-AMP pages can adopt these same technologies for highly optimized user experiences. We believe that the old inventory just have a highly optimized content on the web regardless of whether it's AMP or not with all the standard work we are doing today. And we've been engaging various partners as well as other browser vendors because we want to refine what we have. And we want to make sure that it will help them and the developers like you achieve highly optimized user experiences. For instance, such teams as Bing, Yahoo Japan, Biden and Google, content publishers and web developers at 1-800-Flowers, Hatena, YoungJump web comics, CDNs and certificate authorities such as Digisat and Cloudflare, as well as folks working on the decentralized web at protocol labs. We hugely rely on your feedback and are eagerly awaiting to hear what you think. Here are the important links that we referenced and that you can check out to learn more and share your opinion and give us input. You can also come to the Ask Chrome area in the next break and we'll be there to answer your questions. We're really excited about the future of the web and enabling the kinds of experiences that we showed today and we'll appreciate your help in joining us to move these technologies forward. Thank you.