We’re excited to announce that we’ve teamed up with the Accelerated Mobile Pages team to bring you amp-ima-video, an IMA-SDK-enabled video player extension for AMP pages. This extension has been an AMP experiment for the past few months, but today we’re moving from experiment to public release.
amp-ima-video provides an AMP-enabled video player with the IMA SDK pre-integrated, so you can easily play and monetize content on your AMP pages. Simply provide your content URL and an ad tag, and we’ll handle playing back the video and ad(s). The extension currently supports linear in-stream single ads and VMAP playlists. To see it in action, check out the AMP by Example page for the extension.
If you have any questions or issues with the extension, please file them via the AMP issue tracker on GitHub.
Posted by Rudy Galfi, Product Manager for AMP at Google
The AMP story format is a recently launched addition to the AMP Project that provides content publishers with a mobile-focused format for delivering news and information as visually rich, tap-through stories.
A visual-driven format for evolving news consumption on mobile
Some stories are best told with text while others are best expressed through images and videos. On mobile devices, users browse lots of articles, but engage with few in-depth. Images, videos and graphics help publishers to get their readers' attention as quickly as possible and keep them engaged through immersive and easily consumable visual information.
Recently, as with many new or experimental features within AMP, contributors from multiple companies — in this case, Google and a group of publishers — came together to work toward building a story-focused format in AMP. The collective desire was that this format offer new, creative and visually rich ways of storytelling specifically designed for mobile.
Minimize technical challenges and let creators focus on the storytelling
The mobile web is great for distributing and sharing content, but mastering performance can be tricky. Creating visual stories on the web with the fast and smooth performance that users have grown accustomed to in native apps can be challenging. Getting these key details right often poses prohibitively high startup costs, particularly for small publishers.
AMP stories are built on the technical infrastructure of AMP to provide a fast, beautiful experience on the mobile web. Just like any web page, a publisher hosts an AMP story HTML page on their site and can link to it from any other part of their site to drive discovery. And, as with all content in the AMP ecosystem, discovery platforms can employ techniques like pre-renderable pages, optimized video loading and caching to optimize delivery to the end user.
AMP stories aim to make the production of stories as easy as possible from a technical perspective. The format comes with preset but flexible layout templates, standardized UI controls, and components for sharing and adding follow-on content.
Yet, the design gives great editorial freedom to content creators to tell stories true to their brand. Publishers involved in the early development of the AMP stories format — CNN, Conde Nast, Hearst, Mashable, Meredith, Mic, Vox Media, and The Washington Post — have brought together their reporters, illustrators, designers, producers, and video editors to creatively use this format and experiment with novel ways to tell immersive stories for a diverse set of content categories.
Developer preview for AMP stories is starting today
Today AMP stories are available for everyone to try on their websites. As part of the AMP Project, the AMP story format is free and open for anyone to use. To get started, check out the tutorial and documentation. We are looking forward to feedback from content creators and technical contributors alike.
Also, starting today, you can see AMP stories on Google Search. To try it out, search for publisher names (like the ones mentioned above) within g.co/ampstories using your mobile browser. At a later point, Google plans to bring AMP stories to more products across Google, and expand the ways they appear in Google Search.
To improve our users' experience with AMP results, we are making changes to how we enforce our policy on content parity with AMP. Starting Feb 1, 2018, the policy requires that the AMP page content be comparable to the (original) canonical page content. AMP is not a ranking signal and there is no change in terms of the ranking policy with respect to AMP.
The open source accelerated mobile pages project (AMP) launched in 2015 and has seen tremendous growth with over 25M domains having implemented the AMP format. This rapid progress comes with a sense of responsibility of ensuring that our users continue to have a great content consumption experience that ultimately leads to more engagement with publisher content.
In some cases, webmasters publish two versions of their content: a canonical page that is not based on AMP and an AMP page. In the ideal scenario, both these pages have equivalent content leading the user to get the same content but with a faster and smoother experience via AMP. However, in some cases the content on the AMP page does not match the content on its original (canonical) page.
In a small number of cases, AMP pages are used as teaser pages which create a particularly bad user experience since they only contain minimal content. In these instances, users have to click twice to get to the real content. Below is an example of how this may look like: a brief text of the main article and then asking the user to click to visit another page to complete reading the article.
AMP was introduced to dramatically improve the performance of the web and deliver a fast, consistent content consumption experience. In keeping with this goal, we'll be enforcing the requirement of close parity between AMP and canonical page, for pages that wish to be shown in Google Search as AMPs.
Where we find that an AMP page doesn't contain the same critical content as its non-AMP equivalent, we will direct our users to the non-AMP page. This does not affect Search ranking. However, these pages will not be considered for Search features that require AMP, such as the Top Stories carousel with AMP. Additionally, we will notify the webmaster via Search console as a manual action message and give the publisher the opportunity to fix the issue before its AMP page can be served again. The AMP open source website has several helpful guides to help produce fast, beautiful and high-performing AMP pages.
We hope this change encourages webmasters to maintain content parity between the canonical and AMP equivalent. This will lead to better experience on your site and ultimately happier users.
With users getting more and more impatient with slow mobile pages, developers are increasingly investing in a faster web experience with solutions like Accelerated Mobile Pages (AMP). Billions of AMP pages have been published by all kinds of mobile sites – from news to recipes to e-commerce. With so much AMP content being published every week, Google Analytics continues to evolve to support those of our customers who have adopted AMP.
Today we are excited to be the first supporting vendor to announce a new service, Google’s AMP Client ID API, that will enable the same benefits for AMP pages displayed via Google surfaces. In May of this year we launched a solution to help you better understand your customers’ journeys across AMP and non-AMP experiences that were hosted on your own domain. Google’s AMP Client ID API will enable the same benefits for AMP pages displayed by Google such as in Google Search.
How will this work?
This solution works by allowing your web pages, which may be partially served on Google platforms and partially on your domain, to communicate with each other. This communication happens via a newly introduced Google API and with Google Analytics such that it can understand if a user on your non-AMP pages had ever visited an AMP page displayed by Google. When true, Google Analytics can help you understand user behavior across these two page types as a single cohesive experience.
To get started you’ll have to opt-in to this solution via a code change. The small code change is required on both your AMP and non-AMP websites to enable this as well as an acknowledgement of the new Google Analytics terms for usage of this API.
When will this happen?
The ability to opt-in to this solution is available today and you can find code instructions and new terms here. Please review the documentation and opt-in when you are ready.
Are there any other implications of this change?
Once you opt-in to this solution you will notice changes to some of your metrics. Your user and session metrics will drop down to more accurate counts as formerly distinct users are recognised as the same person, as well as related metrics that will also become more accurate (such as Time on Site and Bounce Rate). And New Users may rise temporarily. This is a function of the product more accurately counting your users. It's a one-time effect that will continue until all your users who have viewed AMP pages in the past return to your site (this can take a short or long period of time depending on how quickly your users return to your site/app). To get more detail about what may change, please read our help center article.
Recently we announcedthe addition of Brotli compression to the Google AMP Cache. All AMP documents served from the Google AMP Cache can now be served with Brotli, which will save a considerable amount of bandwidth for our users and further our goal of improving the mobile experience.
Brotliis a newer, more efficient compression algorithm created by Jyrki Alakuijala and Zoltán Szabadka with the Google Research Europe Compression Team. Launched in 2015, it has already been used to enable considerable savings in other areas of Google. While it is a generic compression algorithm, it has particularly impressive performance when applied to web documents; we have seen an average decrease in document size of around 10% when using Brotli instead of gzip, which has amounted to hundreds of gigabytes of bandwidth saved per day across the Google AMP Cache.
With smaller document sizes, pages load faster while also saving bandwidth which can amount to noticeable savings for users on limited data plans. The Google AMP Cache is just the beginning though, as engineering teams are working on Brotli support in many other products which can enable bandwidth savings throughout Google.
By Jason Titus, Vice President, Developer Product Group
It's great to be in our backyard again for Google I/O to connect with developers
around the world. The 7,200 attendees at Shoreline Amphitheatre, millions of
viewers on the livestream, and
thousand of developers at local I/O Extended events across 80+
countries heard about our efforts to make the lives of developers easier --
allowing them to focus on the problems they're trying to solve by minimizing the
pain points of building a product.
Earlier this morning, our CEO Sundar Pichai talked
about our various billion-user platforms. Whether it's Android or Chrome or the
mobile Web, our success would not have been possible without the developer
community. And during our Developer
Keynote, we covered our heavy investments in tools and services for
developers who build on our platforms every day.
We have a lot to cover over the next three days. Let's take a closer look at the
major developer news at I/O so far:
Platforms that connect developers to billions of users around the
O Developer Preview 2 — Get a look at the next release of Android O focused
on fluid experiences that make Android even more useful, and our efforts to
optimize battery life, startup time, graphic rendering time, and stability.
Early adopters can opt in to the Android O Beta Program at android.com/beta and run Android O now.
Treble — Last week, we also introduced a new Android framework designed to
help reduce the time and effort it takes device makers to upgrade a phone to a
new version of Android, starting with Android O.
Go — We're optimizing Android to run smoothly on entry-level devices,
starting with the O release. We're also designing Google apps to use less
memory, storage space, and mobile data, including apps such as YouTube Go,
Chrome, and Gboard.
— Android is officially supporting the Kotlin programming language, in addition
to the Java language and C++. Kotlin is a brilliantly designed, mature,
production-ready language that we believe will make Android development faster
and more fun.
Studio 3.0 Canary — Our new preview includes three major features to
accelerate development flow: a new suite of app performance profiling tools to
quickly diagnose performance issues, support for the Kotlin programming
language, and increased Gradle build speeds for large sized app projects.
Mobile Web — AMP and Progressive Web
Apps(PWAs) are re-defining
modern mobile web development. AMP gets content in front of users fast and PWAs
deliver app-focused experiences that are reliable, fast and engaging. We're
seeing success stories
from all around the world - travel company Wego has rolled out a
successful AMP based PWA and Forbes has seen user
engagement double since launching a PWA. If you're wondering how good your
current web experience is, you can use Lighthouse - an
automated tool for measuring web-page quality. Be sure to tune in this afternoon
Mobile Web: State of the Union talk to hear more about building rich mobile
Infrastructure and services to take mobile apps and the Web to the
— At last year's I/O, we expanded Firebase to a full mobile development platform
with products to help you build your app and grow your business. Over a million
developers now use Firebase, and we're doubling down on our efforts to simplify
more every-day developer challenges. We're giving more insights to understand
app performance through Firebase Performance Monitoring, introducing integration
between Hosting and Cloud Functions, adding support for Phone Number
Authentication, and continuing to improve Analytics in a number of ways. We've
also started open
sourcing our SDKs.
Powerful tools to acquire and engage new users; grow successful
Play Console — We announced several powerful, new features and reports in
the Play Console to help developers improve their app's performance, manage
releases with confidence, reach a global audience, and grow their business. The
Play Console also has a new name, to reflect its broadened business uses, and a
fresh look to make it easier to get things done.
Instant Apps — We opened Android Instant Apps, a new way to run Android apps
without requiring installation, to all
developers. Now anyone can build and publish an instant app. There are also
more than 50 new experiences available for users to try out from a variety of
brands, such as Jet, New York Times, Vimeo and Zillow.
Payments, Monetization & Ads — We introduced a Google Payment API that
enables developers to give their customers the ability to pay in apps and online
with credit or debit cards saved to their Google Account. New AdMob integration
with Google Analytics for Firebase helps them monetize efficiently and updates
to Universal Apps Campaigns will help them grow their user base.
New interfaces to push the limits of what's possible
on Google for the Google Assistant — We brought Actions on Google to phones,
introduced new features and functionality, improved our SDK and more. We also
launched the Actions Console, a new developer console that helps developers work
as a team, and collect data on app usage, performance and user discovery
patterns. This new console is integrated with the Firebase and Google Cloud
and AR at Google — We'll have more to share on the latest Daydream platform
features and developer tools during our "VR and AR at Google" session tomorrow
(May 18) at 9:30 AM PT in the Amphitheatre and on the livestream.
It's important to us that developers are successful. In addition to building
products that help solve developer challenges, we're on the ground in over 130
countries, growing and expanding the developer community through programs such
as Women Techmakers & Google
Developer Groups (GDGs).
We're also investing in training programs like Google Developers
Certification and courses through Udacity and other partners to help
developers deepen their technical capability. We're also excited to announce two
large multi-product developer events, Google Developer Days, which are planned
for Europe (September 2017 in Krakow, Poland) and India (December 2017 in
Bangalore, India). If you are interested to find out more, sign up for updates
During Google I/O, attendees and viewers have an opportunity to dive deep into
a number of these areas with 14 content tracks and 140+ breakout sessions --
covering Android to Assistant to VR -- and all livestreamed. We've also launched
over 70 codelabs to get
developers up and running with our latest APIs today.
Whether it's Android, Chrome, Play, VR/AR, the Cloud, and the Mobile Web — we're
constantly investing in the platforms that connect developers to billions of
users around the world. Thank you to the continued support and feedback from the
Posted by Alex Fischer, Software Engineer, Google Search.
TL;DR: Today, we're adding a feature to the AMP integration in Google Search that allows users to access, copy, and share the canonical URL of an AMP document. But before diving deeper into the news, let's take a step back to elaborate more on URLs in the AMP world and how they relate to the speed benefits of AMP.
What's in a URL? On the web, a lot - URLs and origins represent, to some extent, trust and ownership of content. When you're reading a New York Times article, a quick glimpse at the URL gives you a level of trust that what you're reading represents the voice of the New York Times. Attribution, brand, and ownership are clear.
Recent product launches in different mobile apps and the recent launch of AMP in Google Search have blurred this line a little. In this post, I'll first try to explain the reasoning behind some of the technical decisions we made and make sense of the different kinds of AMP URLs that exist. I'll then outline changes we are making to address the concerns around URLs.
To start with, AMP documents have three different kinds of URLs:
Original URL: The publisher's document written in the AMP format. http://www.example.com/amp/doc.html
AMP Cache URL: The document served through an AMP Cache (e.g., all AMPs served by Google are served through the Google AMP Cache). Most users will never see this URL. https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html
Google AMP Viewer URL: The document displayed in an AMP viewer (e.g., when rendered on the search result page). https://www.google.com/amp/www.example.com/amp.doc.html
Although having three different URLs with different origins for essentially the same content can be confusing, there are two main reasons why these different URLs exist: caching and pre-rendering. Both are large contributors to AMP's speed, but require new URLs and I will elaborate on why that is.
AMP Cache URLs
Let's start with AMP Cache URLs. Paul Bakaus, a Google Developer Advocate for AMP, has an excellent post describing why AMP Caches exist. Paul's post goes into great detail describing the benefits of AMP Caches, but it doesn't quite answer the question why they require new URLs. The answer to this question comes down to one of the design principles of AMP: build for easy adoption. AMP tries to solve some of the problems of the mobile web at scale, so its components must be easy to use for everyone.
There are a variety of options to get validation, proximity to users, and other benefits provided by AMP Caches. For a small site, however, that doesn't manage its own DNS entries, doesn't have engineering resources to push content through complicated APIs, or can't pay for content delivery networks, a lot of these technologies are inaccessible.
For this reason, the Google AMP Cache works by means of a simple URL "transformation." A webmaster only has to make their content available at some URL and the Google AMP Cache can then cache and serve the content through Google's world-wide infrastructure through a new URL that mirrors and transforms the original. It's as simple as that. Leveraging an AMP Cache using the original URL, on the other hand, would require the webmaster to modify their DNS records or reconfigure their name servers. While some sites do just that, the URL-based approach is easier to use for the vast majority of sites.
AMP Viewer URLs
In the previous section, we learned about Google AMP Cache URLs -- URLs that point to the cached version of an AMP document. But what about www.google.com/amp URLs? Why are they needed? These are "AMP Viewer" URLs and they exist because of pre-rendering. AMP's built-in support for privacy and resource-conscientious pre-rendering is rarely talked about and often misunderstood. AMP documents can be pre-rendered without setting off a cascade of resource fetches, without hogging up users' CPU and memory, and without running any privacy-sensitive analytics code. This works regardless of whether the embedding application is a mobile web page or a native application. The need for new URLs, however, comes mostly from mobile web implementations, so I am using Google's mobile search result page (SERP) as an illustrative example.
How does pre-rendering work?
When a user performs a Google search that returns AMP-enabled results, some of these results are pre-rendered behind the scenes. When the user clicks on a pre-rendered result, the AMP page loads instantly.
The AMP Viewer pre-renders an AMP document in a hidden iFrame.
The user's browser loads the document and the AMP runtime and starts rendering the AMP page. Since all other resources, such as images and embeds, are managed by the AMP runtime, nothing else is loaded at this point. The AMP runtime may decide to fetch some resources, but it will do so in a resource and privacy sensible way.
When a user clicks on the result, all the AMP Viewer has to do is show the iframe that the browser has already rendered and let the AMP runtime know that the AMP document is now visible. As you can see, this operation is incredibly cheap - there is no network activity or hard navigation to a new page involved. This leads to a near-instant loading experience of the result.
Where do google.com/amp URLs come from?
All of the above happens while the user is still on the original page (in our example, that's the search results page). In other words, the user hasn't gone to a different page; they have just viewed an iframe on the same page and so the browser doesn't change the URL.
We still want the URL in the browser to reflect the page that is displayed on the screen and make it easy for users to link to. When users hit refresh in their browser, they expect the same document to show up and not the underlying search result page. So the AMP viewer has to manually update this URL. This happens using the History API. This API allows the AMP Viewer to update the browser's URL bar without doing a hard navigation.
The question is what URL the browser should be updated to. Ideally, this would be the URL of the result itself (e.g., www.example.com/amp/doc.html); or the AMP Cache URL (e.g., www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html). Unfortunately, it can't be either of those. One of the main restrictions of the History API is that the new URL must be on the same origin as the original URL (reference). This is enforced by browsers (for security reasons), but it means that in Google Search, this URL has to be on the www.google.com origin.
Why do we show a header bar?
The previous section explained restrictions on URLs that an AMP Viewer has to handle. These URLs, however, can be confusing and misleading. They can open up the doors to phishing attacks. If an AMP page showed a login page that looks like Google's and the URL bar says www.google.com, how would a user know that this page isn't actually Google's? That's where the need for additional attribution comes in.
To provide appropriate attribution of content, every AMP Viewer must make it clear to users where the content that they're looking at is coming from. And one way of accomplishing this is by adding a header bar that displays the "true" origin of a page.
I hope the previous sections made it clear why these different URLs exist and why there needs to be a header in every AMP viewer. We have heard how you feel about this approach and the importance of URLs. So what next? As you know, we want to be thoughtful in what we do and ensure that we don't break the speed and performance users expect from AMP pages.
All Google URLs (i.e., the Google AMP cache URL and the Google AMP viewer URL) reflect the original source of the content as best as possible: www.google.com/amp/www.example.com/amp/doc.html.
When users scroll down the page to read a document, the AMP viewer header bar hides, freeing up precious screen real-estate.
When users visit a Google AMP viewer URL on a platform where the viewer is not available, we redirect them to the canonical page for the document.
In addition to the above, many users have requested a way to access, copy, and share the canonical URL of a document. Today, we're adding support for this functionality in form of an anchor button in the AMP Viewer header on Google Search. This feature allows users to use their browser's native share functionality by long-tapping on the link that is displayed.
In the coming weeks, the Android Google app will share the original URL of a document when users tap on the app's share button. This functionality is already available on the iOS Google app.
Lastly, we're working on leveraging upcoming web platform APIs that allow us to improve this functionality even further. One such API is the Web Share API that would allow AMP viewers to invoke the platform's native sharing flow with the original URL rather than the AMP viewer URL.
We as Google have every intention in making the AMP experience as good as we can for both, users and publishers. A thriving ecosystem is very important to us and attribution, user trust, and ownership are important pieces of this ecosystem. I hope this blog post helps clear up the origin of the three URLs of AMP documents, their role in making AMP fast, and our efforts to further improve the AMP experience in Google Search. Lastly, an ecosystem can only flourish with your participation: give us feedback and get involved with AMP.
Posted by Huibao Lin and Eyal Peled, Software Engineers, Google
At Google we believe in designing products with speed as a core principle. The Accelerated Mobile Pages (AMP) format helps ensure that content reliably loads fast, but we can do even better.
Smart caching is one of the key ingredients in the near instant AMP experiences users get in products like Google Search and Google News & Weather. With caching, we can make content be, in general, physically closer to the users who are requesting it so that bytes take a shorter trip over the wire to reach the user. In addition, using a single common infrastructure like a cache provides greater consistency in page serving times despite the content originating from many hosts, which might have very different—and much larger—latency in serving the content as compared to the cache.
Faster and more consistent delivery are the major reasons why pages served in Google Search's AMP experience come from the Google AMP Cache. The Cache's unified content serving infrastructure opens up the exciting possibility to build optimizations that scale to improve the experience across hundreds of millions of documents served. Making it so that any document would be able to take advantage of these benefits is one of the main reasons the Google AMP Cache is available for free to anyone to use.
In this post, we'll highlight two improvements we've recently introduced: (1) optimized image delivery and (2) enabling content to be served more successfully in bandwidth-constrained conditions through a project called "AMP Lite."
Image optimizations by the Google AMP Cache
On average across the web, images make up 64% of the bytesof a page. This means images are a very promising target for impactful optimizations.
Applying image optimizations is an effective way for cutting bytes on the wire. The Google AMP Cache employs the image optimization stack used by the PageSpeed Modules and Chrome Data Compression. (Note that in order to make the above transformations, the Google AMP Cache disregards the "Cache-Control: no-transform" header.) Sites can get the same image optimizations on their origin by installing PageSpeed on their server.
Here's a rundown of some of the optimizations we've made:
1) Removing data which is invisible or difficult to see We remove image data that is invisible to users, such as thumbnail and geolocation metadata. For JPEG images, we also reduce quality and color samples if they are higher than necessary. To be exact, we reduce JPEG quality to 85 and color samples to 4:2:0 — i.e., one color sample per four pixels. Compressing a JPEG to quality higher than this or with more color samples takes more bytes, but the visual difference is difficult to notice.
The reduced image data is then exhaustively compressed. We've found that these optimizations reduce bytes by 40%+ while not being noticeable to the user's eye.
2) Converting images to WebP format Some image formats are more mobile-friendly. We convert JPEG to WebP for supported browsers. This transformation leads to an additional 25%+ reduction in bytes with no loss in quality. 3) Adding srcset We add "srcset" if it has not been included. This applies to "amp-img" tags with "src" but no "srcset" attribute. The operation includes expanding "amp-img" tag as well as resizing the image to multiple dimensions. This reduces the byte count further on devices with small screens.
4) Using lower quality images under some circumstances We decrease the quality of JPEG images when there is an indication that this is desired by the user or for very slow network conditions (as part of AMP Lite discussed below). For example, we reduce JPEG image quality to 50 for Chrome users who have turned on Data Saver. This transformation leads to another 40%+ byte reduction to JPEG images.
The following example shows the images before (left) and after(right) optimizations. Originally the image has 241,260 bytes, and after applying Optimizations 1, 2, & 4 it becomes 25,760 bytes. After the optimizations the image looks essentially the same, but 89% of the bytes have been saved.
AMP Lite for Slow Network Conditions
Many people around the world access the internet with slow connection speeds or on devices with low RAM and we've found that some AMP pages are not optimized for these severely bandwidth constrained users. For this reason, Google has also launched AMP Lite to remove even more bytes from AMP pages for these users.
With AMP Lite, we apply all of the above optimizations to images. In particular, we always use lower quality levels (see Bullet 4 above).
In addition, we optimize external fonts by using the amp-fonttag, setting the font loading timeout to 0 seconds so pages can be displayed immediately regardless of whether the external font was previously cached or not.
AMP Lite is rolling out for bandwidth-constrained users in several countries such as Vietnam and Malaysia and for holders of low ram devices globally. Note that these optimizations may modify the fine details of some images, but do not affect other parts of the page including ads.
* * *
All told, we see a combined 45% reduction in bytes across all optimizations listed above. We hope to go even further in making more efficient use of users' data to provide even faster AMP experiences.
At Google I/O in May, we launched Rich Cards for Movies and Recipes, creating a new way for site owners to present previews of their content on the Search results page. Today, we’re expanding to two new verticals for US-based sites: Local restaurants and Online courses.
Evolution of search results for queries like [best New Orleans restaurants] and [leadership courses]: with rich cards, results are presented in new UIs, like carousels that are easy to browse by scrolling left and right, or a vertical three-pack that displays more individual courses
By building Rich Cards, you have a new opportunity to attract more engaged users to your page. Users can swipe through restaurant recommendations from sites like TripAdvisor, Thrillist, Time Out, Eater, and 10Best. In addition to food, users can browse through courses from sites like Coursera, LinkedIn Learning, EdX, Harvard, Udacity, FutureLearn, Edureka, Open University, Udemy, Canvas Network, and NPTEL.
If you have a site that contains local restaurant information or offers online courses, check out our developer docs to start building Rich Cards in the Local restaurant and Online courses verticals.
While AMP HTML is not required for Local restaurant pages and Online Courses rich cards, AMP provides Google Search users with a consistently fast experience, so we recommend that you create AMP pages to further engage users. Users consuming AMP’d content will be able to swipe near instantly from restaurant to restaurant or from recipe to recipe within your site.
Users who tap on your Rich Card will be taken near instantly to your AMP page, and be able to swipe between pages within your site.
Over a year has passed since the AMP Project first launched with the vision of making mobile web experiences faster and better for everybody. From the very beginning, we’ve maintained that the AMP project would support publishers’ existing business models while creating new monetization opportunities. With regards to advertising, this meant giving publishers the flexibility to use the current technology and systems they’re used to, and evolving user-first mobile web initiatives like AMP for Ads (A4A).
With a growing number of publishers embracing the speed of AMP, today we’re addressing some of the ways in which we’re helping you do more with ads on AMP.
Serve ads from more than 70+ ad tech providers
Keeping with the open source nature of the project, more than70+ advertising technology providers have already integrated with AMP. And that list is only growing. Existing tags that are delivered via a supported ad server also work in AMP. So, you can serve ads from both directly-sold campaigns as well as third-party ad networks and exchanges so long as they have support for AMP.
Keep 100% of the ad revenue
AMP is an open source project. It does not take a revenue share. AMP is not an advertising service provider or intermediary, and publishers can monetize AMP pages the same way you monetize HTML pages, keeping 100% of the revenue you earn based on negotiated rates with ad providers.
Choose the advertising experience on your pages
You can choose to serve any number of ads per page to serve in locations that works best for your content, including the first viewport. Just remember that regular ads in AMP load after the primary content. So, unless you’re loading the lightning fast A4A ads, we recommend placing the first ad below the first viewpoint to optimize for viewability and user experience.
Take advantage of video ad support
AMP currently supports 13 different video players, ranging from Brightcove to Teads, all of which can serve video ads. If you want to use a video player that is not currently supported in AMP, place the video player inside amp-iframe. Learn more.
Differentiate yourself with rich and custom ad formats
AMP accommodates a large variety of ad formats by default, ranging from publisher custom ad units to IAB standard outstream video and in-feed native ads. We value publisher choice and support efforts to create proprietary ad formats. For example, with responsive layouts in AMP, you can offer advertisers custom ads that can dynamically span the entire width of the mobile device. Learn more about how you can adapt your ads strategy for AMP.
Maximize revenue with interchangeable ad slots
In September 2016, both YieldMo and DoubleClick announced support for multi-size ad requests on AMP pages. With this launch, you can optimize yield by allowing multiple ad creative sizes to compete for each ad slot, capturing the most advertiser demand possible on AMP pages while still protecting the user’s experience.
Plan ahead with a view into AMP’s roadmap
Transparency is important to the success of any open source project and is a key value for AMP. Accordingly, we started publishing the AMP roadmap publicly nearly 6 months ago, including milestones for ads. These roadmaps are accompanied with bi-quarterly status updates and you can also see all AMP releases here.
Over 700,000 domains have published AMP pages and a good many are monetizing them with ads. Early studies suggest that ads on AMP are more viewable and engaging than ads on non-AMP mobile pages. That’s because with AMP, you don’t have to choose between good user experiences and monetization opportunities. When balanced and optimized, you can have both.
Reach out -- we’re eager to hear your suggestions and feedback to make sure that AMP pays off for everyone.
Posted by Vamsee Jasti, Product Manager, AMP Project