When the AMP Project first launched, the initial use cases and feature development focused on building AMP to support news and blog content. However, the AMP Project’s ambition has always been making the consumption of any type of mobile content vastly better and faster than we had seen before. Ideally, the format should allow anyone to create high performing websites across many verticals—from news to retail to travel and beyond.

Through the extraordinary progress and open-source collaboration to date, we have built AMP to be great at handling news and blogs, but it’s also now suitable to build many aspects of an e-commerce site. AMP is a natural fit for e-commerce because AMP makes web pages fast, and fast pages help with purchase conversions.

To take a closer look at this, we’ll step into the shoes of a typical user, making their way through an e-commerce site. Throughout the journey, we’ll highlight ready-to-use and proposed features of AMP that can be used to build a fast, beautiful shopping experience.

Before we begin

The general idea is that the entire site doesn’t have to be converted at once. We recommend analyzing and AMP’ing the portions of the site that make sense. Identify each page type’s main goal and key features to help decide where to get started.

AMP has a large selection of pre-built and easy-to-use components to enable interactive experiences like image carousels or instrumentation to collect analytics data. These foundational pieces are a good starting point. Content features like product descriptions, images, reviews, and navigation can be implemented in AMP easily today. Start exploring and building prototypes to learn how you might build these experiences of your site in AMP.

More sophisticated and complex scenarios like purchasing flows cannot yet be done in AMP but is something we’d like to explore through gathering additional input on use cases and user flows. In the meantime, consider if it’s possible to have a button click or similar type of hand-off to a non-AMP HTML page to complete a purchase flow. Remember that AMP is an open-source community effort. It’s easy to engage, start developing, and contribute new components as needed. The format will grow richer in time.

With all that said, let’s get on with stepping through the user’s journey.

Step 1: Browsing

A sample home page or category page

Users often start their journey from a site’s home page or a product category page. These are great pages to AMPlify first, as eBay discussed in their post.

These types of pages are very well suited for AMP. The content is typically static and geared toward offering the best showcase of available products. Use features like <amp-carousel> to offer a mobile-optimized way to browse other products organized by subcategories.

Step 2: Landing on a product page

A sample product page

Our user arrives at an AMP’ed product page after clicking on an item from a featured listing on our e-commerce site’s home page.

AMP can help you create a rich beautiful page to showcase your product. Add bold hero images and videos using the <amp-carousel> and <amp-video> elements. Focusing on e-commerce is inspiring us to dream up additional experiences to support in AMP. For example, we are looking to introduce a new component that will enable presenting a large image of a product that can be changed by choosing from a strip of thumbnails.

For sections with more detailed requirements or extended descriptions, use the <amp-accordion> tag. In addition, enable users to share product links with the <amp-social-share> element. Should a user want to switch gears and explore some other areas of the site, <amp-sidebar> allows you to implement a navigation menu across all pages.

Step 3: Exploring related products

Related products on a product page

We know that users often change their mind and that sometimes the initial product they are looking for isn’t the one they want, so let’s show them more products.

With AMP, there are multiple approaches to show related products. One approach is to statically publish a list of related products.

Another approach is to generate the list on the fly. To do so, just use <amp-list> to fire a CORS request to a JSON endpoint which supplies the list of related products. These are populated into an amp-mustache template on the client. What’s more, the result list can be personalized, because the content is dynamically generated server-side for each request.

Step 4: Personalizing & understanding

Knowing a user’s preferences is powerful. You can tailor content to them to increase conversions.

Use the <amp-access> component to display different blocks of content dependent on a user’s status, such as if the user is logged in. Much like the <amp-list> component, fire a request at a JSON endpoint and then present the data into an amp-mustache template.

To see how users are interacting with the site at an aggregate level, use the <amp-analytics> component. Collect analytics data directly, or integrate with 3rd party analytics platforms. AMP supports several popular analytics vendors.

Step 5: Supporting purchase

The final piece of the puzzle comes in when the user is ready to make the purchase and taps on “Buy”. This is likely to be the point of transition from an AMP-only environment to full HTML. Ensure that transition is as fast and consistent with the experience they have had so far.

If your site is a Progressive Web App (PWA), then AMP provides an ideal bridge in the form of <amp-install-serviceworker>. This allows your AMP page to install a service worker for your domain regardless of where the user is viewing the AMP page. You can then preemptively begin caching content from your PWA so that when the transition out happens, all of the needed content is cached, keeping the experience fast and the customer engaged.

Step 6: Keep caching in mind

AMP is built to work within a smart caching model. This enables platforms that refer traffic to AMP pages to use caching and prerendering to load web pages fast—virtually instantly. However, this also means you may see less traffic to your own origin where the AMP pages are originally hosted and see the balance of the traffic through proxied versions of your pages served by AMP caches. It’s important to keep these factors in mind when analyzing your traffic and engagement.

* * *

Here again are links to AMP By Example pages where you can see samples of a couple of the sample pages highlighted in the pictures above:

• Product listing page
• Product page

Hopefully this walkthrough has given you a taste of what’s available now, but it’s by no means everything that’s possible. We’d love to see examples of what you’re building and hear your feedback over at the GitHub repo on what needs to be added to AMP to enable the e-commerce experiences you want to create.

Posted by Boris Farber and Rowan Merewood, Developer Advocates at Google; and Rudy Galfi, Product Manager, AMP Project

We’ve just published updates to the AMP Roadmap — please check them out!

Here is a summary across the focus areas:

Format

A few weeks ago, we announced the beta for <amp-live-list> and development work is complete. This feature will be vital for publishers looking to launch liveblog experiences using AMP. We anticipate upgrading the feature to stable status within August.

With opportunities ahead for growing the AMP format for e-commerce experiences, we’ve been engaging with the AMP community to outline use cases and build features to enable e-commerce in AMP. The roadmap reflects several initiatives tying in with this effort, including support for <form>, support for a component that would enable product image galleries, and various <amp-analytics> improvements detailed below.

Finally, we’re working on several projects that will enable AMPs to be more beautiful and engaging experiences. We’ll soon ship improvements to the <amp-carousel> component to have better scrolling performance and we’re also just beginning work to enhance <amp-lightbox>. We want to make video awesome on AMP pages and in platform experiences where users discover video content. To achieve this, we’re planning several enhancements, including muted autoplay support and the ability to load AMP pages in a video viewing mode. We’ll also begin to work on introducing a set of out-of-box styling and templates for AMPs.

Analytics

To enhance the core of amp-analytics, we shipped support for a “hidden” event and element-level data variables. Each of these enhancements, coming to stable builds of AMP within August, should enable publishers to build greater awareness of users’ behaviors on AMP pages.

A/B-style content experimentation support has been a long-standing feature request. We’ve recently completed the code for <amp-experiment>, which offers client-side traffic diversion and variation, and integrates with <amp-analytics>. This feature should be launched within August.

Finally, we’d like to improve analytics support in AMP for a couple of key focus areas mentioned above, video and e-commerce, through the introduction of new triggers, variables, and ways of passing data to analytics.

Ads

Since our previous update, we launched sticky ads and flying carpet formats. We also worked on building a lot of the infrastructure required to serve AMP Ads for AMP Pages (A4A).

This quarter, we announced the AMP for Ads (A4A) initiative and expect to deliver A4As via supported ad servers. We are also releasing a format spec for A4A to ensure ads can render quickly and smoothly in the browser and do not degrade a site’s user experience. We’d like to focus on making A4A work in non-AMP pages as well, which will allow advertisers and publishers to build a creative once and deploy to any inventory. Enabling as much A4A creative demand as possible across the advertiser and publisher ecosystem is critical to ensuring overall success of the initiative. To that end, we’re working with creative agencies to build creatives in A4A and auto-convert creatives to A4A when possible.

Finally, we plan to improve the ad loading user experience in AMP through a couple specific projects: displaying a better ad loading indicator and showing a default fallback when no ad is available to serve.

Access

Working towards the goal of enabling seamless access to subscription content in AMP, the team has been developing a general framework for allowing an AMP viewer to help the user sign-in to the publisher of the AMP document. We are working on a prototype that should be ready soon, and look forward to engaging with the community to bring it to market. We are brainstorming ways to use the same general approach to open up user experiences with publisher content that requires signed in usage.

On the AMP Access server-side support front, we needed to switch gears and explore a new approach, so we are prototyping a solution that should be available by end of Q3. Many thanks to the publisher partners who are helping us test the approach.

* * *

As always, please let us know if you have any feedback.

Posted by Vamsee Jasti, Product Manager, AMP Project

Page load time is one of the strongest reasons of page bounce. The average U.S. retail mobile site loaded in 6.9 seconds in July 2016, and according to the most recent data, 40% of consumers will leave a page that takes longer than three seconds to load [source].  This means that if you’re navigating users to a landing page from an ad, 40% will likely not bother and click away. Furthermore, a click to a landing page often takes the user out of context so it’s hard for them to return to the publisher’s site, making the whole experience very disruptive. This is not just bad for the user experience but also bad for publisher and advertiser monetization.

Introducing AMP Ad Landing Pages

To ensure users have a great experience with ads, we’re introducing AMP Ad Landing Pages (ALP), which are landing pages that are built in AMP-HTML that load incredibly fast. Early tests indicate that the median load time for these pages is under one second. We’ve introduced a number of optimizations to improve the loading experience before the user even navigates to the landing page:

1. Pre-connect to landing page: Normal ads do not typically know the URL of the actual landing page. Ads leading to ALPs always know it, and thus can issue a pre-connect request to the respective landing page, which reduces the time it takes to navigate the user to the landing page after the user clicks.
2. Pre-fetch landing pages: Simple non-CPU intensive resources that are visible on the first viewport of the landing page are requested and downloaded before the user clicks on the ad.
3. Delivering Google Cache URL when available: As a trafficker, when you input a canonical destination URL for a creative, the ad server can switch it to the AMP version of the URL (with trafficker consent) using the AMP URL API. The ad server can also embed code required by the creative to pre-fetch and pre-connect to the landing page. Ad servers like DoubleClick for Publishers (DFP) are integrating such features over the next couple of quarters to make trafficking of AMP landing pages easy.
4. Zero Redirects: When possible, AMP eliminates redirects to the ad server. So what happens with the redirects? AMP will initiate the requests once the user has reached the landing page. AMP also supports the amp-pixel component for 3rd party tracking redirects which can be performed on the landing page.

Below is an example of the ALP experience. A user is being served an ad with an AMP Landing Page on the Google Search viewer. Not only does the landing page load in under a second, the user can easily navigate back to the content they were reading before their click on the ad.

We think that a better ad landing page experience is better for the entire ads ecosystem:

• Users are more likely to click on ads they may be interested in if they know they’ll have a positive experience;
• Advertisers benefit from increased user engagement and higher conversion rates;
• Publishers increase revenue with better performing ads, while ensuring that users can get back to their content anytime they want.

Getting started with ALP

If you are a publisher:

AMP landing pages are very well suited to serving sponsored content pages or house marketing pages. If you publish your sponsored content as AMP, similar to how you do for other content, follow the instructions listed below for trafficking in your adserver and you are all set.

If you are an advertiser:

More than 650,000 domains and growing, already publish AMP pages today.

Get started with AMP Ad Landing pages by launching AMP versions of your campaign landing pages. Head to AMP’s Get Started tutorial to learn how. These pages can be highly interactive and fast with AMP components like carousel, video, light box etc. You’ll be able to customize them even more using amp-iframe to embed components not yet supported by AMP.

What’s next?

The AMP project was launched with the goal of making the entire mobile web experience faster and better for everybody. AMP Ad Landing pages is a key initiative to improving the user’s experience of ads on mobile and ensuring that we build a sustainable model for monetization.

This project is in early stages with much more to come. If you have ideas or a use case that isn’t currently supported, or if you’re looking for more information on how you can contribute, come say hi on Github. In the meantime, check out detailed instructions for how to traffic an ad campaign in DFP with AMP landing pages.

Posted by Vamsee Jasti, Product Manager, AMP Project

Editor’s note: The following was originally posted on the Google Webmaster Blog  by Nick Zukoski, Software Engineer. 

It’s 2016 and it’s hard to believe that browsing the web on a mobile phone can still feel so slow with users abandoning sites that just don’t load quickly. To us — and many in the industry — it was clear that something needed to change. That was why we started working with the Accelerated Mobile Pages Project, an open source initiative to improve the mobile web experience for everyone.

Less than six months ago, we started sending people to AMP pages in the “Top stories” section of the Google Search Results page on mobile phones. Since then, we’ve seen incredible global adoption of AMP that has gone beyond the news industry to include e-commerce, entertainment, travel, recipe sites and so on. To date we have more than 150 million AMP docs in our index, with over 4 million new ones being added every week. As a result, today we’re sharing an early preview of our expanded AMP support across the entire search results page –not just the “Top stories” section.

To clarify, this is not a ranking change for sites. As a result of the growth of AMP beyond publishers, we wanted to make it easier for people to access this faster experience. The preview shows an experience where web results that that have AMP versions are labeled with . When you tap on these results, you will be directed to the corresponding AMP page within the AMP viewer.

AMP in Search Preview

Try it out for yourself on your mobile device by navigating to g.co/ampdemo. Once you’re in the demo, search for something like “french toast recipe” or music lyrics by your favorite artist to experience how AMP can provide a speedier reading experience on the mobile web. The “Who” page on AMPProject.org has a flavor of some of the sites already creating AMP content.

We’re starting with a preview to get feedback from users, developers and sites so that we can create a better Search experience when we make this feature more broadly available later this year. In addition, we want to give everyone who might be interested in “AMPing up” their content enough time to learn how to implement AMP and to see how their content appears in the demo. And beyond developing AMP pages, we invite everyone to get involved and contribute to the AMP Project.

We can’t wait to hear from you as we work together to speed up the web. And as always, if you have any questions, please visit our webmaster forums.

This post was originally published on the Google Webmaster Central Blog by Nick Zukoski, Software Engineer, Google.

[9/1/2016 Update: has been promoted from “experimental” to “stable”, and can now be used in production pages. Check it out, try it out and give us feedback!]

More and more publishers are leveraging the power of live blogs to connect readers to breaking news as it unfolds. Today we are inviting you to try out the beta for , a new AMP component that updates page content dynamically without additional navigation or reload: readers looking at an earlier version of the page will simply see new updates as they come in.

You—as a developer—have control of the content, and can override the component’s default styles. For example, a default class is applied to the most recent updates, so you can determine the style of new items, such as subtly highlighting the background for new items for a few seconds. The component also includes a customizable button for your users to pull in updates on demand.

How does it work?

In the background, while an AMP page using is displayed on the client, polls the origin document on the host for updates. When the client receives a response, it then filters and dynamically inserts those updates back into the page on the client. Publishers can customize the polling rate in order to control the number of incoming requests, and AMP caches like the Google AMP Cache can perform optimizations to reduce the server response payload, saving client bandwidth and CPU cycles.

To use , all you have to do is:

1. While the component is in beta, opt into the experiment by entering

   AMP.toggleExperiment('amp-live-list')

   into your javascript console on your testing page. You can also opt in on the AMP experiments page for all pages served from cdn.ampproject.org.

2. In the HTML for an AMP page, wrap any live-updating content in and its children, ensure that each element has the required attributes and structure, and publish the page.
3. Whenever new information comes in, update the HTML for with new entries or changes to older entries, and re-publish the page.

That’s it! The child elements of will be dynamically updated as new content comes in.

Example implementation

<amp-live-list id="live-list" data-poll-interval="20000" data-max-items-per-page="10">
<div update on="tap:live-list.update">
You have updates</div>
<div items>
<div id="live-list-item-2" data-sort-time="1464281932879">world</div>
<div id="live-list-item-1" data-sort-time="1464281932878">hello</div>
</div>
</amp-live-list>

Why beta?

This is a very flexible format: on one hand, you could use it for live blogs, which feature updates across nearly the entire page, and can include details like pagination or deep-linking to specific posts. On the other, you might use it to update just one small section, like a scoreboard during a soccer game, or a map of voting results on the night of an election. With your feedback from testing real-world applications of the component, we have the opportunity change some of the behaviors and validations before launch.

This of course means that you shouldn’t launch it on a public-facing page until progresses to “stable” status, and that you should expect to see some validation errors associated with the component while you’re testing.

Try it out!

So check out the documentation in GitHub and at AMP by example, test out the component in your development environment, and give us feedback for what does and doesn’t work for your use-cases. The sooner we know what is and isn’t working for , the sooner we can polish it up and release it to production for use in your AMP pages.

Posted by Eric Lindley, Product Manager

Earlier today, Daniel An and Pat Meenan from Google shared the results of a recent research project focused on uncovering what influences the bounce and conversion rates for e-commerce sites.

Using a machine learning model developed in collaboration with SOASTA, Daniel and Pat identified that the speed and performance of a website can significantly influence the bounce rate of an e-commerce site.  To put it simply: the slower and the more complex the page, the higher the bounce rate and the lower the conversion rate. This is consistent with several research studies and shows the promise that AMP adoption in e-commerce sites holds for doing business on the mobile web.

 

 

To read more about Daniel and Pat’s research check out their article on Think with Google. And if you are curious to learn more about how your website is performing, we encourage you to run the same analysis using their open-sourced code.

This is the story about how AMP came to build a user-experience-first ecosystem for advertising on the web.

A significant part of my job working on the AMP Project has been to engage in discussions on Twitter and in our GitHub issues around what AMP is, what it should be and whether it is doing the right things. Often these discussions eventually come to a point where somebody says:

“Cool, you made the content faster, but what about the ads? Aren’t they the worst offenders for page load times?”

AMP’s original goal was to lift up the user experience across as much web content as possible. This meant we couldn’t just build some idealistic system–existing monetization methods would need to be supported in order to get the wide adoption that would lead to widespread user experience improvements. On today’s web that meant: AMP had to support advertising.

I learned a lot about internet advertising in the first months of working on AMP, and one of those things was that the web advertising industry doesn’t exactly change fast. In fact, looking at lots of ad related JavaScript on the web, one cannot avoid frequent 90s flashbacks.

That led to the design compromise in AMP: Support legacy web advertising, but do so in a way that would mitigate impact on the pages it is embedded into. To achieve this goal AMP uses the following techniques:

• Content first. AMP loads ads after the rest of the content, so ads would never slow down load time.
• Containment. AMP strictly manages the area of a page that ads can access and control to a well defined rectangle. Among other things this avoids pages “jumping around” as ads pop in.
• Mitigation. AMP mitigates against various JavaScript worst practices often found in ad tech such as `document.write`, by limiting their effect on the ad itself vs. the entire page.
• Intervention. AMP slows down timers such as those used for animations for ads that are not currently visible, so that ads use much less battery and CPU when they aren’t being seen. Firefox, Safari, Opera and Chrome have recently started doing this by default and we’ll be happy to delete the code when this rolls out to more users. Because in AMP all legacy ads run inside iframes (many ads outside of AMP have access to the host page), these new browser interventions work particularly well in AMP.

These measures, together with AMP’s aggressive optimizations for general web content, significantly improve both page load time and mitigate effects of the ads on the user experience. In particular, the fact that content always loads first guarantees that ads are never in the way of users doing what they came for on a given page.

There are, however, limits to the fidelity that can be achieved with the approach we have taken so far. This starts with the obvious: Delaying ad load until after content might be an OK compromise, but it is far from the best possible strategy one could employ with finer grained control over an ad’s lifecycle. But the biggest issue, which AMP so far has not addressed, is what we call the coordination problem.

The coordination problem

One of the greatest strengths of the web is that it has a super flexible composition model. This allows easy and ad-hoc assembly of things like YouTube videos, Instagrams, Tweets and ads on a single page. But while composition is simple, all these components share a single thread for JavaScript computation and most UI operations. This is where the coordination problem comes into play: While each component, in isolation, might work super well, things can easily deteriorate to bad UX when assembled together.

This is a frequent problem with ads. For instance, it is super easy to envision 3 ads that each use 6ms of CPU per frame for their animations. That is in itself great — easily staying within the frame budget to achieve 60 frames per second (or 16ms total frame time). But when those ads appear together on the same page, they suddenly need 18ms per frame and the browser can no longer deliver the smooth experience of 60 frames per second.

That is the coordination problem: Even perfectly engineered ads can, in aggregation, negatively impact user experience.

Finally, even ignoring the above, there is a lot that can be done to improve overall quality of ad creatives in terms of their impact on user experience. AMP was first created as a simple path to creating well performing documents on the web, and it seems that it would be great to make that same leap forward for advertising on the web.

Introducing AMP for ads

Earlier this year, a team at Google asked themselves the question:

“AMP worked super well for general content. Couldn’t we just use it for ads?”

…which is what they did. These ads based on AMP are normal, valid AMP documents in their own right, that just happen to be ad creatives. I’m super excited about this as it provides a path to solving all the technical challenges outlined above, bringing us to a more technically healthy advertising ecosystem on the internet.

It is early days for AMP for ads, or A4A, but after announcing the effort on GitHub a few weeks ago, the team has merged their pull request into AMP and is in the process of setting up a live experiment. AMP itself will continue to support non-AMP ad creatives to allow for a gradual transition of the wider ecosystem.

Separating ad requests from ad rendering

The first innovation in A4A seems very obvious in retrospect, but has a super large impact: As outlined above, AMP, by default, loads ads after the content and generally lazily. This is because rendering ads can be expensive in terms of CPU and RAM. However, the ad request itself can be slow, because a lot of work (think: the auction) has to be done on the server side — doing it late is not great for fast load times. From the client’s perspective making the request itself is super cheap, but its side effect (the rendering of the ad) is expensive. By separating the two, A4A achieves much faster ad rendering at no additional CPU and memory cost.

Going deeper: A restricted subset of AMP

One of the core elements of AMP is that is ships with a validator, that checks compliance of AMP documents with certain rules. The idea is: If the rules are met, then the document will load fast. The ruleset we designed for AMP has a broad set of document types and use cases in mind. Ad creatives, on the other hand, are a much more focused use case, and hence they do not actually require the full breadth of functionality that AMP exposes. For this reason, AMP for ads carefully picks out the aspects of AMP that are required to build ad creatives. One example is that AMP based ads will not be allowed to load iframes with arbitrary JavaScript.

Contrast this with the status quo in ad tech: ad creatives typically have full control over the browser and they can dynamically load more code at runtime, so it is impossible to ever really know what they will do. AMP based creatives on the other hand will have well defined, statically analyzable behavior while still having access to the vast majority of web platform functionality.

AMP being optimized for documents right now is certainly missing many types of components needed for engaging ads. The team is hard at work at closing that feature gap. One example is that AMP for ads will ship with a component for smooth and interactive timeline based animations.

Re-using AMP

Ads often come with their own set of measurement tools to collect important information such as whether an ad was actually seen by a user. This substantially increases ad payload size, initial compilation and execution time, battery usage and other aspects of runtime performance.

AMP, through its established `amp-analytics` mechanism, already ships with all the code to perform these measurements. It is vendor neutral and supports a wide range of metrics. This means ads can take advantage of the same “instrument once, report many times” feature that benefits AMP pages today, completely eliminating the bandwidth and runtime cost outlined above.

The coordination solution

AMP based ads will participate in page layout like all other AMP resources. That means they automatically take advantage of AMP’s features for minimizing resource impact on runtime performance.

In particular, AMP only animates things that are visible on the screen. Period. While browsers are working on achieving this at the platform level, they need to be conservative in not breaking existing use cases. AMP for ads being new and special purpose technology, can pinpoint when animations are needed and thus further reduce CPU usage and battery consumption.

AMP will act as a supervisor for ads and ensure that they do not negatively impact primary content on a page. A4A based animations will be throttled to lower-but-uniform frame rates when AMP detects that 60 frames per second cannot be achieved on the current device. Similarly, if AMP is unable to stabilize the frame rate it will turn off animations. This ensures that every device gets the best experience it can deliver and makes sure that ads cannot have a negative impact on important aspects of the user experience such as scrolling.

Cross platform

As part of the AMP Project, AMP for ads is a vendor neutral initiative. While we are still in the early experimentation and implementation phase, the technology is designed to support all ad networks. If you work on ad tech, say Hi on GitHub. We believe A4A is a big step forward for user experience and would love to see wide adoption across the internet advertising industry.

So, that is what we are doing with ads

It is early days, and we are just getting started to explore using AMP for ads.

In this future

• ads will be statically analyzable to be safe and behave well,
• they will be able to use a common set of functionality to significantly reduce bandwidth consumption,
• CPU usage will be limited to on-screen ads, maximizing battery life,
• and ads will be coordinated with the page making sure that primary content and functionality can always be buttery smooth at 60 frames per second.

We are trying to build a user-experience-first ecosystem for advertising on the web and, looking at the success of AMP in publishing, it might just work.

This post was originally published on Medium by Malte Ubl, Tech Lead for the AMP Project.

Speed matters – and not just when you are chasing a rare Pokémon in the wild. Research has shown that 40% of users abandon a site that takes more than 3 seconds to load.

We launched AMP to make the experience of loading screens obsolete. And users are already noticing. Today, The Washington Post is sharing with the AMP community some promising user engagement and retention stats: since The Washington Post adopted AMP, they observed an 88% decrease in article loading time, resulting in a 23% increase in returning users from mobile search.

As more sites implementing AMP share information about their experience, we’ll make sure to update you through this blog and @amphtml.

Posted by Adam Greenberg, AMP Partnerships

Editor’s note: Developers in verticals such as e-commerce have started embracing AMP to bring a faster experience to their users, and we’re excited to highlight their efforts.

The following was originally posted on the eBay Tech Blog by Senthil Padmanabhan, Principal Engineer & Frontend Lead at eBay. Below you can read about how Senthil’s team started working on AMP and learn about their upcoming plans to get involved with the AMP Project.

* * *

One of the top initiatives for eBay this year is to provide a compelling browse experience to our users. In a recent interview, Devin Wenig has given a good overview of why this matters to eBay. The idea is to leverage structured data and machine learning to allow users to shop across a whole spectrum of value, where some users might desire great savings, while others may want to focus on, say, best selling products.

When we started to design the experience, our first area of focus was mobile web. Similar to many other organizations, mobile web has been our highest growing sector. We wanted to launch the new browse experience on mobile web first, followed by desktop and native.

The core design principles of the new mobile web browse experience were to keep it simple, accessible, and fast, really fast. On the front-end side of things, we made a couple of choices to achieve this.

• Lean and accessible — From the beginning we wanted the page to be as lean as possible. This meant keeping the HTML, CSS, and JS to a minimum. To achieve this goal, we followed a modular architecture and started building atomic components. Basically a page is a bunch of modules, and a module is built from other sub-modules, and so on. This practice enabled maximum code reuse, which in turn reduced the size of resources (CSS and JS) drastically. In addition, our style library enforced accessibility through CSS — by using ARIA attributes to define styles rather than just class names. This forces developers to write a11y-friendly markup from the beginning, instead of it being an afterthought. You can read more about it here.
• Code with the platform — The web platform has evolved into a more developer friendly stack, and we wanted to leverage this aspect — code with the platform vs. coding against it. What this meant was that we could reduce the dependency on big libraries and frameworks and start using the native APIs to achieve the same. For instance, we tried to avoid jQuery for DOM manipulations and instead use the native DOM APIs. Similarly, we could use the fetch polyfill instead of $.ajax etc. The end result was a faster loading page that was also very responsive to user interactions. BTW, jQuery is still loaded in the page, because some of eBay platform specific code is dependent on it, and we are working towards removing the dependency altogether.

But our efforts did not stop there. The speed aspect was very critical for us, and we wanted to do more for speed. That is when we ran into AMP.

Experimenting with AMP

The AMP project was announced around the same time we started the initial brainstorming for browse. It seemed to resonate a lot with our own thinking on how we wanted to render the new experience. Although AMP was more tuned towards publisher-based content, it was still an open source project built using the open web. Also, a portion of the traffic to the new browse experience is going to be from search engines, which made it more promising to look into AMP. So we quickly pinged the AMP folks at Google and discussed the idea of building an AMP version for the browse experience, in addition to the normal mobile web pages. They were very supportive of it. This positive reaction encouraged us to start looking into AMP technology for the eCommerce world and in parallel develop an AMP version of browse.

Today we are proud to announce that the AMP version of the new browse experience is live, and about 8 million AMP-based browse nodes are available in production. Check out some of the popular queries in a mobile browser — Camera Drones and Sony PlayStation, for example. Basically adding amp/ to the path of any browse URL will render an AMP version (for example, non-AMP, AMP). We have not linked all of them from our regular (non-AMP) pages yet. This step is waiting on few pending tasks to be completed. For now, we have enabled this new browse experience only in mobile web. In the next couple of weeks, the desktop web experience will also be launched.

So how was the experience in implementing AMP for the eCommerce world? We have highlighted some of our learnings below.

What worked well?

• Best practices — One of the good things about AMP is that at the end of the day it is a bunch of best practices for building mobile web pages. We were already following some of them, but adoption was scattered across various teams, each having its own preference. This initiative helped us consolidate the list and incorporate these best practices as a part of our regular development life cycle itself. This made our approach towards AMP more organic, rather than a forced function. The other good side effect of this is even our non-AMP pages become faster.
• Less forking in code — This follows the previous point. Since we started following some of the AMP best practices for building regular pages, we were able to reuse most of the UI components between our non-AMP and AMP browse page. This resulted in less forking in code, which otherwise would have become a maintenance nightmare. Having said that, there is still some forking when it comes to JavaScript-based components, and we are still figuring out the best solution.
• AMP Component list — Although the AMP project’s initial focus was more towards publisher-based content and news feeds, the AMP component list was still sufficient to build a basic product for viewing eCommerce pages. Users will not be able to do actions on items (such as “Add To Cart”), but they still get a solid browsing experience. The good news is that the list is getting better and growing day by day. Components like sidebar, carousel, and lightbox are critical in providing a compelling eCommerce experience.
• Internal AMP platform — We have been thinking about leveraging the AMP ecosystem for our own search, similar to how Google handles AMP results. This plan is in very early stages of discussion, but the possibility of our search using AMP technology is very interesting.

The complex parts

• Infrastructure components — To launch an eBay page to production, a lot of infrastructure components automatically come into play. These are things like Global header/footer, site speed beacon kit, experimentation library, and the analytics module. All of them have some amount of JavaScript, which immediately disqualifies them from being used in the AMP version. This adds complexity in development. We had to fork few infrastructure components to support the AMP guidelines. They had to go through a strict regression cycle before being published, which added delays. Also, our default front-end server pipeline had to be conditionally tweaked to exclude or swap certain modules. It was a good learning curve, and over time we have also replaced our early quick hacks with more robust and sustainable solutions.
• Tracking — AMP provides user activity tracking through its amp-analytics component.amp-analytics can be configured in various ways, but it still was not sufficient for the granular tracking needs that eBay has. We also do stuff like session stitching, which needs cookie access. Creating an amp-analytics configuration to suit our needs was slowly becoming unmanageable. We need some enhancements in the component, which we are hoping to develop and commit to the project soon.

What’s next?

We are excited to partner with Google and everyone else participating on the AMP Project to close the gap in launching a full-fledged eCommerce experience in AMP. We have created a combined working group to tackle the gap, and we will be looking into these items and more.

• Smart buttons — These enable us to do actions like “Add To Cart” and “Buy It Now” with authentication support.
• Input elements — User interactive elements are critical to eCommerce experiences, be they simple search text boxes or checkboxes.
• Advanced tracking — As mentioned earlier, we need more granular tracking for eBay, and so we have to figure out a way to achieve it.
• A/B Testing — This will enable experimentation on AMP.

With items like these in place, AMP for eCommerce will soon start surfacing.

We will also be looking into creating a seamless transition from the AMP view to a regular page view, similar to what the Washington Post did using Service Workers. This will enable users to have a complete and delightful eBay experience without switching contexts.

We are also asked the question of if there is more focus towards web over native. The answer is NO. At eBay, we strongly believe that web and native do not compete each other. They indeed complement each other, and the combined ecosystem works very well for us. We will soon be launching these browse experiences in our native platforms.

We are on our path to making eBay the world’s first place to shop and this is a step towards it. Thanks to my colleague Suresh Ayyasamy, who partnered in implementing the AMP version of browse nodes and successfully rolling it to production.

— Senthil

As we bid adieu to Q2, we made some updates on the AMP Roadmap to make sure the status of projects listed there reflects where these efforts stand today.

Here is a summary across the focus areas:

Format

In the past three months we launched elements like <amp-sidebar>, <amp-accordion>, and <amp-social-share> to bring some highly requested functionality to AMP pages like site navigation menus and share bars. We introduced <amp-live-list> to enable live-updating content, and look forward to pushing it across the line from experimental to stable in Q3.

There are several additional priorities this quarter, such as support for forms, that haven’t landed just yet, which we expect to continue focusing on into Q3. Over the next few months, we are looking at adding features that make it easier to build immersive and interactive AMP pages as well as introduce methods to lazily load content that must be up to date—and do so in a way that’s compatible with AMP’s user experience and performance goals.

Analytics

This quarter we shipped further ways to customize the <amp-analytics> “visible” trigger to provide viewability-based analytics data. We’re in the early phases of building support for A/B testing and share tracking, and development on those will continue into Q3.

In the coming quarter, we plan to add further support for video analytics and to deepen AMP’s analytics support to ensure it supports a wide variety of content verticals, such as ecommerce.

Ads

This quarter we continued our twin focus of making the existing ads better as well as laying the groundwork for even faster ads experiences with AMP. For the former, we developed two new ad formats in compliance with AMP’s philosophy: the AMP sticky ads and the AMP flying carpet ad format. Since existing ad demand can fill in these ad formats, publishers will be able to further monetize their AMP pages with good-looking ads. For the latter, we submitted infrastructure changes for AMP Ads For AMP Pages (“A4A”) which will allow AMP ads to be loaded as fast as content on AMP pages.

In Q3, we are working on adding ad server support to A4A ads, enabling buyside support for A4A, and better AMP signals for programmatic buyers and much more.

Access

AMP now has multiple publishers such as the New York Times, Wall Street Journal, Financial Times, New Yorker, Folha, Les Echos, and Espresso live with paywalls globally. We are in the final stages of development of server-side paywall support for AMP, which will be in beta soon.

Extending AMP functionality to help publishers with conversion via simple, seamless user experiences is an important focus area for us. We are in early stages of prototyping simplified user sign-in to AMP pages, and development on this and associated features will continue into Q3.

* * *

We hope these roadmap updates are helpful. Thanks for taking the time to come up to speed on AMP. We invite you to come to our GitHub repository to collaborate with us on building AMP, and please let us know if you have any feedback.

Posted by Ashwin Limaye, Product Manager, AMP Project