 Hello, hello, hello, hello. Yeah, it's so good to be here. So this is my first work on speaking. And for some reason, it feels home. So I'm here today with Thierry from XWP. And we want to talk about this idea of progressive web development in general and progressive WordPress in particular. But before, I would like to start by answering an important question that was asked yesterday. And so what is Google doing here? So at Google, we truly care deeply about the long-term health and evolution of the web. So we work on the core technologies and the standards of power of the web platform. We develop and maintain the Chrome browser that is used by more than a billion users. And we also build tooling and frameworks to enable developers to build amazing user experiences. So it should not be a surprise that we also care about a platform that powers a third of the web and a platform that philosophy is democratizing web publishing. And that is you guys. It's WordPress. However, we believe that democratizing web publishing is not possible if you don't democratize as well performance and the ability to create awesome user experiences. So the reason why we are here and the reason why we are committed to contribute with the WordPress ecosystem is because we believe that your goals and our goals are very well aligned and that if we team up and we work together, we are going to work faster to achieve our individual goals and our collective goals. So now, not talking as a Googler, but from a personal standpoint, I truly hope that all these rumors of acquisitions and this idea that Google is an evil corporation, I hope that that one day that it's going to disappear and we are going to understand that we are partners. We want the same thing. We all love the web and we should and we must work together to make this happen. OK, so having said that, I'm sure that you have heard the word progressive before. It's usually there's a lot of buzz about progressive web apps. There are nothing else that websites or web applications that are developed using modern web APIs. It's also very often used in the context of progressive enhancements. That brings about this idea that you can develop and incorporate these modern web APIs and features to your apps in a step-by-step way rather than all at once. In the context of this work that we have been working for the last year, we use the term progressive in the context of progressive web development. That is defined as the development of user-first web experiences using modern web APIs, coding, and performance best practices. And the key part of this definition is user-first, which means that at the center of progressive web development is user experience. So let's start at the core. What is user experience? User experience has to do with the emotions that users get when they go to our apps. In the context of what we are doing is our sites, our WordPress sites. So it's all about how they feel. So the next question is, what are applications or what is entailed in applications that users love? So there are four main pillars that are sort of patterns in applications that tend to be classified as delightful. So I call it the four pillars of a delightful UI. Users, and when I say this, I reflect a lot what I like as a user. It's like users like applications that are fast and reliable. They load quickly, consistently, even if the underlying network is flaky, which is very common in cellular networks, in an energy market, and so on. Users like applications that are secure. I like to feel safe when I give my data or I do transactions. I want to see now everything's going to be OK. Users also like applications that feel integrated with your mobile device because you can take advantage of all the goodies of the phone that you have. And users like applications that are engaging. So users like to feel that kick of wanting to go back to the application. And the application makes it easy for them to go back. So keep in mind these pillars of a delightful UI. So the next question is, what does it take to build applications like this in the web? So for a long time, the main power of the web resided in the hyperlinking capabilities that they have, the URL model. So it's very powerful still today. It's one of the main things for the web. But historically, when you compare the web platform to close platforms, like those for building native app, for example, the web lag behind in the kind of things that you could do with it, the good news is that the web has been evolving rapidly and steadily and is evolving as we speak. And nowadays, it is possible to build applications with the four pillars of the delightful user experiences totally in the web. So this here is a, I should use this, right? Yeah. So this here is a little bit glorious in my eyes. Anyway, so it's a subset of the APIs that are standard today in the web. And with them, we can do tons of things from accessing the device features. For example, you can actually get the vibration signals or the gyroscope. You can implement native-like features like offline access and things like that. Even virtual reality and augmented reality are a thing in the web today. So it's a lot of power that is right now in the web platform. And on top of that, then we have a lot of modern development workflows. We have frameworks that are super powerful and allow us then to get higher levels of attraction and build even more awesome user experience, right? And on top of this pyramid of power is you, right? The developer that said, yeah, I got this. I'm going to do superb things with this. The problem is that there is so much complexity nowadays to do things that we have seen that as the power of the web has increased, we also have seen a dramatic increase in what I would like to call the capabilities usage gap. That is nothing else than the difference between what can be done and what is done. It's very big. So let's suppose that many of you probably in 1999 were not doing web development, but it was a time where web development was very simple. You just have to learn HTML, see a sense a little bit, and you have one form factor, right, the desktop. Now we are here in 2018. We have that pyramid of power. We have frameworks. We have built workflows. Jesus, so many things that no wonder that a lot of the things that can be done, I cannot do them, right? So if we're to our reality right now, OK, I have to spend a few months trying to do it. So and the problem is that I said that awesome application can't be built in the web, but you need to use the capabilities of the way to do that. So if we don't do it, you cannot get the experience that you want. There is a lot of studies and data that we have seen and other people also have measured that that lack of the capabilities usage gap is reflected in things like applications that are very sluggish, that are heavy. They take like, you know, the average, you know, web app or website takes 19 seconds to load on 3G. And guess what? Most people access the network on 3G and a lot of people in worse networks than that. 75% of mobile sites take 10 or more seconds to load. That is terrifying, right? So that is the reality that we are facing. And this is what I say, that this is a problem for all of us. So either we solve this together or it's not going to be solved. And also, there are then usability problems, right? I'm sure that you have experience that you load an app in your mobile phone and the thing gets stuck. I'm just like, what a second, why it doesn't load? Or it loads and then you cannot move it. Or you are reading the content and suddenly the thing move up like, what's going on? I get very, very annoyed and you know, and we have data that proves that it's not only me. Users dislike this a lot and that causes, you know, heat site owners and web developers when it hurts the most is money, right? 53% of mobile visitors are going to leave a site that takes three or more seconds to load or more than three seconds to load. Wow, if 75% of the sites take 10 more seconds, that means that half of the web is not being seen by anybody. So you spend all that time developing your site and then nobody goes and says it, that is sad. There is an inverse correlation between conversions and each second delay that your application takes to load. 7%, that is a lot of conversions. And it's also an inverse correlation between the money that you get on ad revenue and the load time. So this is painful, right? So if you cannot monetize, you cannot eat, you cannot code. So we need to fix this. So for me, probably the worst problem, and I want you to pay attention to this because it's related to what I said at the beginning. The worst effect of having a large capability usage gap and the complexity of the development workflow nowadays is that it's what is called in sociology, the Matthew effect of accumulated advantage. Very fancy term to say that it seems that only superstar developers or evil corporations, right, or people that have a lot of money, then they are the only ones that have access to providing great user experiences. And that is not what the web is all about and it's definitely not what WordPress is all about. So we need to close the capabilities usage gap. How do we go about it, right? I see basically two options, right? So option number one, you do it, right? Do it, go and do it, right? So all the capabilities are there, all the technologies are there, you know, there is documentation, everything is there for us to do it, okay? The reality looks more like this, right? Jesus Christ, you know, I have to learn webpack. Should I do code splitting? How do I do lazy loading? Oh, are you using the pre-connect API, everybody? Are you loading resources asynchronously? And do I have to do that every single time with every single change for the lifetime of a map? Wow, it's more difficult than I thought. So this reality points to, there has to be a better solution and a better approach. Don't take me wrong, you know. I work with some superstar developers, you know who you are, right? That they can do magic, right? But they are like the 1%, right? Or the 5%? I am in the 95%. I wanna do it too, right? So I am thinking about this notion of a progressive web ecosystem. Is a web ecosystem where making the right thing or doing the right thing is easy? It's like, well, you know, if you know what you want to do, you can do it. And it has the following components. First, you have an evolving platform, a platform where web APIs are improved over time and they are added back to the platform. For example, that's what I refer to the core technologies and the web standards. Then we have tooling, which is very important, you know, things like, I don't know, webpack or progressive team starter kits that are very important. Then we have frameworks, think about React, Workbox for service workers API and so on. And then this is a key component. Now we need to do this over and over again. So we have a powerful platform, but we want to do more. So we create tooling and frameworks. We learn what works. We bake it back in to the platform. Next step, repeat. So we're gonna do this until the end of time. And every time, we're gonna end up with a better platform. So this is what we call then, if you think about this, then, well, WordPress is also an ecosystem. I like to think about the notion of progressive WordPress. And a progressive WordPress ecosystem is a WordPress platform where modern workflows, coding best practices, performance best practices, and the use of modern web APIs are the norm. Now they're like, wow, that is a super good thing to do. But 99% of the other things don't do it. This is where we are after. And I think that you are too. So this is when I tell you that we have shared goals, it's because we all want this, okay? The question is that, as we all know, WordPress is massive, right? It's like, it's a very, very complex ecosystem. How do we go to achieve this quickly? I don't wanna wait five years. I want this yesterday. How do we go about it? There are many ways, for sure, but one way is a proposal that we have, and I'm sure that you have heard about AMP. AMP is an open source library whose all reason to be is to make it easy to build pages and full websites that provide user experiences that are compelling, that are delightful, and that load near instantly. And what AMP does in a nutshell is to package, right? In a container, a set of coding and performance optimizations that address three problems. One is low time performance. The time that it takes to, when you go the first time to a site, how long does it take to load? Runtime performance, that content shifting or blog content. Well, that runtime performance is the content blog, right? Because the content is blog waiting for resources to be loaded and usability has to do with content shifting. I'm reading the damn content, why do you shift it up? I don't like that. So what is AMP exactly? AMP, when we talk about developing AMP sites or AMP pages, we talk about three components. The first one, this is blank. Okay, is what is called AMP HTML, that is the format. You can think about it as a subset of HTML because there are certain tags that are not allowed. For example, the image tag is not allowed, but it's replaced by an AMP image tag. And the reason to do that is because you want to guarantee performance, right? And then in order to achieve that, then you impose certain constraints. But it's also a superset of HTML because AMP is a web component library and it provides a lot of advanced functionality that would be very hard to do by yourself and it provides to you in the form of custom tags or custom elements, okay? The second component is the AMP runtime. That is a piece of JavaScript that runs on every AMP page and is the superpower, right? It performs a lot of optimizations that make AMP fast and it also provides all the logic for the AMP components or interacts with the AMP components itself that are web components. And the third component is the AMP cache. It's a sort of like a content delivery network that allows the caching of AMP documents that can be accessed by everyone. Let's take first a brief look about some of the optimizations that AMP does. And then we go back to the notion of the cache that I want to emphasize. And I wanted to add this part in which we go dive, we go deep a little bit into what AMP does. So you have a sense of, wow, I don't have to do that by myself. So what are these optimizations? And when people ask you why AMP is fast, this is why. AMP is all about one premise, I think. That's the way that I like to say this. Do not block the rendering of a page never by no means avoided, okay? And one of the main mechanism to achieve that is you need to load all your resources asynchronously, okay? So that's the first step. The second step is in a regular HTML page, right? The browser has no idea what is the layout of the document until all assets arrive to the page. So that's part of the reason why it takes so long because the browser is there like, okay, then when the resources arrive, oh, sorry, I thought that this was here, but it's actually here. Oops, content shifting. Or that particular piece of content never arrived and my content is blocked. So in AMP, you have to specify, or all elements have to specify their size attributes. And that means that with one HTTP request, AMP knows the layout of the entire document. That's it. That is one of the reasons why it's so fast because you have information that allows you to say, if I say that this is here, it's because it's here. Okay, and I wanna guarantee it. The other part is inline size balance CSS. Often, HTML pages or websites include one or more external style sheets, right? And to load all of them in the most basic case, you need to issue an extra HTTP request. And in cases when there is high latency scenarios, remember 2G network, 3G network, this affects performance. In AMP, you are allowed to use one inline style sheet and it's size bound to 50 kilobytes. That means that you need zero requests to load your CSS. And the size bound forces you to practice good CSS hygiene. No more saying, like, yeah, put the rule there. Who cares? I have a thousand rules, 20 more? No, not a big deal, right? It is a big deal, right? When the browser has to do a recalculation of your style layout, having 300 kilobytes of CSS, you're gonna feel it. Or your user is gonna feel it. If you feel it, it's okay, but you don't want your user to feel it. In AMP, another thing that happens is that resources are loaded, specifically images and ads, for example, are loaded only when they are likely to be seen by the user. And the pre-connect API, that is one of the newest API in the browser, is used extensively. And then it deals with all the initial parts of a TCP connection, DNS, TLS negotiation. And what that means is that when the lazy loaded image, actually it's loaded, the STP connection is very fast because a lot of the work was done already. So this is another important component. This is a very, very painful point, right? It's like, I'm sure that you have heard about this, the style layout recalculations. Every time that you read properties and write properties of the DOM, the browser has to do, basically, a complete recalculation of the layout of your document. And many times, if you are not careful, you can't be telling the browser, recalcul, recalcul, recalcul, all the time. And that slows down your performance a lot. So technically, fixing this is simple. You just have to do not interleave reads and writes, just all the reads and then do all the writes. And that's it, simple, right? The problem is that it's very hard to do, especially if you have more than one developer. Because now you have to be coordinating what they do, what is your read, that's impossible. That's what it's not easy to do. And those, what is called DOM bashing, it takes all the operations of the DOM and organizes it in a smart way so that you minimize the number of recalculations that your page is done. Usually, one you need to do. So it's a big, big, big impact on performance. The other one is, well, animations. Animations are a big contributor to the quality of the experience, right? I like to see things moving and wiggling and shaking, but the problem is you are not careful. Those animations are very CPU intensive, right? So what it turns out that all of our devices, well, not all of our devices, but many devices nowadays have graphic processor units or GPUs, and those processors are very good at computing what needs to be rendered on the page. Not all animations can be run on the GPU, but some do. So AMP, it says, well, I'm going to be your friend and I'm gonna not let you drive drunk, sort of. Like you say, no, do not do that animation, just do animations that run on the GPU and you're gonna be very fast. AMP only allows animations that can be run on the GPU, namely transform and opacity, okay? So the other one is resort prioritization, and this is a very big one. This is very difficult to do by yourself because the fact that AMP has a static layout system allows it to be very smart about how to handle resources, right? AMP thinks about a document in terms of the viewport. What is the user is gonna be looking at, right? Everything that is there is sacred. If you told me that that's gonna be two by two, it's going to be two by two. Now, if you are above the viewport or below the viewport and the element com, for example, a tweet, you don't know how big a tweet's gonna be. But if you put it in the viewport, it's gonna stick to the size that you specify. But it's going down and it's bigger because it has a video. Okay, AMP doesn't care, it just resizes it. This is a very important one, too. Sorry. Analytics is another big one, right? So we need to measure. We know, you cannot improve what you cannot measure. You need to track how much money you're making and so on. The problem is that many, many, many, many times, people say, like, oh, I need to measure this thing and then I put an analytics library. Oh, I need to measure that thing and it's another library. And then you end up with three, four analytics library that needs to be loaded, right? And once they are loaded, each of them is measuring what's happening and each of them is reporting. And that is a lot of overhead. What AMP does is something very simple but very clever. It's just decouple the measurement from the reporting, right? AMP knows how to talk to all major analytics provider. AMP does the measurement and then it reports to all the analytics provided that you want. That saves a ton of time and a ton of complexity. And the latest one is instant loading via pre-rendering. And this is one of the golden voice of these optimizations because it will just take seconds out of the load time. That's what gives AMP the sub-second capability. And this is where the cache plays a role. So let's go back to the cache. The cache, as I said, is some kind of content delivery network that allows caching of AMP pages and the access close to where the user is for free. So if you have AMP pages, your AMP pages are going to be in Indonesia for your Indonesian users. And you don't have to deal with it. You don't have to pay for it. It's gonna be quickly for them, okay? It also ensures that the AMP pages that are served are actually AMP because that is what allows you to tell your users, I am consistently fast. It's not that I am fast if you are in New York but I'm slow if you are in Venezuela. Not good, okay? It also performs a lot of other optimizations that optimize HTML. It does a lot of image optimization. For example, if the AMP cache realizes that you are accessing the page from a browser that accepts or the handle's WebP is going to serve WebP, which is much more efficient, okay? Now, all these optimizations you can do it by yourself, right? You cannot optimize HTML. You can check which user agent is accessing your site and provide the right images. But the pre-rendering you cannot do it by yourself is very difficult. And let me a little bit show you what happened. So, because AMP knows exactly where everything's in the pitch, so it can say, well, I'm going to pre-render only the piece of the page that is gonna be seen by the user and everything else is going to be loaded lazily or when the user actually decides to scroll or going there. And remember the pre-connect API that helps the part. And the pre-rendering is very cleverly done because only images are pre-rendered. A video is pre-rendered in a very smart way. I'm not gonna get into that, but the users see that there is a video, but the video is not actually loaded until the user clicks on there. Also, it's done in a privacy-preserving way. So the cache does the pre-rendering, but no JavaScript is executed, which means that if the page was pre-rendered but the user didn't see it, you're not gonna get the page view in your analytics dashboard. So all of this is to tell you all of this is happening when you are using an AMP page. So it packs a bunch of performance that you can use, you have at your fingertips, you have an AMP page. So the question that we ask ourselves, what if we could integrate AMP? We WordPress in a way that if you choose to use it, you can take advantage of all those things all the time without thinking about it. And that's exactly what we are working on. You know, when I was at Google, I was telling people WordPress uses plugins. I don't have to go to that part here, but when we're talking about AMP in WordPress, at this stage, we are talking about an AMP plugin. The AMP plugin for WordPress started very early in the lifetime of the AMP project. WordPress was one of the earliest adopters of the project. It was an open source project that automatic pioneered. And because they started at the very beginning of the AMP project, AMP itself was very limited. For example, at the beginning of AMP, forms were not supported. So the plugin adopted a mechanism that was very effective. It's called a permode, that where for each piece of post content, there was an alternative version of it, that was the AMP version. And the plugin definitely succeeded, even at that early stage, in enabling AMP in tons of websites because WordPress is massive. But it suffered from the problem that it was super flexible for developers. But if you didn't have the engineering capabilities of the money to pour into that, then you end up with an AMP experience that was very lame, right? The blue bar, boring, and people get upset, like that's not my site. Yeah, I want to access the cash, but I don't want that thing, right? So that's the Matthew effect of community and advantage. Then comes an agency like XWP and has this shiny AMP page. Ta-da! Yeah, because I had the Superstar developers. What about me, right? So we started collaborating with Automatic. I'm not taking it wrong. Automatic did an awesome job with the plugin, given the constraints of the library at the time. So we started collaborating about version 0.4 and we started doing things. Mo Yanda is a lot of, I give him a lot of credit for pioneering this project. And by version, after version 0.5, then we joined forces with XWP and we set our site to say, what if we do not need a permote? What if we can provide in a very easy way a native AMP experience? So where there are no visual gaps, I forgot to say that, right? The blue bar and the lameness of the pages is because is what we refer as a visual and functional gap between the canonical content or the original content and the AMP version. So when we started working with XWP, we say, well, let's set our site on native AMP. We want to achieve full AMP experiences. And we put a lot of effort on this project and it certainly enabled native AMP. So by 0.7, we had enabled native AMP support, page support and so on. And now version 0.1, 1.0 alpha was released last week and it's basically 0.7 made native AMP possible, but it's still not easy to do. 1.0 addresses the usability problem, right? The workflow, how do you incorporate this in the most WordPress-y way possible? And we also work on Gutenberg integration in support for several core themes and improvement of the workflow. And now I would like to call theory and he's gonna show the magic of the plugin in action. Good morning. As we just saw on the AMP plugin's timeline, the evolution of the AMP plugin in the past few months has been amazing. It literally grew from a toddler to what is now an adult. That said, still today, the AMP pages in WordPress are referred to as the pages with the top blue bar. The reality though is that the plugin today is capable of a lot more. It's capable of integrating an amazing AMP user experience in WordPress. So let's dive in some of the fundamentals and that's more specifically the AMP plugin modes. The initial version of the plugin introduced AMP in WordPress and it was using what is called a paired mode. In short, a paired mode means that you have a standard version of your website and a second version of your website which is the AMP version. But like any early version of a software, it comes with its limitation. And in the context of the paired mode, which is now called the legacy paired mode and we'll see why in a minute, the main limitation is that it used a different set of templates, providing a very different user experience between the two versions. If we look at the screen right now, one website is using the 2015 theme and the other one is using the 2016 theme. And the styling is obviously different between the two websites. And if we look at the AMP version, they look similar for both websites and that is what we call a visual gap between the non WordPress, the non AMP version, sorry, and the AMP version. Added to that, the legacy paired mode had more limitations. For example, it didn't include the navigation. It didn't include the comments, the widgets, and the list goes on. This is what we refer as a functional gap or what the Google search console refer as a content mismatch, also affecting ranking. To overcome these limitations, the paid mode was completely reimagined and a new paid mode was introduced in the 0.7 version of the plugin. The new paid mode is all about closing the visual and functional gap that we just saw. It's to provide a very consistent user experience between the two versions. And why two versions? In some cases, some features of the standup website might not have a matching AMP component yet. And yet, I want to emphasize this word because the AMP library is growing every day and there is more and more capability that can be leveraged. This is where the new paid mode really shines. But ultimately, the visual gap and the functional gap would be close to zero. And if there is no visual gap and no functional gap between the two versions, why having two versions? And that's what takes us to the last mode, which is native AMP, what I like to call the cream of the cream of all modes. And native AMP is a world where there is only one version of website and that is the AMP version. That provides a very consistent user experience across the entire website. And one might think that this is a little bit limiting, but we'll see a little bit later on in the demo that we can actually build amazing things using the native AMP mode. So let's recap. We have the legacy paid mode, which came with the initial versions of the plugin and is still available for backwards compatibility. But we expect the number of sites using the legacy paid mode to decrease in the coming months. Then we have the new paid mode, which is all about closing the visual and functional gap but still allowing for some features to be rendered on the standard version of the site. And then we have the native AMP mode, which is all about combining everything in one version and providing a consistent user experience. One thing to note is that the legacy paid mode is still around, but every website owner around the globe should consider migrating to the new paid mode or the native AMP mode, which provides endless benefits over the legacy paid mode. So let's jump a little bit into what powers the paid mode and the native mode. The plugin now comes with a set of amazing features which does actually most of the heavy lifting for us. Let's look at some of these great features. The first one is that now every WordPress built-in components are AMP compatible if you use the plugin. And that's the widgets, the comments, everything that we can think of that WordPress would render is now AMP compatible. That really closes the functional gap, but it also allows WordPress developers to continue using the WordPress APIs, coding the WordPress way and let the plugin do the rest. AMP is all about speed and with that comes some restrictions. For example, only 50 kilobytes of CSS is allowed. The reality in the WordPress world is that most themes use a way more than that. And having to reduce over 100 kilobytes of CSS down to 50 kilobytes can be really, really hard or actually require a complete rewrite. The plugin now has a cool feature which is called CSS tree shaking. It scans the HTML document, checks for all the attributes which are used and literally remove all the unnecessary CSS on a per page basis, considerably reducing the amount of CSS rendered on the page. This is a key feature while working with existing themes or existing plugins because in many, many cases, we cannot rewrite the entire CSS. Predicting what is rendering on the page from the built-in components is fairly easy, but predicting what thousands of plugins and customer integration rendered on the page is really difficult. And that's why the plugin now has a post-processor which literally ensure that everything rendered on the page is AMP valid. In some cases, though, that would mean removing some functionalities, for example, when they are written in JavaScript. And the goal of the plugin is to make the AMP integration as easy as possible, but not to introduce regression. And that's why we saw a need for a validation workflow which literally tells the user everything that has to be removed or modified on the page and has an opt-in-opt-out option for the site owners to leverage the power of the plugin but also control what is done on the page. So this set of amazing new features allowed us to do some really cool stuff, starting by adding AMP support for the native, for the new paid mode and a native AMP mode for all default themes bundled in WordPress by default. And if we think about this a little further, this means that today with the 1.0 alpha version of the plugin, anybody can provide a native AMP experience using WordPress core functionalities. Of course, you would guess it, one of our main focus has been on Gutenberg as well. To start with, all the Gutenberg core blocks are now AMP compatible, but we didn't stop there. We wanted to actually leverage the power of Gutenberg and the power of AMP. Gutenberg has this concept of blocks to build pages and on the other hand, AMP has the concept of components. But what about combining the two and leverage the power of both? This is exactly what we did and we built Gutenberg AMP blocks allowing users to easily benefit from the AMP components and the amazing flexibility that Gutenberg brings to the table. We push boundaries to take the native AMP experience in WordPress a step further, leveraging the latest work done on the plugin and the latest work done by the Gutenberg team and this is what we have achieved. What we're looking right now is a travel theme inspired by the AMP start travel theme, but it's fully powered in WordPress and Gutenberg. And as we can see, the native experience is now really well integrated or even seamless and we can see that we can do some really cool stuff. For example, leveraging some of the AMP components like the AMP carousel that we're seeing right now for a slider or the AMP bind component to change the price of an adventure. And on the other end, we can also see that we're leveraging some of the WordPress components, for example, the WordPress comments to submit reviews. We also see some cool stuff like the WordPress search to actually search for adventures and now we're really seeing the power of the CMS and the power of native AMP combined together. Of course, it looks beautiful on mobile. It's all combined in one version and once again, we can see, for example, that we're leveraging the taxonomies to categorize the adventures by activities. If we look at a single layout, we can also see other cool AMP components like the AMP YouTube. What about the content creation experience? How does it feel to build such pages or native AMP pages with Gutenberg? So let's rebuild our homepage using the Gutenberg AMP custom blocks. For example, we're gonna add our hero block and immediately when we insert the hero block on the page, we get the look and feel of what it looks like on the front end and we can manage the content in a very nice way. For example, inline editing. Let's go ahead and add a block. For example, the discover block. We get, again, a very good content creation experience where we can edit our content and see it on the fly. And let's add one more block which is gonna be the featured destination block using a taxonomy and pulling the content dynamically, of course. And an important part is now let's customize our page. For example, move the features destination block up. Boom, there we go. And just like that, we have rebuilt a different version of our homepage using Gutenberg and all that native AMP. So where we are today. The 0.7 of the plugin has been released and that was all about introducing the new paid mode and making native AMP possible in WordPress but it was still very orientated towards developers and had to require, for example, the theme to be built from scratch. Now 1.0 is now released and that includes all the CSS tree shaking, the validation workflow, the Gutenberg blocks being incompatible and this is really the first step towards the universal adoption for integrating AMP in existing products. What we have today is amazing but the future is even brighter and for that I would like to take one minute if we have one minute for Alberto to come back on stage and tell you what's coming next. We're gonna skip this part. There is a ton of work. One thing that we're gonna be doing is integrating service worker API with core. If you are interested, stop by the booth and sorry for taking so long time. Thank you. There are some information here. We're gonna be publishing the slides and do it all.