New Industry Benchmarks for Mobile Page Speed

The following is an excerpt from a Think with Google article by Daniel An, Global Product Lead, Mobile, Google.

The average time it takes to fully load a mobile landing page is 22 seconds, according to a new analysis. Yet 53% of mobile site visitors leave a page that takes longer than three seconds to load. That’s a big problem.

It’s no secret that shoppers expect a fast mobile experience. If there’s too much friction, they’ll abandon their cart and move on. Today, it’s critical that marketers design fast web experiences across all industry sectors. Consumers want to quickly pay bills on finance sites, get rapid results when they’re browsing vacation reviews, and view an article immediately when they click through.

Despite the fact that more than half of overall web traffic comes from mobile, our data shows that mobile conversion rates are lower than desktop. In short, speed equals revenue.

Our research has been eye-opening. For 70% of the pages we analyzed, it took nearly seven seconds for the visual content above the fold to display on the screen, and it took more than 10 seconds to fully load all visual content above and below the fold.

Recently, we trained a deep neural network—a computer system modeled on the human brain and nervous system—with a large set of bounce rate and conversions data. The neural net, which had a 90% prediction accuracy, found that as page load time goes from one second to seven seconds, the probability of a mobile site visitor bouncing increases 113%. Similarly, as the number of elements—text, titles, images—on a page goes from 400 to 6,000, the probability of conversion drops 95%.


Source: Google/SOASTA Research, 2017.

Learn more about this research, by checking out the full article on Think with Google.

To help improve these benchmarks, the AMP Project enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. Learn more at

New Industry Benchmarks for Mobile Page Speed

Grow Your Business with Ads on AMP

We understand that every business is different, but one thing common to them all in today’s mobile driven world is the need to ensure a fast user experience across all screens. That is why we believe the growing AMP ecosystem is so important. It brings together a diverse community of publishers, advertisers, and technology platforms all working together towards a better, faster, and more secure open web. Over 100 technology platforms currently support AMP, and the number continues to increase as each organization realizes the importance of delivering a fast user experience across all screens.

We also know that advertising is an important part of many web business. Many members of the AMP community have asked for guidance on how to best monetize their AMP pages. Today, we’d like to share our guide for serving ads on AMP. This guide brings together best practices from a range of publishers with the goal of helping you succeed with AMP in your own way.

One such publisher is Hearst Communications. To date, Hearst has published over one million AMP pages, and counting, across its various business units, resulting in significant improvements in viewability, ad engagement, and user traffic on properties such as Elle, Cosmopolitan, and

Hearst’s implementation of AMP exemplifies many of the best practices recommended in the guide. To ensure AMP fit their business needs, Hearst took the following steps:

First, they carried over their successful monetization strategies from non-AMP pages to AMP pages. They then started optimizing those strategies for AMP, continuously iterating and adapting to the results they saw.

Next, Hearst implemented more than 10 ad tech and analytics partners to supplement their monetization efforts. Coupled with the inherent speed of AMP, Hearst saw a 29% increase in ad viewability and 45% increase in CTR on their AMP pages.

As with any web page, simply publishing an AMP page doesn’t guarantee success — optimizing AMP to meet your business needs and partner relationships is key. As the ecosystem continues to grow, we look forward to seeing each and every success story as we collectively make the mobile web better for everyone.

Check out the ads on AMP guide here and see how other publishers are leveraging AMP to grow their business on mobile web.

To read more about Hearst’s approach to AMP, see the full case study here.

Posted by Vamsee Jasti, Product Manager, AMP Project

Grow Your Business with Ads on AMP

AMP Roadmap Update for Mid-Q1 2017

We’ve updated the AMP Roadmap with the details on progress during the first quarter of 2017, and you can read below for some of the highlights.


Interactivity is a major focus for us this quarter as we  build out the AMP format’s capabilities. amp-bind is a binding protocol that introduces lower-level methods for building interactive experiences. We’ve also launched two new features that enhance interactivity in their own right. amp-selector makes it easy to use image thumbnails as form inputs, and the goToSlide method supports new interactivity for amp-carousel, including galleries linked with image previews.

Another large focus is AMP Start, a set of quick-start code snippets that developers can copy and paste to quickly create and customize valid AMPs.


We introduced usability features with ads served to AMP pages. This includes an improvement to the default ad loading experience where AMP will, by default, clearly indicate the location of ads and add a subtle indicator when the ad is loading. Through this launch, we hope to eliminate the experience of seeing large blank spaces before a slow loading ad has loaded. We’ve also made some UX improvements to sticky ads that are gradually rolling out.

We’ve worked with Cloudflare and TripleLift to create and deliver AMP ads (ad creatives made in AMP format) that are safe, beautiful and performant ads. This paves the path for any ad network wanting to serve their own AMP ads to the publisher directly.


Soon you will be able to programmatically substitute values, including the Client ID, into links (anchor tags) and form inputs. We expect this to make it possible to build add-to-shopping cart flows, and to make scenarios involving multi-page flows and analytics data collection work better.

We’ve been thinking about ways to improve and extend amp-analytics infrastructure. We’re designing a way for extensions to take advantage of amp-analytics to report data to extension authors. This will provide extension authors with greater visibility into how their extensions are performing so they can spot issues and optimize behavior. We’re also close to completing an improvement to amp-analytics’s visibility features to use Intersection Observer.

Finally, in order to help AMP page developers understand the kinds of errors or issues that their users are encountering, we’re planning to introduce an analytics trigger that will send error events.

* * *

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

Posted by Eric Lindley, Product Manager, AMP Project

AMP Roadmap Update for Mid-Q1 2017

Better galleries and forms in AMP

We just released a couple of small tweaks in the AMP library that can make a big difference in building a better user experience.

First, a new JavaScript method (goToSlide) supports advancing <amp-carousel> to a particular slide on user tap/click. This enables significant UX enhancements to image galleries. Second, we’ve made it easier to integrate image thumbnails into forms with <amp-selector>. These will be useful to a lot of developers in providing engaging content to users, as in image-rich journalism and e-commerce product pages.

Using the goToSlide method: Carousel with thumbnails

Until now, <amp-carousel> hasn’t supported some key interaction patterns for image galleries. How does the user know how many images are in this carousel? What if they want to jump directly to image five in a carousel of eight? How does the user even know the carousel is swipeable, if they don’t notice the arrow icon, or if it’s been hidden on the page?

The solution, for many developers and designers, is to provide image thumbnails to the user. Tapping on these thumbnails will automatically advance the carousel to a specific slide.

This is now possible in AMP, using the goToSlide method. You, as a developer, can trigger this method on user tap to advance a slide carousel to a particular slide.

Example implementation

<!-- Primary Carousel -->
<amp-carousel id="carousel-with-preview"
<amp-img src=""
alt="a sample image"></amp-img>
<amp-img src=""
alt="a sample image"></amp-img>

<!-- Carousel thumbnails -->
<div class="carousel-preview">
<button on="tap:carousel-with-preview.goToSlide(index=0)">
<amp-img src=""
alt="a sample image"></amp-img>
<button on="tap:carousel-with-preview.goToSlide(index=1)">
<amp-img src=""
alt="a sample image"></amp-img>



If you have a lot of images, you can even put the thumbnails in a smaller scrollable carousel:

sub-carousel.gifSee AMP by Example for a sample implementation

This pattern pops up all over the web—e-commerce sites may find it especially useful on product pages.

Using <amp-selector>: Forms + image thumbnails

The previous two examples focused on use cases where images are important to a story or immersive experience, but images can also be useful to help users make selections when filling out forms. Using <amp-selector> makes this markup easy and semantically consistent. As a result, users understand their form selections in context. The experience becomes more informative, engaging, and easier to accomplish.

form.gifSee AMP by Example for a sample implementation

Try it out!

To get started with <amp-selector> and the goToSlide method, you can take a look at the documentation (goToSlide, <amp-selector>), check out working examples at AMP By Example (goToSlide, <amp-selector>), and give us feedback on what’s working and what’s not in the AMP GitHub repo. We look forward to hearing from you!

Posted by Eric Lindley, Product Manager

Better galleries and forms in AMP

What’s in an AMP URL?

The following was posted on the Google Developers Blog 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
  • 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.
  • Google AMP Viewer URL: The document displayed in an AMP viewer (e.g., when rendered on the search result page).

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 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 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.,; or the AMP Cache URL (e.g., 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 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, 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 2016, 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:
  • 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 Alex Fischer, Software Engineer, Google Search.

What’s in an AMP URL?

New default placeholders for ads in AMP

We want to share a somewhat small but visually impactful feature that we are planning to launch on AMP.

Content loads incredibly fast on AMP pages, but traditional ads often load relatively slowly. This leaves blank areas on publisher pages, which is a poor reading experience for the user as it can feel like the page is missing content.

To deliver faster, lighter and more secure ads that are as fast as your AMP content, consider switching over to AMP Ads.

In the meantime, in order to address the issue of blank ad spaces, we’ve added two default features to every ad placement on AMP pages. If an ad does not have a publisher-configured placeholder, AMP will automatically add:

  1. A clearly marked “Ad” label
  2. A subtle loading animation at the top indicating that the ad is loading


The new default ad loading indicator and placeholder feature

The clearly labeled placeholder allows the user to focus on the content and selectively shift their attention to ads. It also ensures that the user doesn’t think there is missing content while the ad is loading.


      A close-up of the subtle loading indicator

We realize this could be a breaking change for a few publishers who have already configured default placeholders on their pages, but these change come with significant user benefits described above. Publisher-configured placeholders will always retain full control over the ad loading experience.

We recommend that you try out how this treatment fits with existing content by opting into the AMP dev channel and subscribing into the ‘amp-ad-loading-ux’ experiment. This change is planned for a production release on Thursday Feb 9th, 2017.

We look forward to your feedback!

Posted by Vamsee Jasti, Product Manager, AMP Project

New default placeholders for ads in AMP