Fast by default: AMP powering WordPress (AMP Conf 2018)
Articles Blog

Fast by default: AMP powering WordPress (AMP Conf 2018)

August 11, 2019

so my name is Alberto. I work in the web content
ecosystems team at Google. And we’ll tell you
in this session how it is possible
today for publishers to take advantage of
the benefits of using AMP when they are publishing
content with WordPress. But first, let me
put this work– this was the first slide. Let me put this
work in the context of what my team at Google does. So if you think about
what an ecosystem is, basically, it’s a community of
interacting parts and organisms and their environment. And the important thing
here is that every member of that ecosystem is important
to all the other members. So you cannot get rid of the
trees and then have birds, for example. So that’s a big deal with
global warming, right? So this is the essence
of what an ecosystem is. And the same happens
with content ecosystem. A content ecosystem is a
community of content creators and content consumption
participants interacting between themselves
and their environment. And there are many of these
content ecosystems in the web. And I like to think about
the web as a federation of these content ecosystems. And for the purpose
of my theme, there is one important thing, that is
all these ecosystems share one goal– the experience that the users
get when accessing, consuming, or publishing content
in those ecosystems should be an awesome experience. And since AMP is all about
achieving an awesome experience for all users, we are
interested in seeing how can we bring the power
of AMP through as many of these ecosystems as possible. So one of the most relevant
content ecosystems arguably– and we’re going to see why– in the web today is WordPress. WordPress, I can define
it as a content management system for websites. And as Malte said, it was one
of the earliest adopters of AMP. Historically, when people
hear the word WordPress, usually they used
to associate it with a platform that
enables bloggers to publish their content in an easier way. But WordPress has
been evolving steadily since it started back in 2003. And now it basically
powers websites across a wide
variety of verticals. You name it– blogging– the initial one– travel,
education, real estate, you name it. So it’s a very, very powerful
platform in this sense, and it’s reflected by definitely
the largest content management system out there right now, with
59% of the open-source content management systems market share. So that’s impressive. And what is more impressive
is that nowadays, a third of websites are
powered by WordPress. So these stats are
very, very impressive. But again, they
tell me one thing. So a third of the web
is a lot of the web. So there are many, many,
many, many, many users both publishing and consuming
content via WordPress. And my goal is
all of them should get an awesome experience
when they are doing that. So one of the major strengths
of the WordPress platform is the flexibility
that it offers. And that is reflected by a very,
very large and ever-expanding ecosystem of plugins and themes. So there are this many
on each of those sites. You can use themes and
plugins to basically customize your WordPress site
in a myriad of ways, in any way you can imagine it. Now, this virtue
also can be turned into one of the major challenges
of the platform, right? Because even if you take
into account plugins that are coded perfectly, that
are very performance, and they behave
nicely, the probability of having two
plugins or more that collide when installed at
the same time in a site or affecting the performance
of a site is not negligible. And what I like to think about
this duality between a virtue and a challenge, it is parallel
to the virtue and challenge in the open web. So in the open web, nothing
prevents a developer to basically screw the
performance of a site by following development
practices that are counterproductive, like
loading scripts synchronously, or not optimizing email,
some things like that. And even if the developer does
an impeccable work and codes a site that is extremely
efficient and optimized, installing one
third-party JavaScript could spell a performance
disaster for the site. So if you think about it,
AMP emerged as a response to that reality in
bringing to the ecosystem a set of design principles
and control mechanisms that allow us to
create sites that offer predictable performance. And since both AMP and
the output of WordPress are just web content,
WordPress publishers can also benefit
from the power of AMP in order to offer predictable
performance on their sites. So when we talk about
AMP in WordPress, we basically talk
about two things. One, if the capability
is enabled by a plugin and also the integration
of that plugin with the other
components of a site, like the underlying theme
and the other plugins that provide functionality
for whatever the site does. So the plugin, as Var
mentioned, the plugin work for enabling AMP in WordPress
was pioneered by Automattic. And it was developed to
satisfy the needs of– probably you have heard
about the VIP platform. The VIP platform is a
fully-managed cloud platform provided by Automattic. And basically, they offer full
solutions to their clients. They offer support,
customer advice, and so on. And the interesting
thing for me is that it has a diverse partner
ecosystem around them. And there are basically
two type of partners. There are agency partners. That is where most of the
advanced WordPress development takes place. And then there are
technology partners that basically team
up with Automattic to integrate technologies
to the VIP platform. Google is one of those partners. For example, if you want
to integrate, I don’t know, Google Drive to
the VIP platform, then will be qualified
as a technology partner. Now, the plugin definitely
satisfies the need that they set for themselves. For the VIP platform, they
report around 700 million page views per month both across and the VIP platform. And the plugin also
has been adopted at a relatively good size,
more than 200,000 installs. And it also has been used
as the core of other plugins that have been built around it. But thinking about the
initial goals of the plugin, that it was basically to satisfy
the needs of the VIP platform that usually have agency
partners working with them, the characteristics of the
initial plugin implementation makes sense. Basically, it’s a
developer-oriented plugin. Basically, it offered
minimal functionality with a set of core abstractions
that enable AMP, but then allow developers to extend
and customize it to satisfy the needs of specific sites. But that means
also that for sites that do not have strong
engineering support, the plugin was very difficult
to adopt because you get pages that I’m going to show you in a
second that makes it difficult. Basically, as Barb
mentioned too, the plugin enabled
millions of pages in thousands of
sites in WordPress. And on the AMP side, we
heard a lot of feedback about regenerated pages. And most of the feedback
that we heard was like, well, but all the AMP
pages look the same, and they look a little bit lame. So here on the left, we
have the canonical site, the original content. And on the right is a
page that was generated using the plugin version 0.4. And here you can
see two problems. One is that it doesn’t matter
how the page on the left looks like, the
page on the right is going to look
pretty much like this. And on the second
thing, basically, that’s what I call a visual gap. So there is a little
difference between them. And then you see,
for example, here, there is not the hamburger menu. The Load Updates button
is not present here. And there is a lot of
functionality that is gone. And the reason for this is
that you can take this output, tweak the plugin, and
then make it look nicer. But if you don’t have
the engineering support, then you cannot do it. And your pages are
going to look like this. So Google and Automattic
started collaborating around mid-last year with the
purpose of taking the plugin and evolving it to a point
in which, basically, it can be adopted at scale. So we started working, and
we released version 0.5 a little while after we
started collaborating. And this release brought
support for new embeds– for example, Vimeo,
SoundCloud, Pinterest. The original version
of the plugin used a blacklist
sanitizer, or preprocessor, that basically takes– you had to get rid of
things that are not AMP. We changed it for a preprocessor
that adds a lot of intelligence to it and also allows the plugin
to stay in sync with AMP’s specification. So every time that the
AMP projects evolve, the plugin stays up to date. We did code and
documentation improvements, and we added a basic UI
and analytics to the sites. After we finished that,
we were all pumped up. OK, so let’s move towards
the path to getting an all-AMP experience. And by mere chance, somehow we
came across the awesome folks with the XWP engineering
team, and we started talking. Yeah, we are doing this. We are doing that. And it turned out that we
shared a lot of our visions, and we decided to
start working together. So we joined forces
together with Automattic. And not long after our
collaboration started, we released 0.6. And the 0.6 is loaded
with a lot of new things that I’m very excited about. I’m going to show each of them. Here, for example, you can see
before, in the previous version of the plugin, you could
only preview the latest post that you were working in AMP. If you wanted to see how
the AMP version looked, you can only preview
the last post. And the preview
functionality was separate from the integrated
or the normal workflow in WordPress for
doing the previews. Here, you can see this is just
a regular WordPress workflow, and now you can see that
you can preview the changes in the normal WordPress. And next to it, you
have the little AMP icon that says, OK, preview how
the AMP version looks like. So this is pretty cool because
then the developer doesn’t have to leave the normal
workflow in WordPress to see how AMP is behaving
or what the version of AMP is looking like. The other thing is that the
initial version of the plugin only supported the
post content type. In WordPress there are
different types of content that you can create. Post content type
is one of them, and it was the only one
supported by the plugin. In this version, we
added support for pages. That was one of the
things that the community was asking the most– we need support for pages. Here there is not much to
show, only that this is a page. And then it’s been
converted to AMP. And the other thing
that we added is– because the plugin
was evolving, we wanted to give the
user the power to say, for this particular
piece of content, I want AMP to be disabled,
for whatever reason. They have a
functionality that is not supported for any reason,
so they have now the ability to say, for this particular
post, disable AMP, or vice versa. You can see there’s
a opt-in, which is actually very good to give
the users the capability. Although, you’re going
to see soon that this is not going to be needed,
and it’s very nice. Thierry is going to
tell you all about it. And another thing that was
very cool is also in WordPress, you have the ability
to create what is called custom post types. You can create your own layout,
and you define a content type that you create. And before, in the initial
versions of the plugin, in order to add AMP
support for them, you had to go to the code– like in the lower
side of this slide– and you had to
manually say, OK, I’m going to put this specifically. I want AMP support
for this content type. Now, on the upper part,
you see now you can do it. In the 0.6 version, you
can just click and say, I want AMP support for this
post content type, and so on. So this is very good because
it adds a lot of flexibility and don’t require the
user to go to the code. Now, besides those, the
0.6 has many other things. We added autoloading
capabilities that basically allow us
to simplify the code, because you don’t have to
be including all classes and interfaces manually. We integrated the AMP customizer
with the regular customizer in the regular
WordPress workflow. This is important because in
the content ecosystem team, one of the things
that we want to do is to bring coding and
performance best practices to the WordPress ecosystem. And we are applying those
principles in the plugin by adding a lot of code
quality checking in the build process of the plugin itself. And the 0.6 version also
enhanced the preprocessor a lot, added a lot
of intelligence, and actually fixed some bugs
that prevented the plugin to be actually completely
in sync with the AMP specification. Now, since the beginning
when we started this work, we had our sight in an all-AMP
experience in WordPress. We can call it native
AMP or all-AMP. And it’s an experience in
where no paired mode is needed. If there are no visual
gaps and no functional gaps between the regular version
and the AMP version, then you don’t
need two versions. And I want to invite Thierry, my
colleague and friend from XWP, to tell you the
progress that we have made towards this goal with
version 0.7 of the plugin. [APPLAUSE] THIERRY MULLER: 0.5 and 0.6
included great features, no doubt about that. But like any early
versions of softwares, it also came with
its limitation. And by that, I mean until today,
the WordPress AMP plugin only converted certain type of pages. Imagine a user coming
from Google Search and landing on a
WordPress AMP article. What they would get
is the default styling that the WordPress
plugin provides. And that would be the same
across all WordPress websites which uses the AMP plugin. Not only that,
but when this user is done reading the
article and goes and clicks on the logo to
go back to the home page, then they land to
a non-AMP version, which provides a completely
different visual experience. And that is because until today,
the 0.6 version of the plugin did not convert the
home page by default. Now, we’ve thought
with the team, how can we come over
these limitations? And we brainstormed, and
we came to the conclusion that we needed to combine this
non-AMP version of the website with the AMP version into
one beautiful native AMP experience. When building beautiful
WordPress websites, users and site
owners have access to large built-in libraries
of components, the WordPress components. But these are not
all AMP compatible. Now, these obviously
expose great challenges. And what we wanted to do is take
the power of these WordPress components and
make sure that what powers one third of the
web today is AMP-valid. And in order to
achieve that, we had to completely rethink the
way the AMP integration in WordPress was done. Well, I’m so proud to announce
that through collaboration with the Google
AMP team, as well as our friends at
Automattic, we overcame these challenges and that via
the new version, 0.7 beta, of the WordPress AMP plugin. Not only does it convert
all WordPress components and make them AMP-valid, it
also allows WordPress developers to continue coding
the WordPress way and let the plugin do the rest. And I think the best way
to put this in context is to actually look at
a real world example. Before we do that, we’re
going to look at the website without the AMP plugin. Now, this is a
beautiful news website. And it’s a non-AMP website. And it has a fairly complex
layout with the drop-down. And on the right,
we have a search, which animates on click. And of course, this website
looks beautiful in mobile with the hamburger menu. Nobody knows why
is it hamburger, but everybody
knows what it does. Now, at this stage,
before 0.7, people would install the 0.6
version of the plugin, and what they would get when
they activate the plugin is the same-looking home page,
a non-AMP version of the home page. And then they would have
the same non-AMP version of all the articles,
and on top of that, another version with a
completely different styling. Now, with 0.7– and we’re
going to activate the plugin in the Admin– we were able to provide
this native AMP experience. And let’s look at the
same website again. This is native AMP in WordPress. [APPLAUSE] We still have our drop-down. We still have our search. The mobile looks as
beautiful, and we see the AMP live list in action,
allowing us to click and see the latest article. And we obviously still
have our drop-down. And while developing this,
sometimes I found myself wondering, am I on the AMP? Is the plugin activated? And look at the console– powered by AMP. Passing validation indeed. And to give you an
idea of the speed that this website is providing,
what you’re seeing right now is me browsing the website
and just recording my screen. That’s what we’re getting out
of this WordPress website. Now, let’s recap. There is no longer a
need for paired mode. There is only one beautiful
version of the website. There is no longer a need to
maintain two versions of it. And then from a
development perspective, people or companies– like
we have heard “The Washington Post” early on– don’t have to put this hard
work into converting WordPress components and make
them AMP-valid. It is done out of the
box with the 0.7 release. I mentioned early
on it doesn’t only convert the AMP components. It also allows
developers to continue coding the WordPress way. And what we see on the screen
is a typical WordPress snippet that we would find on any
WordPress website today. And what it does is it
just tells WordPress, please anchor your
stylesheet in my HTML head, like we see on the
screen right now. Now, obviously, linked
stylesheet are not AMP-valid, and WordPress developers
would have to convert that into inline CSS the AMP way. And now there is
no longer a need to do that because
with the plugin, it’s done automatically. And we can see the
difference here. WordPress developers do
not have to change the code snippet we saw early on. The AMP plugin
does that for them. And it prints the CSS
inline the AMP-valid way. Now, we didn’t stop there. We want to make it better. And we are working
on a prototype which analyzed the HTML DOM and
compares it with the CSS that’s loading on the page and makes
sure that only the CSS needed for this page is printed in
the custom style HTML tag. Now, that really much aligns
with the AMP philosophy of keeping CSS
under 50 kilobytes. As I mentioned
early on, WordPress is made out of
multiple components. And one of the
components are widgets. They are small
blocks that users can place in the websites
in multiple areas. And if we look at the
back end of WordPress, we’re dropping a gallery
widget and selecting images, which is the standard
WordPress experience. And we are going to be adding
this widget in our sidebar and change the categories
widget to be a drop-down. And you’ll see why now. So when we look at the
front end and we scroll down to our sidebar, this is
without the AMP plugin. There is a list of images, and
if we inspect the drop-down, we’ll see there is
inline JavaScript. And this JavaScript is
obviously not AMP-valid. And instead of developers
converting that by themselves, we activate the AMP plugin,
and the first thing we see is that we have a
beautiful image gallery. And that’s leveraging the
amp-carousel component, of course. And then for the
JavaScript issue, that has been replaced with
the amp-bind component. And that allows users to
just select a category and get the expected behavior. Now at XWP, while working on
some of the major publishing websites in the world, we have
identified that very often they end up replacing the
WordPress comments with alternative solutions. And we believe that
one of the reasons is because out of the box, the
WordPress Comments experience is aging a little bit. It’s requiring the
page to reload. And while converting
these WordPress components to be AMP-valid, we also wanted
to improve the user experience by leveraging some of
the AMP components, such as the amp-mustache,
the amp-form, the amp-bind, or the amp-live-list. So on the page, we’re
going to scroll down to the list of
comments, and I’m going to add a very useful comment,
very good feedback, as usual, my name and email. And then when I
post the comment, then the amp-mustache
displays the success message. And the amp-live-list
goes and fetch the comment in the
back end and tell us immediately there is a new
comment, which I can obviously click on. And then we scrolled up,
and we see the new comments. We haven’t left the
page, and developers didn’t have to do anything
on this theme other than wrapping the
core comments function with the amp-live-list HTML div. They get that out of the box,
this new WordPress Comments experience. Now, we have seen the
style conversions. We have seen the widgets. We have seen the comments. But 0.7 includes a
lot more than that. Pretty much all the
WordPress embeds are now converted
to be AMP-valid, leveraging some of
the AMP components, such as the amp-facebook,
amp-twitter, amp-video, and so much more. WordPress core components
are predictable. We know what to
expect from WordPress. And so we could easily
convert that to be AMP-valid. But with WordPress powering
one third of the web and a huge ecosystem of plugins
and custom integrations, it’s really difficult
to predict what’s going to be rendered on the page. And while this will be part
of the future phases, what we wanted to make sure of is
that anything which is rendered on the page is AMP-valid. And for that, we took what
was before the sanitizer, and what we would want to
call it, the preprocessor, and it essentially
takes whatever is rendered on the page,
puts it through a funnel, and outputs it in
an AMP-valid way. While doing that, we
obviously saw an opportunity to make things even better. And since we had access to
this rendered or this output, we thought, why not
automatically include in the AMP components? On this page, we
see at the bottom it uses four AMP components. And under this content,
we’ll add a code snippet using GitHub gist. In the back end, we’ll
just use our snippet. And when we reload the page,
if we look at the console right now, we can see that
the amp-gist component in JavaScript has already
been added to the page. Without the AMP
plugin, site owners would have to call developers
and say, hey, on page ID 54, I’m using a gist snippet. Could you please add
the gist component? And that’s no longer needed. During the panel talk,
there was a question about, what about the content
creation experience? Well, now we have turned
WordPress to be WordPress AMP. But we also wanted the
people editing the content to be made aware when they
actually add something which is not AMP-compatible on the page. And that was really tied with
the editorial notification of the editorial workflow. So in the WordPress
Admin, we see that there’s a script tag
and an onclick event which is not allowed in AMP. And if we save
the draft, then we see there is a
notification saying, hey, this content will
fail AMP-validation. It will be stripped out
anyway, but you should really remove it. And then we remove the event
and the disallowed script, and when we save again,
the notification is gone. So editors in
WordPress now know when they’re doing something wrong. And the technology base behind
that is actually quite cool. It is using the preprocessor. And we have a prototype
using the WordPress REST API to which we can
send content to, and it gives us a report of
what the preprocessor has stripped out from the HTML. That will open the door
for so much and so– and actually, even outside of
the WordPress context, also maybe other people
using this API endpoint. And that would also
allow us to inform users when some of the plugins may not
be good citizens at this stage. And they will be one day. When doing such improvement
on an existing software, backwards compatibility
comes in mind, of course. And that’s really dear to
the WordPress community. It’s really dear to us as well. Well, 0.7 is 100%
backwards compatible. And that is because to get
this new native AMP experience, themes have to add one line
of code telling the plugin, hey, I’m AMP native ready,
or native AMP ready. And if they don’t do that,
then the legacy paired mode will just be rendered as usual. So site owners can upgrade
to 0.7 with the peace of mind that their website
will not break. Now, before I continue,
as you would imagine, this is a huge step forward. And it has taken a tremendous
amount of work to get there. And I would like you to
give a round of applause for the team who has put in
an outstanding job to do that. [APPLAUSE] This is not like any release. This is a huge step forward
for the WordPress world and actually for anybody trying
to create native AMP websites. This allows WordPress to
now power these websites. And I haven’t spoken much
about Gutenberg and more stuff, really exciting stuff, coming. And for that, I would like to
invite Alberto back on stage to tell you more about it. ALBERTO MEDINA: Thank you, man. Super exciting. [APPLAUSE] I’m so excited about this
that I can’t hide it. So I’m glad that you mentioned
Gutenberg because it’s a thing that we want to do. As I mentioned before,
the WordPress platform has been evolving steadily
since the beginning. And the latest thing
that is coming for them is Gutenberg, which is
a new content creation experience that is going to
be rolled out, if I am not mistaken, with WordPress 5.0. Basically, Gutenberg
is based on the concept of blocks for content creation. Right now in
WordPress, if you want to create different
type of content, you have many ways to do it. You have shortcodes. You have embeds. You have custom post types. You have meta boxes. You have widgets. You have many ways to do things. With Gutenberg, everything
is going to be a block. So I believe that
Gutenberg is going to revolutionize the
way that WordPress is used because we
want to streamline the creation of content. And because of this
notion of blocks is at the core of
Gutenberg, I think that there is strong synergy
between AMP and Gutenberg. And let’s see why. This is an example of
Gutenberg in action. Basically, everything
is a block here. We see that you have different
blocks for layout, formatting, standards, and so on. So for example here,
let’s create an eMatch. You can go select it
from the media library. That’s it. And that’s a block. And then here you can create a
paragraph that is also a block. And so now we can
create an embed. Let’s suppose that we want
to add a Tweet to our post. So you put the URL,
and boom, that’s it. And here on the
right side, you can see that there is the
block section there to see how the
block is configured that you can see how the
block is laid out and so on. And then Gutenberg
is extensible. It comes with these
blocks, but you can say, well, let’s add
new blocks to the editing experience. Let’s suppose that I would like
to add a lightbox to Gutenberg. So a lightbox is
this functionality. I click, and that appears. If I want to do it
the standard way, I’m going to have to do
the declarative part, and I also have to then
put the JavaScript that supports that functionality. But what about if we use
AMP components to create Gutenberg blocks? The only thing that we
would have to do then is to do the declarative
part, and AMP is going to take care of all the rest. So it’s going to be much easier
to create Gutenberg blocks. So definitely
Gutenberg is one thing that we want to do, full
integration with it. And remember that I am part
of the content ecosystem team. So the work that we’re
doing with the AMP plugin is in the bigger context of the
WordPress ecosystem as a whole. So we are going to continue
working on the AMP plugin to reach as close as possible to
this native all-AMP experience in WordPress. One of the things that I am
excited about is what André talked about, server
side rendering for AMP. We are going to port the code
that they wrote to PHP and put it also as part of the
functionality of the plugin so that it can be
integrated then with WordPress caching plugin so
that the AMP pages are already rendered. So that’s something that is
going to be very powerful. Now as I said, in
WordPress, you have plugins, and you have themes. So there is a lot
of work that we want to do in the area
of themes to create what I like to refer to as
progressive themes, that are themes that integrate coding
and performance best practices, enable all the new technologies
of the web platform, and also integrate seamlessly
with the AMP plugin. I mentioned Gutenberg
integration. It’s a big deal. We want to continue
working on that. And another project that we are
working coincidentally with XWP folks as well is called Tide. And Tide’s important
because we need to empower WordPress
users to make decisions about which plugins
and themes to use based on concrete
quality metrics, not only on popularity. The Tide project is
seeking to do that. And also we want to
use another project that we are spearheading
at Google that is called the HTTP Archive. We want to keep track of the
performance of the WordPress ecosystem, as we
do things to it. So like, how is the
performance today? How do we evolve it? It’s important to keep track
of how things are progressing. And also, we want to continue
engaging with the WordPress community in general, with
theme and plugin makers, and everybody in the
community to make sure that the whole plugin ecosystem
is compatible with AMP. There is still quite
a bit of work there, but I think that it is
very doable with the work that we are laying out. One particular collaboration
that I would like to call out is with a company that
is called Marfeel. Marfeel is a very good
company based in Spain. I think that they have
around 80 engineers. And they have been
involved with the AMP project for quite a bit. And they have done
contributions. And one of the particular things
that I’m very interested in is a plugin that they built
that is called Marfeel Press. Marfeel Press is a plugin that
was built on top of the AMP plugin that we are working on. And it offers progressive
web app capabilities to WordPress sites. Basically, they implemented
the AMP shell model on top of the shadow
API, which then allows WordPress publishers to use
AMP as an embeddable data unit, which is one of
the most powerful things that I like about AMP. You can take it and
embed it anywhere. So we want to have
that capability ubiquitous in WordPress. That’s something that
there is a lot of room for us to collaborate. They did a lot of things. They also have this
what-you-see-is-what-you-get experience that
they implemented. So that’s something
that is very exciting. So certainly the development
of AMP in WordPress has come a long way
since AMP started. And I want to, again,
acknowledge the XWP team that has done a
superb job with us and also the
collaboration that we have with several teams at
Automattic, like the Jetpack, the themes team, the VIP team. So it’s very, very,
very remarkable, the work that has
been happening, and I am really looking
forward to the future. Thank you. [APPLAUSE] [MUSIC PLAYING]

Only registered users can comment.

  1. That was an interesting talk, Alberto & Theirry!

    This comments feature is pretty sick! ✅
    I wish we could use these features progressively instead of having to go all in — from the very first day — since my sites have lots of JS that’ll need to be taken care of.

    P.S. I can see my comment in the talk LOL @ 24:37 🙂 was just testing the theme. Surprise!

  2. I have to say v.7 is a massive leap forward in WordPress AMP usability. Overcoming the stripped down orphaned post issues caused by the initial plugin release is a huge win.

    We've been building our own AMP WordPress page builder framework for the past two years that has been focused on AMP only pages with a similar option to create non-AMP pages/posts when the end user wants to use an embed that is non-AMP compliant. You can see a couple example sites (AMP pages, posts, custom posts including recipes with full schema markup, as well as video, commenting, and Mailchimp form submission integrations) (AMP pages and posts, video, commenting, social sharing, form submission and ad network support.)

    We're currently working on AMP compliant Woocommerce stores, which should be available in March.

  3. i don't watch this whole least for now..
    and i am wondering..
    AMP is google initiative..
    how about "blogger"?

  4. I loved the plugin but how add ads to it!! The one by Khaled is lot easier ! but still I want to use the WordPress official plugin ! plz do reply if any1 has the answer

Leave a Reply

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