 I'm Alberto. I'm a developer advocate in the content ecosystem team at Google. I'm super happy to be here with my teammate, Western Router. We are going to talk about bringing the pillars of modern web development to the space of content management systems. But let's start with the end goal in mind. Our goal as web creators is to maximize the joy that our users get when they go to the websites we build or the content that we create and publish on the web. And although it is true that user experience is a complex matter, there are certain elements that are commonly found in experiences that users love. Specifically, users love presentations that work, number one. They love sites that load fast consistently and offer good runtime performance. They love sites where they feel safe when they trust their data or they do transactions when they decide to do so. They like sites that feel accessible and they are integrated with the full capabilities of their devices. And they love sites that offer great content quality. The good news is that we can build today experiences that have these pillars if we take advantage of the capabilities that the modern web has to offer. Now, doing this is what we call progressive web development. In essence, progressive web development is developing user first experiences using modern workflows and modern web APIs, following coding best practices and performance best practices, and taking advantage of effective incentive mechanisms and validation structures that are available to us. Now, we can take advantage of these principles in different ways, depending on how we go to the creative process. How do we create things in the web? In general, the things that we create in the web follow in two categories. On one hand, we can build websites or web ads from scratch, in which case, we have full control of the whole creative journey, from the build process to the functionality of the app to the look and feel. Or we can take advantage of some kind of content management system that are our CMS, for short, that are software platforms that add a layer of abstraction on top of the open web to offer capabilities to create, publish, and consume digital content on the web. If we follow the first route, we have full control, and full flexibility is very powerful. But also, it requires a lot of expertise and resources to follow. If we follow the second route, we can take advantage of the capabilities that the CMS has to offer to us. But then, at the end of the day, the experience that we can offer to our users depends on the characteristics of the CMS that we choose. Now, it turns out that nowadays, the majority of content in the web is created and consumed via some kind of content management system. Specifically, 54% of sites today are built on some kind of content management system. And we saw this year 11% year-over-year growth. These are staggering statistics. And there are other systems that do not think of themselves as CMSs, but also offer the same capabilities of making it very easy to create and publish content. So in reality, these statistics are much higher. So this basically means that the CMS space is very large and very complex. CMS comes in many shapes and forms, and they vary according to certain dimensions. For example, you can have static versus dynamic, open source, closed source, special purpose, general purpose. But although there are differences between them, they also share a lot of commonalities. And specifically, many of them face common challenges when it comes to integrating progressive web technologies into their platforms. So many of these systems are very large and complex. There are many interacting components. They have large code bases. They have legacy code, technical depth, and so on. There are also some of them have evolved on top of initial architectural choices that make it difficult for them to evolve and become progressive. They also suffer from fragmentation very often in terms of things like the quality of the components that make them or the expertise of the developer community or the type of users that are creating and consuming content on the platform. And often, and this is very important, CMS lacks effective incentives for developers to do the right thing. For example, exposing coding and performance metrics so that users of the CMS can choose solutions based on quality and not just on popularity. Now, we want to tackle these challenges in the CMS space. And in order to reason about how to do that, it is very useful to abstract our thinking about the systems in terms of the components that make them. A CMS ecosystem, one way or another, has certain components that form a unique ecosystem for each of them. There is usually a core, a platform core, that offers the basic functionality of the system. There is usually some kind of extension mechanism that allows you to extend the core functionality. These extensions are usually called modules in some CMSs, plug-ins on another. Also, things, if they have to do with the look and feel of the system, there is usually a developer's community that are in charge of evolving both the core and the extensions of that platform. And then there is the user base of the CMS that are either creating content or consuming content on the platform. So when we talk about progressive content management systems, we are talking about bringing the principles of progressive web development to the component of each of these ecosystems. For example, how do we bring coding and performance practices to the developer ecosystem so that they can do the right thing? Can we bring tooling so that it makes it easy for them to do the right thing on the first place? Or can we bring incentive mechanisms so that they are compelled to do the right thing? Now, Google is working with many CMSs to support them in their effort as they integrate progressive technologies into their platform. So in the next few slides, we are going to show you the results of a particular effort that my team has followed in the context of specific CMS. And then later on, we are going to touch upon some of the great work done by other CMSs. Our team has been pursuing efforts to bring progressive web technologies to the WordPress ecosystem. This little fellow here there is WAPU. That is the mascot of the WordPress ecosystem. It's not a mouse, although it looks like a mouse. So WordPress nowadays powers about a third of the web. So there's a lot of users creating and consuming content on this platform. Now, given the size and complexity of the WordPress ecosystem, if we address the challenges that they face, we will not have only an impact on a very large swath of the web, but also we will be able to shed light on how to address these challenges in other CMSs. So our goals with these efforts are twofold. One is to tackle the challenges that the WordPress ecosystem faces, and also to gather our learnings that we get along the way and bring them over to other CMSs in the form of objective guidance, tutorials, technology transfers, and so on. Now, our approach, the approach that we follow to make WordPress more progressive consists of two parts. The first part is leveraging the capabilities and also accelerating the mobile pages of AMP for short. AMP provides basically a well-lit path to modern web development in WordPress. AMP is an open source web component library which provides out of the box a set of capabilities and optimizations that are essential to achieve awesome web experiences in the web. For example, coding and performance best practices so that you don't get things like unresponsive content when you are loading it or with usability so you don't have this content just in front of your eyes when you are trying to engage with the content. It also provides an incentive mechanism, for example, the capability of getting near instant loading time when AMP content is loaded from the AMP cache. And it also provides a validation framework that helps developers to bring their sites to high performance states and to keep them in that state as the site evolves. So if we enable AMP content creation in WordPress, that means that WordPress developers can take advantage of all these capabilities without deviating of the normal content creation workflow that they follow in the platform normally. We have achieved this integration by means of an AMP plugin for WordPress. Right now, it is in version 1.0 release candidate 2, and the stable version will be released at the end of this month. Now, this plugin has a lot of capabilities and features. Unfortunately, we don't have time today to go over them in detail. But I want to mention a specific important one, one that assists WordPress developers as they build teams and plugins that are fully AMP compatible. The plugin comes with a compatibility tool that supports the development of AMP content in WordPress. In a nutshell, for any URL on a site, the plugin tells us all information about any error that can exist in that URL in very minute details. It tells you even the markup that is generating the error and also the component in the WordPress site that generated the markup in the first place. Was it a team? Was it a plugin? Was WordPress core? What is it? So if you are a WordPress developer, you can take advantage of this tool and all the other capabilities that the plugin provides to you to create AMP content in your website. If you are a developer from other CMSs, the good news is that they are also implementing AMP. And we are going to tell you more about this in a little bit. Now, the second part of our approach of bringing progressiveness to the WordPress ecosystem consists on integrating modern web capabilities and APIs into WordPress core. We want things like service workers, streaming, background sync, all the goodies that you have seen today. We want them to be supported natively in the WordPress platform. So the goal of the integration is that there is a consistent and unified approach so that all WordPress developers can take advantage of them as they develop functionality for either core or themes or plugins. Now, last year, our colleague Surma, which you have heard of him, by the way has a complete disregard for the impossible, he decided to show that PWA with WordPress is actually possible by building a WordPress theme that does all the things, as he called it. He successfully proved his case and he presented his work at CDS last year. But he also faced many challenges along the way and he recognized that it would have been super great if the WordPress platform would have provided him with the building blocks that he needed to build his WordPress that does all the things in a much easier way. So in addition to our work on AMP for WordPress, our team focused this year on devising and implementing the integration of some of these building blocks into the WordPress core platform, okay? And we emphasize the requirement of doing that in a way that is seamlessly integrated with how WordPress works in the first place. So I would like to call my teammate, Western, to tell us more where we are in this effort. Gracias, Roberto. Yeah, Surma certainly did build a WordPress theme that did a lot of things. And he had a service worker that was installed by the theme and that service worker powered things like offline reading and background sync. It facilitated smooth page transitions as you navigate around the site. And while his proof of concept was compelling, it faced a lot of challenges. And it was because WordPress didn't allow for doing things that he wanted to do. And so, but these challenges are not unique to WordPress. They are common to other CMSs as well. So there were a few fundamental challenges that needed to be addressed. The first challenge is that there needs to be a central API in the CMS for generating a service worker. Because there wasn't this in WordPress, the theme itself had to generate the service worker. And this is a problem because as with Highlander, there can only be one service worker at a time. Multiple service workers could be installed, but only one is active. And so a CMS like WordPress needs to be able to generate that service worker centrally. The next challenge is that writing service worker logic can be complex and that the CMS should provide abstractions as a part of it that eliminate a lot of that boilerplate code that has to be repeated over and over again. And the last challenge, as Alberto referred to, is that WordPress extension system and other CMSs as well don't have sandboxing. And so a theme or a plugin can do things that make it difficult to maintain advanced capabilities like the App Shell model. So we implemented abstractions in WordPress to solve these challenges. And what we did is applicable to more than just WordPress. First of all, we integrated the service worker API into WordPress so that themes and plugins can each include their own service worker logic and to be installed by the single service worker that was generated by the CMS. But this is just the base requirement. There also needs to be, as I said, those abstractions to make it easier to generate the complex logic that is needed to power a service worker. So our integration includes a work box out of the box so that as you've heard about earlier today, you can take advantage of all the complex logic for generating caching strategies and other advanced functionality like Background Sync that are part of work box so that you don't have to reinvent the wheel. And since WordPress developers have historically been PHP-first developers, we have included PHP abstraction that allows you to write PHP instead of JavaScript so that you can have a PHP call that gets translated into the equivalent in JavaScript. To give you a sense for how this API is used in WordPress, in this first example, you can see a caching strategy being leveraged here at Stale Wall Revalidate to match any request that is made to the AMP project CDN so that it will be then served from the cache while being updated in the background. And here, you can see a image being pre-cached by the service worker and then served directly from the cache without hitting the network at all. And if these two examples here look familiar to you, then that is no mistake because they're essentially PHP versions of what you would be doing otherwise in JavaScript via work box. But if there is no abstraction in PHP for you to do that, you can also hook directly into the service worker to add your own arbitrary JavaScript to do more advanced functionality if needed. So given these service worker capabilities, one common application is the AppShell model. And AppShell facilitates those seamless page transitions and offline interactions that you often see inside of native applications. But making a AppShell is often very difficult and challenging to do in WordPress because themes and plugins can add absolutely anything to the page, like I just said. And so this, again, is where the AMP plugin plays a key role because it enforces those constraints to make sure that the content behaves in a way that doesn't break the AppShell model. And AMP is also specifically designed to be embedded inside of these kinds of experiences. Here is a demonstration that we built that shows the standard theme 2017 with a nice spinning logo for fun. Keep watching that logo. Notice as I open the nav menu and start clicking around, the content is changing. But the logo keeps spinning and is unchanged. The header nav menu remains expanded. And you don't lose that context as you navigate around the site. So it's a single page application built in WordPress using a standard theme as the basis. And we could do it just with a minimal amount of code thanks to the foundation that the AMP plugin provides in the AMP project as well. You can look at the pull request on the AMP plugin repo to see more specifics in how you can get started on your own themes. To give you a glimpse of that, here you can see the theme just has to declare theme support to enforce those constraints to make sure that everything is served available in AMP. You have to make sure that the whole theme is able to serve every page in AMP. So you do add this to your theme. Next, you indicate the region in the template that contains the content that dynamically changes as you navigate around the site. And lastly, you tell the AMP plugin that you're opting into App Shell. And then that then causes the AMP plugin to generate the service worker logic to pre-cache the App Shell and to add the JavaScript to the page that will then intercept the clicks and do the history management and all that. And the bottom line here is that the theme developer doesn't have to know the complexities of building App Shell. They just extend what is already in the platform. But service worker is applicable to more than just App Shell. It also is useful for other advanced capabilities, including offline access. Often, if you've developed a WordPress theme, you're familiar with the 404.php template, which is used to serve a page to the user when WordPress can't locate the site, the content that you're trying to load. And in the same way, we have extended WordPress's template system to introduce an offline.php, which will then be served to the user when the browser can't access the site. And so they get that nice branded experience from the theme without the dinosaur. And to opt into caching pages that you visited while online, you can opt into that Stalewater Validate Strategy for Navigation requests so that those will continue to be available when you go offline. And lastly, service worker is useful for commenting offline as well. So here, if I try to submit a comment while offline, then the service worker can intercept that request and then replay it when the user comes back online via background sync. And here, the developer doesn't have to do anything because it's just part of the integration itself. So with that in mind, I'll pass it back to Alberto to talk about the road ahead. Thank you, Weston. This is super good to see all these things running. And we certainly have made a lot of progress in the context of WordPress. And other CMSs have done also a lot of progress. But we are still not quite where we need to be. So in the context of WordPress, the AMP plugin is available to you today. You can download it from the GitHub link. So please download the start experiment with your site. We are going to continue expanding this work, integrating AMP content creation into WordPress, especially specifically in the context of Gutenberg. That is the new editing experience in that platform. In the area, the integration of PWA, the service workers, and all the PWA capabilities into WordPress core, we have made a lot of progress. Right now, that functionality is available in the form of a feature plugin that you can also download and experiment with your other WordPress developer. And we are going to continue working with the WordPress ecosystem to help them to integrate these technologies into their work at all levels. Now, one aspect that we are working that is very exciting is enabling content creators to create content easily, taking advantage of new powerful format such as AMP Stories. As you can see in this example, AMP Stories is a mobile-focused format for delivering rich information in terms of visually-rich and tap-true stories. We are building an AMP Stories editor for WordPress, which is also integrated with Gutenberg, the new editing experience of WordPress. To give you a glimpse of where we are in this work, this that you see here is all the Gutenberg editing experience. And the good thing about Gutenberg is that everything corresponds to a blog. And that design premise lends itself very well to create AMP Stories that are also formed by components. So the goal of the editor is to allow users to manipulate all the components of an AMP Stories, control the parameters, and so on. We want powerful content formats like this to become available across all CMSs. And one interesting development that is happening is that Gutenberg is being ported to Drupal, which is another popular open-source CMS. And this is great because then they are going to be able to take advantage of this editor right away. So much more on this will be coming next year, so stay tuned. So to conclude, I can say that the CMS space is moving forward steadily along the progressive web road. Google is working on supporting many of CMS platforms who help them advance in this path. And we are seeing excellent results on some fronts. Here we have some examples. Drupal, which I mentioned is another popular open-source CMS. Their developer community is working on the AMP and PWA modules. They are available in sites today. And they are working on enhancing them. Magento, which is a popular e-commerce platform, they are releasing Magento 2.3 this month. And that release includes PWS Studio, that is a set of guidelines and tools to be able to create awesome web experience in their platform. Adobe Experience Manager, which is a popular CMS in the enterprise arena, they have allowed the creation and publishing of single-page applications directly from the page editor. And they are working on also providing service working integration natively in their platform early next year. At the end, we have ECQ, that is one of the leading e-commerce platforms in Japan. They are working with an agency that is called Sunday Systems on an AMP plugin that would also enable the creation of AMP content on their platform. So we want to extend special thanks to XWP, which is an excellent WordPress agency that has been partnering with us. And they have made awesome contributions in the areas of bringing AMP and PWA technologies to the WordPress platform. With that, I want to say thank you. And stay tuned for more progressions coming soon to CMS NRU.