 Hello, Irwin. Thank you for joining us today. My name is Sebastian Benz. I'm part of the AMP developer relations team. And my name is Nana Reisinghane, and I'm a product manager on the AMP project. We want to talk about the work we are doing on AMP to make web development less painful and developers more productive. Yeah, I'm incredibly excited. So let's dive right into it. So, Nana, we would be remiss if we talked about AMP and didn't talk about the impact of Google's recent announcement around the page experience ranking signal. Absolutely. So even before we can actually start talking about AMP and page experience, first let's just talk about what the announcement is. In May, the Google search team announced that they're going to measure how the page is experienced by the user, in addition to prior signals such as a page's usefulness. And this whole suite of measurements is called page experience. It uses Core Web Vitals, which the Chrome team announced earlier that month, and adds other pre-existing signals such as mobile friendliness, safe browsing, and HTTPS on top of it. And the great thing is that these metrics line up really well with AMP's design goals of making sure that users are getting a content forward experience and are able to consume content without having to download unnecessary resources or wait for unnecessary processing. OK, so how does AMP do against page experience? Good catch, actually. We did some analysis, and we saw that a majority of AMP pages actually already do pretty well against this criteria. This means that AMP is really living up to the intention of being a well-lit path to creating a great page experience. So you said that a majority of AMP pages meet the criteria, but not all? Yep. So in the cases where the AMP page doesn't perform well against the page experience criteria, we saw that they failed for reasons that were outside of AMP's control, such as overly large images being served on mobile devices or the server response time being too slow. That's a really interesting key aspect of page experience, that the core web vitals are measured from real user data. This means to improve your core web vitals, for example, it's a good idea to use a CDN to ensure that users around the world get your content delivered quickly. Yeah, and just like other libraries and frameworks, the AMP project will be monitoring these metrics closely and continue investing in AMP's performance via a performance working group. But more generally, it's really important to note that AMP will intend to reduce the ongoing effort needed to create pages that offer a great user experience. And we intend to do so by helping offload tasks and various such as browser compatibility, accessibility, JavaScript budgets, et cetera. At its core, AMP is a UI component library. Before using AMP, I often struggled with too much choice when it came to adding a new feature to a site. Having to decide whether to build my own carousel, which is a bad idea, or finding a suitable existing implementation could take a lot of time and energy. With AMP, you get a flexible, high quality UI component out of the box. And you can be sure that these perform well, are accessible, and play along well with each other. Recently, I talked to a developer from an agency which uses AMP for building most of their client's websites. They told me that one of their design interns had been able to build a fully interactive website for one of their clients without any JavaScript knowledge. I think that's fantastic and a great example for the value of a good UI component library. It makes it easy to get started for beginners and allows experienced developers to focus on creating new user experiences instead of bike-shading technical details. And that's exactly what we're focusing on in 2020. We want AMP to be a cost-effective and simple solution that allows developers to focus on their product and not worry about other things like performance, infrastructure, et cetera. And this is an effort that we're calling AMP as a service. The idea here is to use AMP as a turnkey solution to easily create and then maintain a great page experience and make developers more productive simultaneously. So what exactly do you intend to do? So the first thing that we really want to do is address the feedback that AMP developers have. And some of the top complaints that we've seen with AMP is, first, the need for custom JavaScript. And second, the fact that the inline CSS limit is too small at 50 kilobytes. Now, we address the need for custom JavaScript by adding AMP script, a component that allows you to add custom JavaScript to AMP to help fulfill any business-specific need that AMP doesn't solve. And if you want to hear more here, you should stay tuned because our colleagues Ben Morse and Crystal Lambert will be talking you through this in their talk titled Workerize.js. Now, with our CSS limit, the intention was to promote CSS hygiene. But we got feedback that the limit was too tight at 50 kilobytes. So we worked with the AMP community to understand what a reasonable CSS limit could be. And after working with plugin developers, news publishers, and e-commerce site creators, we realized that most interactive experiences could actually fit in within 75 kilobytes of CSS. And so that's what we made our new limit, 75 kilobytes. And this really seems to have hit the sweet spot. With the 50 kilobyte limit, I have from many developers that they've been struggling with keeping their CSS as below the limit. But I still have to hear from someone starting with the 75 kilobytes limit. Yeah, fingers crossed that this limit works. Now, aside from addressing feedback, we want to make developers more productive. We want to help them create and maintain performance sites as well. The problem usually wasn't with AMP itself, but that they had to maintain two versions of the pages, the canonical one and an additional one, AMP one. Yep, that's by far the largest problem that AMP developers have. The problem is even more acute if you have separate teams that are working on the AMP and mobile web experience, especially if they're in separate parts of the organization. To be honest, the AMP team itself advocated for paired AMP experiences when we got started. We saw it as an easy way to create AMP pages with the least amount of effort. But talking to developers over time has made us realize the amount of pain that can be associated with maintaining this dual code base and that this outweighs the initial gains of actually creating the AMP page quickly. And Google's page experience announcement is a great move for AMP developers in this regard. It allows development teams to really think about how they want to continue investing in AMP going forward. OK, so say I'm publishing paired AMP pages because I want to be in the Google Top Stories carousel. Should I continue doing this? So in that case, I would ask for you to consider the maintenance costs that you're incurring by having to maintain an AMP version of your code and a non-AMP version of your code. Now that you have the option to be flexible with your text app, you should be looking to pick a setup that allows all your web developers to be productive from day one. So you're telling those who are going the paired AMP route to completely drop AMP support? No, what we're telling them is to pick something that makes them the most productive. And this could be a number of things. Developers could pick experiences on their site that could actually benefit from AMP and only invest in AMP for those experiences. Or they could go fully AMP first across all their site if they actually believe that AMP is able to meet their needs. And we've gotten pretty positive feedback from developers who use AMP as their main library because they think that AMP makes them more productive. And this is what we see AMP's future as, a component library that helps developers be more productive. And this is why we're investing in allowing everyone to use AMP components even outside of AMP pages. It's an effort that we're calling Bento AMP. And we look forward to releasing it later this year. I'm really excited about this. Focusing on AMP as UI component library is a much healthier direction, in my opinion. And I'm very happy that we're making this move. Another area we are taking or learnings from AMP or making them available to a wider audience are server-side optimizations for AMP pages. At the beginning, AMP pages were mostly served from AMP caches. And these perform additional optimizations, enabling AMP's strong user experience. However, many developers started using AMP for building their whole website. In these cases, AMP pages are not served from a cache. And there's been room for improving AMP's loading performance. To address this, we created AMP Optimizer, a tool to bring AMP cache optimizations to publishers. For example, we use AMP Optimizer for the official AMP website, AMP.dev. And by using AMP Optimizer, we achieve the same performance as when the page is served from an AMP cache. And what I really like, AMP Optimizer fits really well into our idea of AMP as a service. It enables us to automate web development best practices. For example, the latest AMP Optimizer release added support for image source generation to make it easier to serve optimized images. Another example is JavaScript modules. The AMP project is soon going to start serving the AMP runtime components as JavaScript modules. And if you're using AMP Optimizer, you will automatically get the benefit of smaller runtime modules once this becomes available. That sounds so great. And I'm really excited about all the improvements that are coming to Optimizer. But what's the best way for developers to actually include AMP Optimizer? I mean, of course, you could include it normally in your build pipeline or your rendering pipeline. But ideally, you shouldn't have to think about how to get AMP Optimizer. Our goal is to make the integration seamless by integrating AMP Optimizer into existing frameworks and scene assessors. The NextJS integration is a great example for what a good AMP development experience can look like. NextJS has a special AMP mode that you enable via flag, and this will result in the generated page being valid AMP. The cool thing is that you can start using AMP components straight out of the box and you don't need to worry about the AMP boilerplate or importing AMP components. All of this is automatically added in the background by an Optimizer, which is integrated directly into NextJS. And the resulting editing experience is really nice. And it feels like web development from 30 years ago. And a great example for this is Axios. They recently launched their new site and it's completely built on AMP using NextJS. And they've been really happy with the experience. Another example for a CMS that has these features integrated is WordPress. Recently, the official AMP WordPress plugin started by publishing an optimized AMP by default. So this means if you built an AMP page using WordPress, you get the best serving performance for them. Wow, it's really exciting to see so many new experiences that are being built using AMP and in fact, AMP Optimizer. And I'm really hoping to see more. But that's it, that's our time, and that's our vision for 2020. The Google page experience announcement allows AMP to focus on what it does best. Be a UI component library that helps developers be more productive by helping them deploy web development best practices at scale. And if you want to read more about AMP's plans for 2020, please read our blog post at go.amp.dev.service. And with that, thank you for joining us. If you wanna learn more about AMP in general, you can visit amp.dev today. Thanks everyone. And we will also be hanging out in the chat to help answer your questions for a bit.