Make your WordPress site progressive (Google I/O ’18)
Articles Blog

Make your WordPress site progressive (Google I/O ’18)

August 11, 2019

you have heard before the term “progressive.” Today we we’re
going to be talking about how to make
progressive WordPress sites. And you have heard the
term progressive probably in the context of progressive
web apps, which mean basically web apps that have been
developed using mobile web capabilities, or in the context
of progressive enhancement, which is the application of
those modern web capabilities into your sites in a
step-by-step way instead of all at once. Here we are using
the term progressive to capture the notion
of progressive web development, which means
development of user-first web experiences, using modern
web capabilities, coding, and performance best practices. And the key here is
the word “user-first,” which means that at the core of
progressive web development is user experience. So lets start at the core. What is user experience? User experience refers
to a person’s emotion when they are using a product. In our case, that product is
our website, our WordPress site. So it is all about
how users feel when they are engaging with
the content that we create and that we publish. So the way that I like to
imagine this is, in a nutshell, what I want is my users to have
that expression in their faces every time that they go
to my site a little bit. But what are the qualities
in web experiences that actually bring joy to users? And there are mainly
four main factors that are commonly
present in what we define as a delightful UX experiences. Users love applications
that are fast and reliable, they load quickly, consistently,
and they behave well once they are running. Users love– sorry. Users love applications
that are secure. They want to feel
safe when they are trusting their data and the
transaction to the apps. Users love
applications that feel integrated with their
device, that they can take advantage
of all the features that the device has to offer. And users love applications
that are engaging, right? They like that kick of wanting
to go back to the application. And the application makes it
very easy to come back to them. But for a long time,
building applications in the web that satisfies these
four pillars of delightful UX was not easy or not
possible at all. And the main reason was
that for a long time, the main power of
the web was the URL, the hyperlinking capabilities. But if you compare
it to platforms to develop native
apps, for example, in the Android platform,
the web lagged behind in terms of the things that
you could do with it them. However, the good news is
that the web has been evolving quickly in recent years. And nowadays it
is fully possible to build awesome web experiences
only using web capabilities. This here is a subset
of the web APIs that are available in
the web platform today. So you can do a lot
of things with them. For example, accessing device
features like the vibration, signals, the gyroscope. You can implement
native-like features, like add to home screen,
offline access, and so on. Even augmented reality is
a thing today in the web. Now, on top of this, we have
modern developing workflows, a lot of tooling, and
powerful JavaScript frameworks that add additional
layers of abstraction that allows us to build
very, very complex and awesome experiences. And on top of all this, you have
yourself, the web developer, eager to harness the power of
these mountainous capabilities, right? The challenge is that
the complexity is such that truly taking advantage
of what the web has to offer is very difficult, right? So as the complexity of the
web ecosystem has increased, we also have seen
an increase in what I like to call the
capabilities/usage gap, which simply is the difference
between what can be done and what is actually done. For example, if we go back to,
let’s say, 1999, probably most of you were not developing
the web at the time, but arguably the gap was
not big at that time, there were not many things
that we could do in the web. There was HTML, CSS,
and the best thing is there was only a single form
factor that you had to develop. Now, fast forward to today. The complexity
has grown so much. There are so many tools, so many
frameworks, and so many things. And we have to
develop applications that have to run well in what it
seems to me an infinite number of form factors. So no wonder that
that gap has grown. And the problem with this gap is
that if we don’t take advantage of what the web
has to offer, it’s very difficult to build
applications that satisfy the pillars of a delightful UX. And we see evidence of
this a lot in the wild. There are stories that show
the prevalence of applications that run very slow. They exhibit very poor
load time performance. For example, 19 seconds
load time on 3G on mobile. 75% of mobile sites take
10 seconds or more to load. And also there are a lot of
applications– too many– that exhibit poor
runtime performance. So things like
unresponsive pages, or counting sheep in
front of your eyes when you are engaging with it. And the bad news is
the users hate this. And we see evidence of that in
the wild as well in the impact that these experiences
have on the revenue potential of our sites. For example, more
than half the users are going to leave
a site that takes more than 30 seconds to load. 75% takes more than 10 seconds,
then you figure it out, right? There is an inverse
correlation between low time and conversions. And there is an
inverse correlation between revenue and load time. But for me, the worst
collateral effect of not being able to
take advantage of the web is what is known in sociology
as the Matthew effect of accumulated advantage. Probably you have heard of
it as the “rich gets richer” principle, which
means in our context that given the complexity
of the web platform, it seems that only
superstar developers or organizations that
have the capability to afford large, high-quality
engineering teams are the only ones that
have a true chance to take advantage of the web. And that is not what
the web is all about. OK? And notice that given the
prevalence of the experience that I just described,
even superstar developers have a hard time to do it. OK? So the bottom line is,
we must strive to close the capabilities/usage gap. And there are mainly two
ways that we can go about it. One is on us. Given that the web capabilities
are there for us to use them, if we all do the right
thing, things will be OK. Right? We should not see
those experiences. However, that is
easier said than done. The reality looks
more like this, right? You have to master
so many things to have applications
that are delightful that it’s very challenging. You have to be careful
to not interfere with the critical rendering
path, low resources asynchronously, do codes
splitting, et cetera. Master browser caching. So many things. So the landscape is
so complex that it’s very difficult to do the
right thing the first time. Imagine doing the right
thing all the time for the lifetime
of your application in all circumstances
all the time. So it’s very hard. A better option is
what I like to think about a progressive
web ecosystem. It’s a platform,
a web ecosystem. When doing the right
thing, it’s easy, right? And it involves several factors. The first one is an evolving
web platform, right? A platform where new
web APIs are added, probably existing APIs
are improved, you know? We have a good set of tools
that help developers automate complex tasks, we
have frameworks that add layers of attraction
to do complex applications. And a key point in a
progressive web ecosystem is that we take the
learnings that we get from using the tooling
and the frameworks, and we see what works and we
bake them in back into the web platform. So this is a better
option, right? We want to pursue this. How should we focus our
efforts to achieve this? In order to answer
that question, it’s very useful for me to
think about the web in terms of a very, very simple
model that has three layers. The top layer has
the content ecosystem that we all use everyday
and gives us the perception of the web as one thing, right? Then there is a second layer
conformed by content management systems that are basically
software platforms that make it easy to create
and maintain content, OK? And on top of that,
the bottom layer is what you hear many
times as the web platform. OK. That is nothing else that the
implementation or the power of the web exposed by browsers
in implementation of the web APIs. So you can see that
the content ecosystem, there is a dotted line
dividing it in two. And that’s very important
because nowadays, about 50% of sites in the web are
powered by some sort of content management system. And the other ones by
some combination of tools and frameworks and so on. Now, at Google we are
interested in closing the capabilities/usage
gap everywhere. And we are pursuing
significant efforts across all dimensions
of the web ecosystem. Our effort, particularly
in this talk, focuses on closing the
capabilities/usage gap in the area of content
management systems. Now, I want to make clear
all content management systems are very important. And we want to help to make
them all progressive platforms. But in this work, we are
focusing specifically in WordPress. And there are several reasons
why focusing on WordPress will cause an impact not only
for the WordPress platform, but also for the content
management space in general and the web as a whole. First, historically,
WordPress has been seen as a blogging platform, right? But the platform has
been evolving steadily since it started back in
2003, if I am not mistaken. And now it powers experiences
across a variety of areas. You name it. Travel, education,
shopping, et cetera. So if we close the
capabilities/usage gap in WordPress, we are
going to be improving the experience for users
across a variety of verticals. That’s very important. The second one,
WordPress is certainly the largest player in the
content management system, enjoying right now, like
59% of the open source CMS market share. And the third reason, which is
for me staggering, nowadays, WordPress powers
around 30% of the web. So in a nutshell, when
I think about WordPress, I think about so many users
publishing and consuming content in the platform. And I would like
all of them to be able to get delightful user
experience, both creating the content and consuming it. So going back to our definition
of progressive web development, when I say progressive
WordPress, what I mean is a WordPress platform where
modern workflows, coding and performance practices,
and the use of modern web APIs is the standard and
not the exception. It’s commonplace, OK? Now, you must be
asking yourself, how in the world, given the
size and scope of WordPress, how can we make
progress quickly? We want to have a progressive
WordPress site yesterday, not five years from now. But fear not. I am sure that you have heard
about the Accelerated Mobile Pages project, or
AMP, for short. AMP is a open
source library that makes it easy to build web pages
and sites, in general, that can provide those
kind of experiences that are very compelling and
load near instantaneously, right? In a nutshell, what AMP does,
it is to provide out of the box a set of powerful capabilities
and performance optimization that address three things. Low time performance. I want snappy load times. Runtime performance. I don’t want content
system in front of my eyes on unresponsive pages. And usability. So I want a smooth transition
between my interaction when I engage with content. So if we could integrate AMP
with the WordPress platform as a choice, we would be
putting at the fingertips of all WordPress
developers the capability of taking advantage
of what AMP has to offer to create experiences
that are compelling and are very easy. So let’s quickly see
what AMP is in a nutshell and then we want to see
the integration in action. So– sorry. I need to click faster. So developing AMP pages
entails three components. The first thing is
AMP HTML, that you can think of it as
both a subset of HTML because there are some HTML
tags that are not allowed. And the reason is that
in order to satisfy reliable performance, you have
to impose certain constraints. But it’s also a superset of
HTML because AMP is essentially a web components
library that provides a lot of advanced
functionality that you can have at your fingertips in
the form of constant element tasks. OK? The second component is
that the AMP runtime system. That is a piece of JavaScript
that runs on every AMP page and has logic to control custom
elements, a lot of performance optimization, the load
scheduling, and so on. And then we have the AMP cache. Notice that the AMP cache is not
necessary to develop AMP pages, but it is sort of like
content distribution network that serves to make valid
AMP pages available and ready to use to everyone. I say that it’s not
necessary, but it does offer a lot of optimization
and performance interaction with the runtime
system of AMP that actually provide that snappy
load time that users love. And finally is the use of
AMP in the web ecosystem that encompasses the
implementation of product features– now, that’s
important– product features across a variety
of platforms that are seeking the same
that we are seeking, enhancing the experience that
the users of those platforms get. Things like, for example, the
top news carousel at Google is one of those
product features. Twitter uses it, LinkedIn,
and now WordPress is among these platforms
that can benefit of what AMP has to offer. So in WordPress, everything
happens in one or three places, right? WordPress Core, that
is the platform itself, themes that have
to do with the look and feel of the WordPress
sites, and plugins that have to do with
extending the functionality that the platform has to offer. So when we say AMP
in WordPress, we are referring to
an AMP plugin that is integrated with
the WordPress platform and the interaction
of that plugin with all the components
of WordPress sites, for example, the underlying
theme, other plugins that may be installed. So that is what we refer
to as AMP in WordPress. Now, the plugin for WordPress
was pioneered by an open source project started by Automatic. And it was started at the
very, very early ages of AMP. They were one of the earliest
adopters of the framework. And they implemented a very
simple but effective mechanism that we call the
paired mode, which means that for every piece
of content in a post, there was an equivalent
version but for AMP. OK? So you had two. For every piece of content,
you have two versions. And the plugin succeeded
in achieving this goal, but had one main
limitation that it was that if you didn’t
have enough engineering capabilities to work
on the resource, you usually got a
lot of functional and visual disparity between
the original content and the AMP version. So after the version
plugin 0.5 of the plugin, we joined forces with XWP. And basically we set
our eyes and our sight on enabling what we call native
experiences in WordPress. So a world where
there is no need to have two versions
of the same content because there is no official
disparity or functional disparity. You can have only
the AMP version and get all the
benefits that AMP has to offer without
sacrificing the flexibility of the WordPress platform. That was our goal. Now, there was a lot of
work put into this version. And it indeed enabled
native AMP experiences. We presented that work in AMP
Conf a couple of months ago. And it’s very good. However, it’s still
oriented to Power users. It is not as easy
as we would it like to be in order to
make it mainstream. So we are here at
I/O. And we are going to show you soon
a lot of improvement that we did in the
area of tooling and also in the editorial
workflow of content creation in WordPress. In a second, we want
to talk about that. And after this, after
1.0 of the plugin, I said that we have right now
on the alpha version of the 1.0, then comes a lot of
work that we want to mention a little bit at the
end that has to do with content ecosystem adoption. But before we do
that, I would like to call Thierry Mueller
from XWP to show us where we are along the road
to progressive WordPress. [APPLAUSE] THIERRY MULLER: Good morning. The latest work
on the AMP plugin is focused on closing
the capability usage gap in two ways. The first one is by providing a
framework to empower developers to integrate AMP in the
WordPress ecosystem. And the second one
is by providing tools which seamlessly integrate
AMP components in the brand new content creation
workflow in WordPress. To put this in context
and better understand how we’re closing the
capability/usage gap, we’re going to look at
some real world example. Let’s take the 2015 theme
which comes by default bundled in WordPress. It is active on a half
a million website today. But what would it really take
to actually convert this theme to be AMP-compatible
and specifically provide a native AMP experience? Well, lets look
at the theme first and some of the challenges
we may encounter. The 2015 theme is
all about content. It is designed for clarity. It is also designed with
a mobile-first approach. One thing we want to pay
specific attention to is the menu dropdown which uses
JavaScript, custom JavaScript. On the code side, if we look
closer at the Archives widget, it uses disallowed inline
JavaScript, or disallowed AMP, at least. If we look closer at the image,
it uses an image tag and not an AMP image tag. On the CSS side, it loads
three CSS style sheets. And if we look closely
at the total size, it’s close to 114
kilobytes, which is way above the 50
kilobytes allowed in AMP. If we look at the
JavaScript, there is multiple JavaScript
files loading. And if we take a closer
look at the function.js, it includes or
contains the handlers from the navigation
and widget area we saw early on the mobile. So to convert this
theme, we have some challenges,
custom JavaScript, too much CSS for AMP, and
a lot of non-AMP HTML. So let’s look at how we
can convert this theme. The AMP plugin comes with
a set of amazing features that can really help us
overcome these challenges. And it will actually do most
of the heavy lifting for us. So the first thing
we would need to do is to declare the so-called
AMP theme support. It is extremely simple. All it takes is to
add the code snippet that you see on the screen
right now in the custom plugin or in the child theme. And once the AMP theme
support is declared, the AMP plugin will consider
the active theme, for instance, the 2015 theme, as
a native AMP citizen and apply a set of
really nifty features. For example, the AMP plugin
is capable of converting all the WordPress
built-in components and make them AMP-compatible. And by that, we mean
widgets, embeds, comments. Literally everything rendered
by the WordPress components. So we saw early on the problem
with the Archives widget. And if we look at
the code on top before in the AMP
plugin conversion, we have this inline
disallow JavaScript in AMP. And if we look after
the AMP conversion, we can see that the
plugin has changed that to use the AMP
navigation to function, which is part of the
runtime JavaScript library. And that will help or actually
that will pass AMP validation. So if we look at the invalid
AMP and the valid AMP, what we are after is to get
exactly the same result. And that’s what we
see on the screen. We didn’t lose any
functionalities, but on the right-hand
side, we can see that it passes AMP validation. Only 50 kilobytes of
CSS is allowed in AMP to ensure maximum page speed. But the reality is in
WordPress, a lot of these themes contain a lot more than that. And to address this
issue and make it easier, the AMP plugin includes a
CSS tree shaking mechanism, which has the
ability to only load the CSS needed on any
given page and remove all the unnecessary CSS. If we look once again at
the stripped down version of the 2015 theme code,
there are two style sheets, disallowed style sheets. And the size of CSS
alone is 96 kilobytes. The plugin has the ability
to concatenate the CSS, apply the tree
shaking, and print it inline, using the
AMP custom style HTML, as prescribed by AMP. And that will pass validation. If we look once again
at the invalid AMP, we can see that we
achieve what we are after, which is exactly
the same result. But we’ve gone from
114 kilobytes of CSS down to 9 kilobytes. [APPLAUSE] It is 10 times smaller. Predicting what
thousands of plugins and custom integrations
will render on the page is extremely
difficult. And to address that, the plugin includes
a post processor which is capable of
validating the page outputs and ensuring AMP compatibility
wherever possible. But in some cases, it may
cost some functionalities, especially when
JavaScript is involved. So let’s look at this a
little bit in more detail. Once again, if we
look at the HTML before the AMP
plugin conversion, we see that there’s an image. And if we look at
the bottom snippet, the AMP plugin is able to
convert this image using the AMP image tag. And that is considered
as a safe change. But if you look at the
JavaScript, the functions.js, in order to pass AMP validation,
it would have to be removed. And the plugin is
capable of doing that. But if we look at the
invalid AMP and AMP version, the invalid works
the menu toggle because it contains
the JavaScript. But on the right-hand side,
the menu doesn’t work anymore. And there we have
a problem, right? The goal of the plugin is
to make AMP integration as easy as possible and to
improve the user experience, but not damage it by any mean. And that’s why we saw the
need for a validation workflow which allows developers to
benefit from all the features that the plugin includes,
but also have control and be able to manage it. So by default, the plugin
will convert and apply all the conversions
which are considered as safe, for example,
the AMP HTML conversion. And for the changes,
we could potentially introduce regression. They would have to go through
a validation workflow, which looks like this. For example, for the
CSS tree shaking, which is still in
beta, the developer can go ahead and
view the front end as if the plugin was
to apply this feature. And as we can see
and we saw early on, it works perfectly fine. And at that point, we can go
ahead and tell the plugin, please enable it so that
it passes AMP validation. In the context of
function.js, we saw early on that it
actually breaks the menu. And the plugin will not
apply this change by default not to introduce regression. And that will give
developers a chance to go ahead and fix
it, for example, using the amp-bind components and use
the setState function to toggle the class, right? And then preview the page
again once this change has been applied in the
child theme, for example, by overwriting
the header or PHP. And once it’s proven
to be working, the developer can go
ahead and tell the plugin, now that we fixed
it, you can go ahead and remove the functions.js. And that will then pass
the AMP validation. So to recap what it
took to actually convert 2015 theme, which is a
popular theme, right? We had to declare or enable
the AMP theme support, we had to apply one
fix for the menu toggle by using the
amp-bind components, and we went through
a validation workflow and told the plugin to apply
all the AMP conversions after reviewing them. And this is the end result. What we’re looking at right
now is a native AMP version of the 2015 theme. It looks as great as
the non-AMP version. Of course, if we
look at it on mobile it looks similar as well. And as we can see
just now, because we applied the amp-bind, the
menu is still working. Is it passing AMP validation? If we look at the
console, we can see that it passed AMP
validation successfully. And let’s look on
the performance side. Let’s run the Lighthouse
audit without the AMP plugin. So that’s before
the AMP conversion. We get a score of 66 with a
4.8 first meaningful print. If we run the same
Lighthouse test, which is running on 3G slow mobile,
after the AMP conversion, we get an 88 with the first
meaningful print of 2.8 second. [APPLAUSE] Amazing. We really see how the
latest development work done on the
plugin is helping converting existing products,
existing themes and plugins used by millions of people
to be AMP-compatible. The other main focus area is
in the content creation side. Gutenberg is the new
revolutionary content creation experience in WordPress. It replaces half a
dozen inconsistent ways of customizing
WordPress, bringing it in line with the
modern code standards and aligning with
web initiatives. It also closes the gap between
the back end and the front end, offering an amazing visual
building experience. So Gutenberg has the concept
of blocks to build pages. And on the other side, AMP
has the concept of components, micro libraries to build pages. But what about combining
the power of both and build Gutenberg AMP blocks? And this is exactly what we did. And it opens the door for
amazing things to happen. We worked hard on pushing
the boundaries to take the native AMP experience
in WordPress a step further, leveraging all the latest
work done in the plugin, as well as a range of
custom Gutenberg AMP blocks. And this is what it looks like. What we’re looking at right
now is a WordPress AMP Gutenberg-powered theme. It’s inspired from
the AMP Start Travel, and all functionalities
that we see on the page is powered by
WordPress and Gutenberg. If we look at a
single adventure, we can see that we
are also leveraging some of the AMP components. For example, the AMP
carousel to slide through the images,
or the amp-bind to actually toggle the price. We are also using some of
the WordPress components, such as the comments,
to actually allow users to submit reviews. Or the WordPress search, to
actually search for adventures. And we can really see how
the content management system shines to manage
the adventures here. On mobile, it is the
same version of the theme and it looks just as
great out of the box. What we’re looking
at is native AMP, but it is seamlessly integrated. Once again, if we look at how
adventures are categorized, we can see that it is
pretty well-organized. And if we look at
a single adventure, we see other AMP components,
like the AMP YouTube, to make the user
experience better. So this theme is fast, right? Super fast. It’s actually secure and
seamlessly integrating. And it is pretty engaging,
which makes it perfectly aligned with the four pillars of a
delightful user experience. And what about the content
creation side of it? What about the content
creation experience that we spoke about earlier on? Well, let’s look
at how Gutenberg can be used to rebuild a
different version of the home page. What we have to do is
give the page a title. And then we’ll have
access to a set of blocks, for instance, custom blocks. By clicking on the
little plus button, it will open a drop down
with a set of blocks. And what we want
to do, for example, to rebuild our home page is
just click on under Hero block. And as we can see,
what we see immediately is that it resembles
the front end and we have access to
really cool things, like inline editing
to change the text. This is new in WordPress. And it’s pretty amazing. Let’s continue building our
page and add a Discover block from the latest three suggested
blocks, which is the most used. Right there, we have our
second block on the page. And we can continue
editing our page, for example, by
changing the subtitle. And let’s add one more third
block, the Featured Destination block. Once again, as we can
see, it pulls the content automatically. And if we were to reorder
these blocks to change the look and feel of the
page, we could just go ahead and click on the little
icon on the left-hand side, and boom, our block
has moved up and is now under the Hero block. This is a pretty amazing editing
experience from my perspective, at least. [APPLAUSE] Let’s preview what we’ve
just built in 30 seconds. A different version of
the homepage, native AMP with access of the amazing AMP
components and an amazing AMP content creation experience
powered by Gutenberg. So where we are today, the
0.7 version of the plugin was released last week. And 0.7 is really the first
step towards native AMP. It is more orientated
towards Power users to build themes from scratch. On the other hand, we
have the AMP plugin 1.0, which is still in progress. And that will include
the validation workflow we looked at today, the CSS
tree shaking, the core Gutenberg blocks made AMP-compatible,
and a range of custom Gutenberg blocks which integrates
the AMP components. What we have today is amazing. But the future is also
very, very bright. And for that, I would like to
invite Alberto back on stage to tell you more about it. Thank you. [APPLAUSE] ALBERTO MEDINA:
Thank you, Thierry. Oh, my god. That’s so exciting. I feel like I never saw it
before, but it’s awesome. So we have certainly
gone a long way on our quest to achieve
progress in WordPress, but we are not
where we want to be. There is quite a bit of
work that we have to do. And we are pursuing significant
efforts in three main areas. One is enabling the App Shell
navigation model in WordPress. You may have heard of it as the
App Shell architecture, which is an architectural
pattern to build sites in a way that is pegged
half-static sections that do not change across
navigation, we could cache them easily so
that when you navigate a page, they can be loaded very quickly
and provide a very nice onwards experience for the user. And the part of the
pages that are changing, that can be then
granted dynamically either on the client
or on the server. And what I’m excited
the most about this work is that it includes
the incorporation of the Service Worker’s API into
the WordPress core platform. I’m very excited about
this particular area. Another area has to do with– remember our progressive
web development model? We need tooling to
help developers to do complex things in an easy way. And one of those
areas is tooling to facilitate the development
of WordPress themes, progressive WordPress themes. I want to say a few more
words about this in a second. And the last part, which is
like an uber area has to do with ecosystem adoption, right? Because as you saw, WordPress
has a vibrant ecosystem of thousands of plugins,
thousands of themes, and we want to and need to work
with the WordPress community to push WordPress towards
the progressive road. There are many, many
projects that are here. And stay tuned for them. Now, our friends at
LinkedIn Learning have been working
very, very hard developing a progressive
theme boilerplate. Essentially, it is a theme
development starter kit that allows or makes it easier
for WordPress theme developers to go from zero to a full
progressive theme very quickly. So the boilerplate comes
loaded with modern development workflow. It’s highly configurable. It uses tools like Composer
and Gold, Browser-Sync. It comes with a range of
coding and performance best practices baked in
so that, for example, asynchronous loading of
resources is by default, lazy loading of
images is by default. And it has an opt-in
AMP plugin integration, so that if a theme
developer decides to have an
AMP-compatible theme, he can switch a flag,
and voila, you’re going to get an AMP-compatible
starting theme from the get go. So the main developer
of this project, which is Morten
Rand-Hendriksen, who is also a staff instructor
at LinkedIn Learning is preparing an
awesome course that is going to teach you
everything about how to use this boilerplate. And that particular
code is going to be free, so don’t miss out. Another thing. If you can take three
things from this talk are the following. Success in the web is all
about user experiences. Building delightful
user experiences. To do that, we need
to strive to close the capabilities/usage gap. It should be easy to do
the right thing in the web. And the topic of today,
it is possible today for WordPress developers to
get native AMP experiences without sacrificing the fidelity
of their site, of the content, or the flexibility of
the WordPress platform. Remember those three things. And if you are a
WordPress expert, you like to code
quite a bit, and you are passionate about making
the WordPress ecosystem better and the web better
as a whole, you may consider working with
us exactly on doing that. And with that, I
want to thank you. There are some useful
resources here. And I want to extend
a special thanks to Weston Ruter, the whole
XWP team, and Automatic for all the awesome
contributions to this work. And I’m very looking
forward to what we are going to achieve
in the coming months. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *