New in AMP stories: Monetization, Revamped bookends and Metadata

We announced the developer preview of AMP stories in February at AMP Conf. Since then, publishers have authored thousands of stories, experimenting with the format and providing valuable feedback to the AMP team. Based on this input, we recently released new capabilities in AMP stories v1.0, open to all developers without origin trials or a whitelist. New features include:

Version 1.0 of AMP stories includes these updates and is available today. Upgrade your existing stories to v1.0 using our migration guide to take advantage of the new features.

Stay tuned for more developments in the coming months; you can see the full roadmap here. The team is actively working on additional features including:

As always, if you have feedback, please let us know on Github. We look forward to seeing more publishers try AMP stories!

Posted by Jon Newmuis, AMP Stories Lead Engineer, Google

New in AMP stories: Monetization, Revamped bookends and Metadata

Serverless AMP solution on AWS

Editor’s note: The following was originally posted on Medium by Artūrs Krūze, CEO, Magebit. You can see their site featured on the showcase page of

It all started when we realized our website gets outdated very fast and we are always so busy with our customers we forget about ourselves. We had to build something amazing.In case you are not familiar with the terms serverlessAMP and AWS — click on the words and learn more.

The technical

Everybody loves fast pages and most of our visitors are on the go — that is why we selected AMP (Accelerated Mobile Pages). We also wanted to make sure our website can handle unexpected loads, requires minimum infrastructure maintenance and is very fast — so why not go with a serverless infrastructure?

Serverless AMP solution on AWS

The above is just the infrastructure part. The website still needs to be generated, deployed etc. For that we used what we call the generator.It is a system built on Laravel which is a regular non-serverless site with 1 extra feature — generating the website frontend code. The generator also takes in the standard (non-AMP, non-minified) code and makes it fully AMP and minimized to the limits. In the end we have a fast lightweight site ready to be deployed.The deployments are automated with Jenkins. From generation and file uploads to cache invalidations — all done with a single click.

The visual

Usually, AMP pages are too minimalistic and don’t look good. We stepped in to change that. Our goal was to build a lightweight AMP page that looks good and works amazingly — and we achieved that!

There were a lot of tricky parts where we understand that with javascript it would be easy but with CSS only it is tough to do. Also, there are different sizing limits (also for CSS) so we had to work hard to keep the styles size tiny. Despite all that we made all the functionality and look as per designs. There was no place where we gave up and went with a simpler solution.

The amazing

At least that is what Google PageSpeed says about us. The infrastructure is very simple, nearly bullet proof, very easy to maintain and search engines love it. Oh, and it is not just loved by some robots and computers — it is also loved by everybody here at Magebit.

It’s a pity that AMP doesn’t allow to host AMP JS file elsewhere or have proper cache headers. This is the only reason we couldn’t reach 100/100 in Google PageSpeed. Changing the AMP JS host to our CDN gives 100 points but throws a console error that the AMP source is not Google’s. Sad, but we’re still happy we reached the maximum possible score with AMP.

Another amazing fact is that the engagement and visibility in Google search grew in a lightning speed after the launch of this AMP website. The average time on site for users doubled (from ~1 minute to ~2 minutes) and our tracked keyword visibility jumped from 0.5% to 8% — that’s 16x more than we had without the AMP site.

We’re ready for new challenges

Ever wanted to have an awesome website that is lightning fast, easy to maintain and performs amazingly? Great! Let’s get in touch to discuss the details. We will make that happen. Check out the site mentioned in this post — or just shoot us an email to

Posted by Artūrs Krūze, CEO, Magebit


Serverless AMP solution on AWS

amp-date-picker is launched!

Earlier this month we announced a limited release of amp-date-picker, a calendar-style interactive date picker for form input. With this component users can specify single dates or date ranges with a calendar interface that makes the process faster and less error prone. After a great round of feedback from developers trying it out on their pages, we’ve fixed a number of bugs and added some feature requests, like the ability to quickly toggle the current date. With these updates, the date picker is now fully launched to production.




Check out the sample on AMP by Example to see how to use it and what it can do. As always, let us know if you have any feedback for amp-date-picker, or for any other feature gaps in AMP. We look forward to hearing from you!

Posted by Eric Lindley, AMP Product Manager

amp-date-picker is launched!

Announcing the AMP Contributor Summit

We are happy to share that the first AMP Contributor Summit for developers in AMP’s open source community will be held in San Francisco, California this September!

The summit will take place from September 25-26, with an optional New Contributor Day on September 24th that’s especially for people new to contributing to AMP.  If you are a developer who contributes to AMP–or a developer who wants to start contributing–please apply to attend!

The AMP Contributor Summit will bring the AMP open source community together in one place for the first time.  The summit will provide an opportunity for the community to:

  • Meet each other in person.
  • Share the latest knowledge about developing in AMP–from relevant web technologies that are important for AMP contributors to know to how-tos on AMP architecture.
  • Enjoy deeply technical talks about the internals of AMP and how they could change in the future.
  • Review what we’ve accomplished in AMP so far and discuss what AMP’s priorities should be going into the future.

The main summit takes place on September 25th & 26th.  These days will feature talks, breakout sessions, hacking–and plenty of breaks and opportunities to meet other developers in the community.

On September 24 we’ll have an optional New Contributor Day to get new contributors up to speed on contributing to AMP before the main summit starts.  This day of talks and codelabs is meant for people who want to contribute to AMP but who haven’t yet started.

The talks at the summit will be given by people in the community.  If you have an idea for a talk you would like to give at the summit please submit a proposal for a talk by July 31, 2018.  Please note, that this is a technical summit and don’t worry that your talk might not be polished enough. We’re excited to hear from everyone!

See the AMP Contributor event page for more information and to apply to attend.  We hope to see you in September!

Posted by Joey Rozier, AMP Engineering Manager at Google

Announcing the AMP Contributor Summit

Contributing to the AMP Project

Editor’s note: The following was originally posted by Adam Silverstein, Lead Web Engineer at 10up on the Google Open Source Blog.

I started my web career building websites for small businesses on WordPress, so when I decided to begin contributing to open source, WordPress was a natural place to start.

Now I work at the digital agency 10up, where I am a part of our open source team. We build popular sites like FiveThirtyEight where having the best possible AMP experience is critical. However, bringing FiveThirtyEight’s AMP version up to parity with the site’s responsive mobile experience was challenging, in part because of advanced features that aren’t directly supported in AMP.

One of those unsupported features was MathML, a standard for displaying mathematical formulas on the web. To avoid a clumsy work around (amp-iframe) and improve our presentation of formulas, I proposed a native `amp-mathml` component which could display formulas inline. Contributing improvements “upstream” to open source projects – especially as we encounter friction in real-world projects – is a core value at 10up and important to the health of the web. I expected that I could leverage the same open source MathJax library we used on the responsive website for an AMP implementation. Contributing this component would strengthen my understanding of AMP’s internals while simultaneously improving a client site and enabling the open MathML standard on any AMP page. Win, win, win!

I started by opening an issue on the amphtml repository, describing MathML and proposing a native `amp-mathml` component. Justin Ridgewell from the AMP team immediately responded to the issue and asked Ali Ghassemi to track it. I offered to help write the code and received an enthusiastic response, encouraging me and assuring me that the team would be available on GitHub and in Slack to answer any questions.

This warm welcome gave me the confidence to dive in, but ramp up was daunting. The build tools and coding standards were quite different from other projects I work on and setup required some editor reconfiguring and reflex retraining. Getting the unit test to run on my system required tracking down and installing some missing dependencies.

Fortunately, AMP’s project documentation is thorough, and Ali guided me through the implementation, pointing me to existing, similar samples in the project. I already knew how to use JavaScript to render formulas with MathJax – my challenge was building an AMP component that ran this code and displayed it inline.

After a few days of concerted effort, I built a proof of concept and opened a pull request. The real fun began as I refined the approach and wrote documentation with help from the team. The team’s active engagement helped the process move along rapidly. Amazingly, the pull request was merged one week later, and today amp-mathml is live in the wild. FiveThirtyEight is already using the new, native implementation.

From opening the issue all the way to the merge of my pull request, I was impressed by the support and encouragement I received. Ali and honeybadgerdontcare provided regular reviews and thorough suggestions on the pull request when I pushed iterations. Their engagement throughout the process made me and my work feel valued, and helped me stay motivated to continue working on the feature.

Adding MathML to AMP reminded me why I find so much joy and professional growth in contributing to open source projects. I have a better understanding of AMP from the inside out, and I was welcomed into the project’s community with wide open arms. I’m proud of my contribution, and ready to tackle new challenges after seeing its success!

Posted By Adam Silverstein, Lead Web Engineer at 10up, and AMP Project contributor

Contributing to the AMP Project

The Shadow Reader, Improved

We made the Shadow Reader even faster – and friendlier to search engines!

We created the Shadow Reader to demonstrate how AMP pages can be used within a Progressive Web App (PWA) (read our announcement post for more context). The site repurposes existing articles from The Guardian into an immersive news reader experience. More than just a demo, it’s intended to be a fully functional site. It contains the end-to-end code needed to effectively combine AMP and PWA… it’s ready for production!


SEO for JS-generated content

As in any self-respecting single page application, the Shadow Reader’s initial HTML payload is small. It’s a thin app shell that loads quickly, giving the user something to look at while JavaScript loads the main content. This approach makes for a fine user experience!

Unfortunately, it can also present a challenge to search engines. Google will try to execute JavaScript in order to index what ultimately appears to the user, not just the initial HTML. But many search engines don’t or do so unreliably. In other words, it’s not safe to depend on a search engine to successfully execute your JavaScript. And if a search engine sees only the app shell, minus most or all of the content, it won’t be able to properly index the page.

Wouldn’t it be nice if the Shadow Reader’s article pages were served to search engines with text included right in the HTML?  And wouldn’t it be amazing if that process didn’t slow down rendering, but instead gave us a way to serve those pages to new users in less than a second?

Turns out we can do both of those by serving the AMP version of articles to new users!  After all, a web crawler appears to a server as a new user, too. So… how did we do it?



We did this by implementing an AMP⇒PWA pattern. Here’s how it works!

For a new user:

  • When a new user visits an article page, we serve the AMP version of the article.
  • The AMP uses <amp-install-serviceworker> to load and install the service worker.
  • The service worker loads and caches the app shell.
  • On the next page navigation, the service worker is in control – and so it gently brings the user into the PWA on that next page.

For an existing user, we simply serve the PWA.

That’s how our site can treat new users and existing users differently at the same URL. For existing users, the service worker is installed. And, when the service worker sees an article URL, it serves its cached version of the PWA.

How does this play out in the Shadow Reader?  Let’s say a user first visits this article page:

Seeing an article URL, the server returns the AMP version of the article, but one that installs a service worker when the article is loaded. The service worker, using the Workbox library, contains this line:


This means, whenever the user navigates to a new URL on this domain, the service worker sees that request, and instead of passing it along to the server, it simply serves its cached version of index.html. That’s our PWA.

So if the user next clicks on a link to

the service worker serves the cached PWA HTML. But the URL is unchanged!  So when the PWA looks at the URL to parse out what article is being requested, it sees the link the user requested, and it can load the proper article into the PWA.

Thereafter, any time the user requests a Shadow Reader link, the service worker is already installed, and it serves the cached PWA.

Since a web crawler won’t allow us to install a service worker, a web crawler always gets served the AMP article.


Here’s that flow in a lovely diagram:

For a new user:

  1. The browser requests an article URL from the server. The server returns an AMP version of the article that includes <amp-install-serviceworker>.
  2. AMP’s serviceworker JS causes the browser to request the service worker. The server sends the service worker JS to the browser. The browser installs the service worker and starts it up.
  3. The service worker sends the server a request for the PWA app shell. The server sends those resources to the service worker, which caches them.

For an existing user:

  1. The browser sends a request for an article URL. This request is intercepted by the service worker. The service worker returns the cached PWA to the browser.
  2. The PWA requests the AMP article. This requests reaches the server, which returns the AMP article to the PWA. The PWA processes and displays that article.

Remember, a web crawler is always a new user!


What’s next?

Now that the Shadow Reader’s got its own server, we’ve got some new TODOs:

  • In the future, we could forgo YQL altogether, simply using the Guardian’s RSS feed directly.
  • We also should replace the Guardian’s top nav links with Shadow Reader links.
  • We ask the AMP Cache to download and run the entire Shadow Reader in an iframe: <amp-install-serviceworker data-iframe-src=”“>. It might be kinder to the casual user to specify a smaller page instead.
  • Backend.js now gets used in the server as well as the front end, and the way we do that is a bit hacky. Perhaps we should refactor our code to use ECMAScript modules?

Please try this out, check out the code on github, and let us know what you think!  We’re curious about how you’re trying out AMP/PWA patterns on your own site, and we’d love to get your ideas for Shadow Reader improvements.


Posted by Ben Morss, Developer Advocate, Google

The Shadow Reader, Improved

New in AMP: Q2, 2018 Edition

Monetization support for AMP stories

AMP stories now supports ‘Publisher placed ads’, the ability for a publisher to serve ads for which they can control delivery sales and delivery. Ad Server support in DoubleClick for Publishers (DFP) is planned for the end of June. We urge other ad networks that are interested in adding monetization support to AMP stories to reach out to us.


See the details related to monetization related to AMP stories here or play with an example on

New user control tools in AMP

We have launched the new <amp-consent> component to help publishers implement user controls for customizable notice, choice, and consent flows. You can find all the usage and integration details related to the launch in this blog post.

Relatedly, a new component, <amp-geo>, makes it easy to vary small sections of web content for users based on an approximation of the users’ country-level location, similar to the level of an ISO Country Code. This can be used with <amp-consent> to change the behavior of <amp-consent> based on users’ approximate location. Check out an example to see how the two components integrate.

AMP Date Picker (Experimental)

The <amp-date-picker> component is a calendar-style interactive date picker for form input, and it’s officially available to use on sites as a document-level experiment. This means that developers can use the component as long as they also include this temporary tag: <meta name=”amp-experiments-opt-in” content=”amp-date-picker”>. Check out the sample on  AMP by Example to see what it can do, and determine if it’s right for your site.

Note: The reason for this intermediate stage of release (a document-level opt-in) is to collect feedback from developers and users and to identify any issues before we consider the component stable enough for a full production release. So expect some rough edges for now, let us know if you have any feedback, and stay tuned for the full release later this quarter.


Introducing the image lightbox gallery

Since AMP launched, developers have been asking for an easy way to link <amp-carousel> with <amp-image-lightbox> so users could experience an immersive view of content in carousels. While it’s been possible to combine numerous components (like <amp-bind>) to make something like this work, it hasn’t been easy.

The <amp-lightbox-gallery> component provides an immersive media experience that can stand on its own or can be integrated with the amp-carousel. The component can be applied to a standalone image or to a group of images so that when a user taps on these images, they enter an immersive view where they can seamlessly swipe from image to image. When <amp-lightbox-gallery> is applied to an <amp-carousel>, all images in the carousel inherit the lightbox gallery behavior so that swipes between items in the immersive view are synced with those in the lightbox, to create a smooth, intuitive gallery experience.


New effects for amp-fx-collection

We’re just starting to build out <amp-fx-collection>, a suite of easy-to-use visual effects that developers can use to make their sites more engaging. So far, we’ve released two effects: parallax, which lets you easily configure page elements to move at different speeds relative to the scrolling speed of the document; and fade-in, which applies a simple and configurable fade-in effect when the user scrolls content into view. Over the next few weeks, we’re planning to launch fly-in as well, which is currently available as an experiment. Check out the new features on AMP by Example and let us know what you think.

Ability to upload files

File upload is an important capability for many sites.  For instance, some e-commerce sites incorporate custom design uploads into their purchase flows. To support this functionality we enabled file upload support in forms through <input type=”file”>(essentially the same way developers would do this in a non-AMP page, with the additional requirement that the form uses a secure XHR submit). And now that AMP offers this basic support, we’re working on a more advanced API that will allow developers to better communicate to users the status of file uploads (bytes uploaded, % progress bars, etc).

The best of the rest

  • Read more about the progress on web packaging to help get rid of URLs when AMP documents are loaded from the Google AMP cache.
  • A number of talks and features were delivered at Google I/O 2018. You can read the summary of the AMP team’s presence at I/O here.

Upcoming features worth a shout

* * *

Thanks to the AMP development community for your work and feedback. As always, please let us know if you have any issues or feature requests.

Posted by Vamsee Jasti, Product Manager, AMP Project

New in AMP: Q2, 2018 Edition