We’ve updated the AMP Roadmap to give you a clear idea of where AMP’s larger projects stand today. Below is a summary across the focus areas:

Format

The past quarter has ushered in support for several new use cases in AMP. Now you can publish live-updating live blogs with <amp-live-list>. We’ve also improved the user experience for ads, video, and other embeds in <amp-carousel>, with an update to enable swiping over iframes. In addition, soon you’ll be able to collect newsletter signups, enable basic site searches, and support other core forms use cases with the amp-form extension (which you can try out today experimentally).

Our focus over the next few months will include enhancements to the seamless transition from AMP documents to native apps, with the ability to promote app installations using <amp-app-banner>, and a component for better deep-linking. We’ve also added experimental support for image grouping in <amp-lightbox>, to enable more immersive experiences at the page and carousel level, and will continue to refine that toward an expected Q4 launch.

In addition, we continue to work on better, more immersive video experiences on AMP pages and platforms, as well as growing the AMP format for e-commerce experiences. This includes further enhancements to form support, component support for product galleries, and tabbed content navigation.

Analytics

In August, <amp-experiment> launched to enable running A/B-style content experiments on AMP pages. The past quarter also saw some improvements to <amp-analytics>: the ability to have a “hidden” trigger and support for element-level data variables.

Heading into Q4, supporting video and e-commerce analytics will remain focal points.

Ads

Recently we added support for a major publisher ask to improve ad monetization, multi-size ad requests. The A4A(AMP for Ads) team finalized the A4A format spec to allow publishers and advertisers to create innovative, performant AMP format ad creatives.

Heading into Q4, we are focused on ramping up delivery of AMP format creatives by supported ad servers. We are also working to ensure that A4A creatives are supported and performant outside of AMP pages. Last, we are working on some UX improvements for all ads in AMP, which includes features like consistent ad labeling and default placeholders and fallbacks.

Access

We continue to work on server-side access and sign-in support, and to seek input on these features. We hope to launch alpha versions of both in Q4.

* * *

Thanks to readers for your time, and to the AMP development community for your work taking AMP even further. As always, please let us know if you have any feedback.

Posted by Eric Lindley, Product Manager, AMP Project

The AMP project has always always strived to help publishers monetize the content they publish to AMP pages as effectively as possible. That means helping publishers capture the most advertiser demand possible for each ad slot on their pages.

One way we’re enabling publishers to do this is by allowing ad slots on AMP pages to serve multiple ad unit sizes, while maintaining AMP’s promise of a stable layout that doesn’t “jump around” in front of the user. With more ad units eligible to serve in a single ad slot, more advertisers can compete in programmatic auctions and drive up the revenue potential of that slot.

Today, we are announcing that both Yieldmo and DoubleClick have implemented multi-size ad request support for AMP pages.

The issue with multi-size ad requests today

Publishers have been using multi-size ad requests to optimize revenue across their web properties for a while now. However, the implementation to date has led to poor user experiences. Existing multi-size ad slots have caused pages to reflow, which in turn could lead to:

1) Accidental ad clicks taking the user out of the original content experience

2) Undesirable content experiences with content bouncing to fit the new ad unit

3) Poor technical performance of the page

The AMP solution

AMP always prioritizes user experience and page performance over anything else. Accordingly, it strictly enforces the principle of containment, i.e. the ad response can never cause the rest of the content to reflow.

AMP will always reserve the primary size required for the ad slot before the ad request is made. In order to support multi-size ad requests, the render-start API  was enhanced to accept an optional size parameter. When this parameter is sent by the ad tech provider, AMP will automatically resize the primary size of the container (when necessary) to fit the creative without causing page reflow.

Enabling Yieldmo clients to leverage multi-size ad requests on AMP

As an early supporter of the AMP project, Yieldmo has been deeply invested in helping publishers effectively monetize their content on AMP pages.

“Publishers and advertisers have been asking for us to provide multi-size ad request support in AMP for a while now. But doing this in a way that wasn’t intrusive to the user-experience was a challenge. We collaborated very closely with the AMP team on this project, even helping define some of the implementation. Integrating with the new API was really easy, and we’re excited to see how this new feature will drive revenue for our clients.” – Rahul Rao, Yieldmo.

For more details on Yieldmo’s implementation, check out the documentation.

To learn more about DoubleClick’s support for multi-size ad requests, check out the documentation and examples.

Posted by Rahul Rao, Director, SDK, Yieldmo & Vamsee Jasti, Product Manager, AMP Project

Editor’s note: The following was originally posted on Shopify’s Blog by Haani Bokhari, Front End Developer. Read below to learn how Shopify is using AMP.

Today we’re excited to share our involvement with the AMP Project.

Life happens on mobile. (In fact, there are over seven billion small screens now!) We’re not only comfortable with shopping online, but increasingly we’re buying things using our mobile devices. Delays can mean the difference between a sale or no sale, so it’s important to make things run as quickly as possible.

AMP, or Accelerated Mobile Pages, is an open source, Google-led initiative aimed at improving the mobile web experience and solving the issue of slow loading content. (You can learn more about the tech here.) Starting today, Google is pointing to AMP’d content beyond their top stories carousel to include general web search results.

We’ve been playing with AMP for the past few months, tinkering with ways to improve the mobile experience for Shopify merchants. We’ve created an app that merchants can install to provide AMP to all of their products. This means, when a Shopify merchant’s product would normally appear in Google search results, a customer will go from results to checkout page in two quick taps. Over the next weeks, we’ll be slowly rolling out our AMP alpha for select merchants.

This work continues our commitment to open source projects, which you can find on GitHub, and to mobile projects that meaningfully benefit merchants. Keep your eyes on this space as we continue to work on AMP and share our learnings.

Posted by Haani Bokhari, Front End Developer

Editor’s note: The following was originally posted on Reddit’s Blog by u/illymc, Product Manager, Channels. Read below to learn how Reddit is using AMP.

Reddit is creating web pages that load almost instantly by leveraging Accelerated Mobile Pages (AMP for short). Slow to load pages are the primary reason that 39% of mobile users are unhappywith their web browsing experience. Creating fast mobile web experiences turns out to be very challenging; Vox Media, a tech company whose sites get over 150 million unique visitors a month, declared “performance bankruptcy” in 2015 citing pages that took 23 seconds to finish loading on average. AMP is a game changer for the mobile web because it makes it easy to create pages that load in a tenth of a second. Google’s performance experts have helped create the AMP standard so you know it’s reliable.

Today, we are announcing the launch of tens of millions of AMP pages on Reddit. These pages load between 7 and 30 times faster than our previous mobile pages. Every self-post created on Reddit now has a corresponding AMP version. Google will be showing these pages in it’s search results more and more over time. These pages focus on the most important part of the Reddit experience — the great content our users create.

Here’s an example:

We were pleased to discover that creating AMP pages was a snap for our engineering team. AMP is a set of components verified by performance experts at Google to load incredibly quickly. As a result, building web pages becomes more like putting together LEGO blocks instead of having to carefully craft every aspect of your page. Some product developers might worry that having a constrained set of choices would lead to a compromised user experience. However, we found that being limited to AMP’s components made it easy to focus our design efforts on the content that users come to Reddit for.

Today, most companies are creating separate AMP versions of pages they already have. Here at Reddit, we are so excited about AMP that we’re experimenting with developing new pages in AMP. AMP pages look great and load fast on desktop just like they do on mobile. Maintaining good performance to pages as they change often amounts to a time consuming game of Whack-A-Mole but we can be confident our AMP pages will always be fast. So, for many kinds of pages, we think the AMP version is the only version we’ll ever need.

Posted by u/illymc

Editor’s note: The following was originally posted on Reddit’s blog by u/arbeitrary, Senior Software Engineer. Read below to learn how Reddit is using React to enable AMP.

At Reddit, we recently built alternate versions of some comments pages that use Accelerated Mobile Pages (AMP) technology — a technology designed by Google and others in the open source world to ensure that pages load instantly from search results on mobile devices. We have implemented it to improve the Reddit experience for mobile users.

We’ve built this as a Node.js app using React and Redux. React is a modern web framework that solves a number of problems that occur during web development. Redux is a library that helps maintain UI application state and abstracts state transitions away from user controls and API callbacks, providing an immutable, single source of truth about application state to the view components. React and Redux might seem like an odd choice for an app that essentially renders static markup, but we found the combination to be effective. Our decision was more about people and productivity than the code itself.

We have an awesome team working hard on a new version of our mobile web app that uses React and Redux. It will replace the site currently running on m.reddit.com, and will ship in the coming weeks. The new app is a single-page app, which means that instead of the server rendering each page, client-side JavaScript code handles clicks, makes data requests to the API, and renders new views live in the browser. To support a great experience when the app first loads, we also support full and partial rendering of a page on the server-side.

Our primary goal for choice of technology to build the AMP app was to let us move quickly while creating a great user experience. Since AMP is a fundamentally mobile experience, we chose to use the new React and Redux-based version of our mobile web app as a starting point, but using it exclusively with server-side rendering. Starting with an existing codebase let us focus attention on how an AMP experience for Reddit should differ from the core mobile web experience. React let us use AMP components like amp-img or amp-accordion to build our views the same way we use any HTML element, so we maintained a consistent paradigm with our other React projects without adding glue for each new component.

As our AMP traffic increases, we learn more about AMP in production, and we continue to explore more ways to serve mobile redditors, the line between our AMP app and our core mobile web app may blur. We have intentionally left the door open for merging our AMP app and mobile web app together. At a basic level, this makes code sharing simpler while giving us flexibility to draw on fast-loading AMP to gracefully enrich the interactivity of our pages as new users become regular redditors.

From both a technology and user experience perspective, we’re excited about new tools and ecosystems like AMP and React. Both enable developers to write better code for a fast and engaging web. Anything is fair game when it helps us build solid technology for helping redditors find their home on the Internet.

Posted by u/arbeitrary

Editor’s note: The following was originally posted on Google’s Inside Search Blog by David Besbris, VP Google Search. Read below to learn how Google Search is using AMP on Search results

Along with many others in the open source Accelerated Mobile Pages Project, we’ve been working to make the mobile web experience faster. In February, we launched AMP in the “Top Stories” section of Google Search, delivering news in a fast and reliable way. In August, we previewed linking to AMPs across the entire mobile search results page. Today we’re excited to announce that we’re rolling out that faster experience to users across the world.  

Now when you search on your mobile device, you’ll see a label that indicates a page is AMP’d. This doesn’t change Search results but will show you which sites have pages that are ready to load lightning fast.

Today, the median time it takes for an AMP page to load from Google Search is less than one second. Beyond just saving you time with fast loading pages, AMP will also save you data — AMP pages on Search use 10 times less data than the equivalent non-AMP page.

To date we have over 600 million AMP documents created by sites such as eBay (US), Reddit (US), Shopify (Canada),  Konga (Nigeria), WikiHow (US), Cybercook (Brazil), Skyscanner (UK), and many more from all over the world (232 locales and 104 languages). These pages cover retail, travel, recipe, general knowledge and entertainment. That’s a lot of fast-loading pages!

To find out more about AMP, check out ampproject.org.

Posted by David Besbris, VP Google Search

 

The AMP project was founded on the belief that for the mobile web to be better, it needs to be faster.

“The Need for Mobile Speed”, a new research study released today by Google, quantifies the real impact of mobile speed on user engagement and revenue. Based on an analysis of 10,000+ mobile web domains, and data from across Google Analytics and DoubleClick, Google’s research team found that:

• 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load
• The average load time for mobile sites is 19 seconds over 3G connections
• The average mobile page makes 214 server requests

The study also projects, that while there are several factors that impact revenue, publishers whose mobile sites load in 5 seconds earn up to 2x more mobile ad revenue than those whose sites load in 19 seconds.

Insights like these reinforce the mission of the AMP project — to improve the experience of the mobile web for everyone, across every device.

To read more about the study, visit g.co/MobileSpeed.

Posted by Rudy Galfi, Product Manager, AMP Project

At the end of July we announced the beta launch of <amp-live-list>, a component that updates page content dynamically without additional navigation or reload. For the core use-case of live blogs, this helps publishers connect readers to breaking news as it unfolds.

Today, we’re pleased to announce that we’ve graduated <amp-live-list> out of beta. Developers can use the component in production pages, and readers can enjoy live-updating content like live blogs in AMP. For instance, The Guardian is already using <amp-live-list> to publish their liveblogs.

“Live updates are a valued feature of our regular liveblogs, so it’s great to have such an easy route to supporting them in AMP.”

— Simon Adcock, Front-end Developer, Guardian News & Media

And this is just the beginning. We want to enhance <amp-live-list> with some of the feature requests we’ve gotten from developers, like the option to trigger updates without user interaction or display the number of available updates. So, as always, check out the documentation in GitHub and at AMP by example, and give us feedback on what you’d like to see next!

Posted by Eric Lindley, Product Manager

Whether you’re running an online news, travel, or e-commerce site, you’ve likely invested time in reviewing your site’s design and user journeys to make your experiences more useful to your users. Often this means running A/B-style experiments to learn which enhancements work best. To enable this in AMP, we’ve launched <amp-experiment>, a new AMP component that allows you to conduct user experience experiments on an AMP page.

How it works

You can now design experiments and specify how much traffic to drive to specific variations. AMP handles the traffic diversion on the client side and provides a way to collect data with either <amp-pixel> or <amp-analytics>.

There are three key steps to getting a content experiment set up on your AMP page:

1. Configure the experiment
2. Implement variations
3. Collect the data

Configure the experiment

<amp-experiment> is a new custom element that you use to specify all experiment behaviors via a JSON configuration. Here’s a code sample that configures an experiment called “recommendedLinksExperiment”:

<amp-experiment>
<script type=”application/json”>
    {
      recommendedLinksExperiment: {
        sticky: true, 
        variants: {
          shorterList: 25.0,
          longerList: 25.0,
          control: 50.0,
        },
      },
      bExperiment: {...}
    }
  </script>
</amp-experiment>

The JSON configuration supports specifying the following attributes of one or several experiments:

• Whether assignment to a given experiment is sticky: Should a given user always be assigned to the same experiment variants across pageviews? In the example above, the experiment is indeed sticky.
• How much traffic to expose to each variant of a given experiment: Do you want a random 50% of users to see version A and 50% to see version B? What about 20% for each of versions A through E? In the sample above, we allocate 50% of users into the control experience and allocate 25% each into either an experience with a shorter list of recommendations or one with a longer list of recommendations.

Please consult the configuration documentation for other advanced settings like experiment dependencies (groups) and employing a user notification constraint when using the sticky setting.

Implement the variations

Next up, you need to implement how each variant in each experiment should behave. <amp-experiment> will expose an attribute on the <body> element for each variant the user has been assigned to. You can then use CSS to change styling or visibility to construct variants as you’d like users to experience them:

body[amp-x-recommendedLinksExperiment=”control”] .extra-links {
display: none;
}

In the above example, the “control” variant of the recommendedLinksExperiment is meant to not display (“display: none”) the extra links for building the longer recommendation list, as indicated by the class name “extra-links”. This behavior will give just the right list length that we want to test as the experimental control experience.

Collect the data

Finally, AMP takes the configuration and decides what variant to assign across all experiments and for all users. As users receive different experiences based on the experiment variants you’ve defined, you collect data so that you can measure the key metrics of interest such as button clicks or time spent.

<amp-experiment> exposes a couple new reporting features. There is a new substitution variable called VARIANT that you can use to look up which experiment variants were assigned to a user on a given page view. If you’re running multiple experiments, you can use the VARIANTS variable to get the assigned variants across each defined experiment in a serialized format. You can use the combination of the user’s experiment combinations and the data indicating how they behaved during their visit to judge the success of each variant.

Try it out!

The <amp-experiment> feature gives developers a handy tool to optimize their users’ experiences.

Please read the documentation for a full overview of features supported in this initial version and check out the sample at AMP By Example. Drop by GitHub and let us know your feedback and any ideas you have to enhance amp-experiment to be even more useful for the content experiments you’d like to run.

Posted by Rudy Galfi, Product Manager, AMP Project