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
world
Android
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.
Project
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.
Android
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.
Kotlin
— 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.
Android
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
for the
Mobile Web: State of the Union talk to hear more about building rich mobile
web experiences.
Infrastructure and services to take mobile apps and the Web to the
next level
Firebase
— 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
businesses
Google
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.
Android
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
Actions
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
consoles.
VR
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
on g.co/gdd2017.
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
developer community.
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.
Pre-rendering works by loading a hidden iframe on the embedding page (the search result page) with the content of the AMP page and an additional parameter that indicates that the AMP document is only being pre-rendered. The JavaScript component that handles the lifecycle of these iframes is called "AMP Viewer".
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.
What's next?
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.
Since the launch of AMP in Google Search in Feb 2015, we have taken the following steps:
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.
Check out our developer site for implementation details.
To make it easier for you to create Rich Cards, we made some changes in our tools:
The Structured Data Testing Tool displays markup errors and a preview card for Local restaurant content as it might appear on Search.
The Rich Cards report in Search Console shows which cards across verticals contain errors, and which ones could be enhanced with more markup.
The AMP Test helps validate AMP pages as well as mark up on the page.
What’s next?
We are actively experimenting with new verticals globally to provide more opportunities for you to display richer previews of your content.
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
Accelerated Mobile Pages (AMP) is a great way to make content on your website accessible in an extremely fast way. To help ensure that your AMP implementation is working as expected , Search Console now has an enhanced AMP testing tool.
This testing tool is mobile-friendly and uses Google's live web-search infrastructure to analyze the AMP page with the real Googlebot. The tool tests the validity of the AMP markup as well as any structured data on the page. If issues are found, click on them to see details, and to have the line in the source-code highlighted. For valid AMP pages, we may also provide a link to a live preview of how this page may appear in Google's search results.
With the share button on the bottom right, you can now share a snapshot of the results that you're currently seeing with others. This makes it easier to discuss issues with your team, whether they're regular occurrences or one-time quirks that you need to iron out. Just click the share button and pass on the URL for this test snapshot. This share feature is now also available in the mobile-friendly testing tool.
We hope this tool makes it easier to create great AMP’d content while finding and resolving issues that may appear on your AMP pages. For any questions, feel free to drop by our webmaster's help forum.
Posted by Ofir Roval & Yaniv Loewenstein, Search Console team
Slow loading sites are arguably one of the most frustrating things about the mobile web. Recent Google research shows that 53% of people will leave a site that fails to load in three seconds or less. That’s problematic for users, businesses, publishers, websites and the mobile web as a whole.
Along with many others in the Accelerated Mobile Pages Project, we’ve been working to make the mobile web experience faster. In the year since we launched AMP, we’ve come a pretty long way, with players from across the web embracing this open source format.
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. And today we’re excited to be rolling out that faster experience to users in India.
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.
What this means for publishers and websites
Just how is that speed translating for publishers and websites that have AMP’d their content? Among news publishers, the first to get on board with AMP, there are a number of case studies that highlight real benefits when content loads fast. For example, the Washington Post has seen a 23% increase in mobile search users who return within 7 days, and an 88% improvement in load time for AMP content versus traditional mobile web.
To date we have over 600 million AMP documents created by sites such as eBay, Pinterest, Wordpress, and Reddit, and there are many more sites from all over the world and in over 104 languages. These pages cover retail, travel, recipe, general knowledge and entertainment. That’s a lot of fast-loading pages! For example, Zomato has seen great early results since AMPing their pages, with page load times decreasing from 3.8 seconds to well under a second. This is great news for Zomato, who are live with AMP in 23 countries, as they’re now more likely to see site visitors come back more often compared to those accessing non-AMP pages. A few other sites that have created AMP pages in India are News 18, NDTV and Aaj Tak.
While the first year of the AMP Project has gotten off to a great start, there still remains a lot of work ahead. This roadmap is a good way to stay up to date on what is happening next. We look forward to returning in a year’s time with even more progress as we work together to make the web great for everyone.
To find out more about AMP, check out ampproject.org.
Posted by Anuvrat Rao, Strategic Partnerships Development Manager, Google
It has been busy here at Google Webmaster Central over the last few weeks, covering a lot of details about Accelerated Mobile Pages that we hope you have found useful. The topics have included:
We’ve also been seeing a few AMP questions coming to the Webmaster forums about getting started using AMP on Google Search. To help, we’ve compiled some of the most common questions we’ve seen:
Q: I’m considering creating AMP pages for my website. What is the benefit? What types of sites and pages is AMP for?
Users love content that loads fast and without any fuss - using the AMP format may make it more compelling for people to consume and engage with your content on mobile devices. Research has shown that 40% of users abandon a site that takes more than three seconds to load. The Washington Post observed an 88% decrease in article loading time and a 23% increase in returning users from mobile search from adopting AMP.
The AMP format is great for all types of static web content such as news, recipes, movie listings, product pages, reviews, videos, blogs and more.
Q: We are getting errors logged in Search Console for AMP pages; however, we already fixed these issues. Why are we still seeing errors?
The short answer is that changes to your AMP pages take about a week to be updated in Search Console. For a more in-depth answer on why, Google’s Webmaster Trends Analyst John Mueller shared a detailed post on Search Console latency challenges.
Q: Our AMP pages are not showing up on Google Search. What should we do?
Only valid AMP pages will be eligible to show on Google Search. Check the validity of your AMP pages by using the AMP HTML Web Validator, the Chrome or Opera Extension or through a more automated process such as a cron job to make sure all new content is valid.
While it’s good practise overall to include schema.org structured data in your AMP pages (we recommend JSON-LD), it's especially important for news publishers. News content that includes valid markup properties are eligible to be shown within the Top Stories section in Google Search results. To test your structured data, try using the structured data testing tool.
