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.

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 AMPproject.org.

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 Chron.com.

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

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.

Format

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.

Ads

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.

Analytics

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

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"
width="400"
height="300"
layout="responsive"
type="slides">
<amp-img src="https://example.com/path/to?image=10"
width="400"
height="300"
layout="responsive"
alt="a sample image"></amp-img>
<amp-img src="https://example.com/path/to?image=11"
width="400"
height="300"
layout="responsive"
alt="a sample image"></amp-img>
</amp-carousel>

<!-- Carousel thumbnails -->
<div class="carousel-preview">
<button on="tap:carousel-with-preview.goToSlide(index=0)">
<amp-img src="https://example.com/path/to?image=10"
width="60"
height="40"
layout="responsive"
alt="a sample image"></amp-img>
</button>
<button on="tap:carousel-with-preview.goToSlide(index=1)">
<amp-img src="https://example.com/path/to?image=11"
width="60"
height="40"
layout="responsive"
alt="a sample image"></amp-img>
</button>
</div>

 

 

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

See 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.

See 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

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

  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 http://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., http://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 http://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 http://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 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:
  

  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 Alex Fischer, Software Engineer, Google Search.

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

There are a lot of bad ads on the web today — ads that are slow, janky and don’t necessarily deliver great user experiences when they include annoying pop-ups or cause content to reflow on your screen. The net result: users install ad blockers, making it difficult for publishers to fund the content they’re creating, and hurting advertisers even when they use acceptable ad practices.

The AMP Project announced the open source AMP for Ads initiative in July to address this  issue and ensure users have great experiences on the web with both content and ads. The initiative’s goal is to fix the foundation of digital advertising on the web, applying the principles of AMP to advertising and making ads faster, more beautiful and secure.

Since the announcement, AMP Ads has seen a lot of momentum. Publishers across the world like The Washington Post, The Guardian, and USAToday have been testing AMP Ads via DoubleClick for Publishers.

Today, we’re sharing news that underscores the progress on the initiative.

TripleLift brings speed to native ads with AMP Ads

Native advertising platform TripleLift now serves AMP Ads for publishers and advertisers using their services. Time Inc is their first publisher partner testing AMP Ads.

Time Inc’s VP of Digital Revenue Strategy and Operations, Kavata Mbondo says, “AMP ads represent an opportunity to fix key issues with regards to ad experiences on the web. In our tests with TripleLift, AMP ads are already more viewable, up 13% from standard ads on AMP pages. We’ve also seen corresponding improvements in CTRs and eCPMs.”

TripleLift also found that AMP ads load 6x faster and are 3x lighter than comparable standard ads.

TripleLift’s President, Shaun Zacharia says, “As a native advertising platform, we want to make ads seamless with the pages in which they’re served in. Now with AMP for Ads, we get to realize that vision while ensuring we’re delivering the better ad performance our partners are looking for.”

Cloudflare now provides ad verification services for AMP Ads

Unlike standard ads, AMP ads must be verified by an authorized signing service before being served to a page. This is important to ensure both a fast and secure user experience. Signed ads allow AMP to trust that the ads are properly created in AMP format. This allows AMP to coordinate the ad experience alongside other components on the page, for a fast and reliable ad experience.

Cloudflare, a leading performance and security company, announced today an AMP ad verification and optimization service, Firebolt, that improves the ad experience for any 3rd party ad network or publisher. Utilizing Cloudflare’s AMP cache, Firebolt helps to deliver faster, safer, and more efficient ads.

This collaboration with the broader ad tech community is a true testament to the open source nature of the AMP Project.

Not your typical banner ad

One of the key tenets of AMP Ads is to ensure that while it makes user experiences better, it doesn’t throttle the creativity of advertisers and publishers. As you can see from the demo of USA Today’s early tests, you can deliver AMP ads using really creative ad formats. Importantly, more creative functionality is being added by the open source developer community with every passing week.

And that’s not all. We’re also working with agencies and buying platforms to ensure they have the tools they need to both build and deliver these fast AMP ad creatives. Advertising teams at Google are also looking into ways in which they can auto convert ads to AMP creatives so that advertisers can get better marketing performance from faster, better ad experiences.

This is the beginning of an exciting journey but there’s a lot more work ahead and we need to work together to ensure that ads remain the lifeblood of the internet. So get involved, join the AMP for Ads initiative, share your ideas and participate in a new fast, beautiful and open ads ecosystem.

Posted by Richard Gingras, VP – News, Google

Shz.de is one of the top news publishers in Schleswig-Holstein, Germany’s most northern state. Each month around 1.5 million unique users access our content to stay up to date on local news. In 2011 we saw an increasing number of our readers viewing content on their mobile phones, so we produced a mobile app, which has been downloaded over 40,000 times.

After 4 years of minor updates, we decided to completely rebuild our app because it was difficult and resource intensive to keep up with app store update cycles and RSS limitation. Our plan was to use mobile web content inside the app which gave us flexibility and cost-effective development, but we still wanted to ensure content loaded quickly inside the app. Our team learned about the Accelerated Mobile Pages project through documentation on AMPproject.org and by inspecting examples on ampbyexample.com. We were excited by the possibility of having content flexibility across platforms with near instantaneous page load times. “Our belief is that anything less than instant kills engagement. Why not integrate AMP article pages in our native apps?”, explains CEO Nicolas L. Fromm.

We piloted utilizing AMP pages inside our smallest mobile app and were extremely pleased with the results. With only a few hours of additional development work, we were seeing articles load 4x faster than in previous app versions. Additionally, pageviews per session increased by 25% – achieving our goal of both speed and engagement. With these initial easy wins, we quickly rolled out the AMP format to our other apps.

Using AMP pages inside our app has provided fantastic improvements with speed and user engagement, but we’re not stopping there. We’re now exploring improving caching and offline support in our app. We look forward to these future enhancements and are excited to share our success with AMP.  As Mr. Fromm said, “We’re in the business of creating engagement, building loyalty and monetizing quality journalism. Our main goal in building digital products is to create a frictionless and uninterrupted reading experience in our apps and news sites.”

Posted by Mario Lorenzen, Portal Manager, mh:n digital

I can’t believe it’s already been over a year since we started our quest for faster, friendlier web pages. Now that we’re out of the honeymoon phase, the AMP team is taking a hard look at where we are today, what’s to come, and the direction of the AMP ecosystem.

It’s easy to blaze ahead with the development of new features, but it’s infinitely harder to create a healthy, breathing ecosystem. To do so, we want to continue to involve all of you – the AMP community – in figuring out the right path together. How better to kickstart things than to meet up?

With that, it’s my great pleasure to invite you to our first-ever AMP Conf. First, the basics:

• March 7th and 8th
• At the Tribeca 360 space in New York
• Live-streamed around the world
• Two full days of talks and panels
• Targeted at web developers & designers

Whether you’re interested in or already building AMP pages, building a platform to display AMP content, or want to contribute to AMP itself (yes please!), we want you to participate. Request a seat to in person, or join via the live stream on YouTube.

Not only will the AMP team talk about new, exciting features and components – more than half of all talks and panels will be from you, members of the AMP ecosystem. We’ll discuss:

• The challenges and wins of running AMP in production
• How to create better, beautiful and interactive AMP pages
• How your AMP pages are distributed across platforms
• How to monetize AMP pages and the innovation happening around ads in AMP
• How you can contribute to AMP

We’ll follow up with a more detailed conference schedule by the end of January, and if you have any questions not covered in the FAQ, reach out to me (or amp-conf-2017@google.com) anytime.

See you soon!

Posted by Paul Bakaus, AMP Developer Advocate, Google

The following was posted on Medium by Paul Bakaus, AMP Developer Advocate, Google.

Caches are a fundamental piece of the Accelerated Mobile Pages (AMP) Project, yet one of the most misunderstood components. Every day, developers ask us why they can’t just get their AMP pages onto some AMP surfaces (e.g. Google) without linking through the cache. Some worry about the cache model breaking the origin model of the web, others worry about analytics attribution and canonical link sharing, and even others worry about their pages being hosted on servers out of their control. Let’s look at all of these, and understand why the caches exist.

While AMP Caches introduce some trade-offs, they do work in the user’s favor to ensure a consistently fast and user-friendly experience. The caches are designed to:

• Ensure that all AMP pages are actually valid AMP.
• Allow AMP pages to be preloaded efficiently and safely.
• Do a myriad of additional user-beneficial performance optimizations to content.

But first:

The Basics: Analytics attribution and link sharing

Even though the AMP Cache model doesn’t follow the origin model (serving your page from your own domain), we attribute all traffic to you, the publisher. Through the <amp-analytics> tag, AMP supports a growing number of analytics providers (26 to date and growing!), to make sure you can measure your success and the traffic is correctly attributed.

When I ask users and developers about why they want to “click-through” to the canonical page from a cached AMP result, the answer is often about link sharing. And granted, it’s annoying to copy a google.com URL instead of the canonical URL. However, the issue isn’t as large of a problem as you’d think: Google amends its cached AMP search results with Schema.org and OpenGraph metadata, so posting the link to any platform that honors these should result in the canonical URL being shared. That being said, there are more opportunities to improve the sharing flow. In native web-views, one could share the canonical directly if the app supports it, and, based on users’ feedback, the team at Google is working on enabling easy access to the canonical URL on all its surfaces.

With these cleared up, let’s dig a little deeper.

When the label says AMP, you get AMP

The AMP Project consists of an ecosystem that depends on strict validation, ensuring that very high performance and quality bars are met. One version of a validator can be used during development, but the AMP Cache ensures the validity at the last stage, when presenting content to the user.

When an AMP page is requested from an AMP Cache for the first time, said cache validates the document first, and won’t offer it to the user if it detects problems. Platforms integrating with AMP (e.g. Bing, Pinterest, Google) can choose to send traffic directly to the AMP page on the origin or optionally to an AMP Cache, but validity can only be guaranteed when served from the cache. It ensures that when users see the AMP label, they’ll almost always get a fast and user friendly experience. (Unless you find a way to make a slow-but-valid AMP page, which is hard, but not impossible… I’m looking at you, big web fonts).

Pre-rendering is a bigger deal than you think

If you take anything away from this post, it’s that pre-rendering, especially the variant in AMP, greatly outweighs any speed gains you could theoretically get by hosting directly from an origin server. Even if the origin server is closer to your users, which would shave off a few milliseconds — rare but possible — pre-rendering will almost certainly drive the most impact.

Perceived as much faster

In fact, pre-rendering can often save you seconds, not milliseconds. The impact of pre-rendering, as opposed to the various other performance optimizations in the AMP JS library, can be pretty dramatic, and contributes largely to the “instant-feel” experience.

Very efficient compared to full pre-rendering

If that was the whole story, we could just as easily pre-render AMP pages from their origin servers. If we did, we couldn’t guarantee that a page is valid AMP on the origin, and valid AMP is critically important for the custom pre-rendering the AMP JS library provides: Pre-rendering in AMP, as opposed to just pre-rendering an entire page through something like link prefetching, also limits the use of the users’ bandwidth, CPU and battery!

Valid AMP documents behave “cooperatively” during the pre-render stage: Only assets in the first viewport get preloaded, and no third-party scripts get executed. This results in a much cheaper, less bandwidth and CPU-intensive preload, allowing platforms to prerender not just the first, but a few of the AMP pages a user will likely click on.

Safe to embed

Because AMP Caches can’t rely on browser pre-rendering (see the section above), normal navigation from page to page doesn’t work. So in the AMP caching model, a page needs to be opened inline on a platform page. AMP Caches ensure that the requested AMP page can do that safely:

• Validator ensures no Cross-Site Scripting (XSS) in main document.
• On top of the validator, the AMP Cache parses and then re-serializes the document in an unambiguous fashion (this means that it does not rely on HTML5 error correction). This ensures that browser parsing bugs and differences cannot lead to XSS.
• The cache applies a Content Security Policy (CSP). This provides additional defense-in-depth against XSS attacks.

Additional privacy

In addition, the AMP Caches remove one important potential privacy issue from the pre-render: When you do a search on a content platform preloading AMP pages on the result page, none of the preloaded AMP pages will ever know about the fact that they’ve been preloaded.

Think about it this way: Say I search for “breakfast burrito”. If you know me well, you know I obviously searched for Parry Gripp’s song with the same name. But the search result page also shows me a couple of AMP search results from fast food chains that sell actual breakfast burritos. For the next month, I wouldn’t want to see actual breakfast burritos everywhere even though I didn’t click on these links (even though…maybe I do…mhh..), and an advertiser wouldn’t want to waste dollars on me for pointless re-marketing ads on all the burritos. Since AMP hides the preload from the publisher of the AMP page and related third parties, it’s a win win scenario for users and advertisers.

Auto-optimizations that often result in dramatic speed increase

The AMP Cache started out with all of the above, but has since added a number of transformative transformations (heh) to its feature roster. Among those optimizations:

• Consistent, fast and free content delivery network for all content (not just big publishers).
• Optimizes HTML through measures such as bringing scripts into the ideal order, removing duplicate script tags and removing unnecessary quotes and whitespace.
• Rewrites JavaScript URLs to have infinite cache time.
• Optimizes images (a 40% average bandwidth improvement!)

On the image compression side alone, Google, through its cache, is doing lossless (without any visual change, e.g. removes EXIF data) and lossy (without noticeable visual change) compression. In addition, it converts images to WebP for browsers that support it and automatically generates srcset attributes (so-called responsive images) if they’re not already available, generating and showing correctly sized images to each device.

Isn’t there a better way of doing this?

Look, I hear you. The provider of an AMP Cache is mirroring your content. It’s an important role and comes with great responsibility. If the cache provider were to do something truly stupid, like inserting obnoxious ads into every AMP page, AMP would stop being a viable solution for publishers, and thus wither away.

Remember, AMP has been created together with publishers, as a means to make the mobile web better for publishers, users and platforms. It’s why the AMP team has released strict guidelines for AMP Caches. To give you two interesting excerpts, the guidelines state that your content needs to provide “a faithful visual and UX reproduction of source document”, and cache providers must pledge that they will keep URLs working indefinitely, even after the cache itself may be decommissioned. These, and many more rules, ensure that a cache doesn’t mess with your content.

Most importantly, there’s plenty of room for more than one AMP Cache – in fact, Cloudflare just announced their own! With these AMP Cache guidelines released, other infrastructure companies are welcome to create new AMP Caches, as long as they follow the rules. It’s then up to the platform integrating AMP to pick their favorite cache.

From cache to web standards?

You just read about all the wins and trade-offs the AMP Caches do to provide an instant-feeling, and user friendly mobile web experience. What if we could get to many of the same awesome optimizations without the trade-offs, and without involving a cache at all?

Personally, I dream of future, still-to-be-invented web standards that would allow us to get there – to move beyond cache models (like a static layout system to know how a page will look like before any assets are loaded).

In 2016, we’ve done our first baby steps with the CPP, which turned into the Feature Policy: A way of saying things like “I disallow document.write on my site, and any third parties in any iframes that get loaded”. More advanced concepts like static layouting and safe prerendering require far-fetching changes to the web platform, but hey – just like forward time travel, it’s not impossible, just very, very difficult 🙂

Join me in figuring this out by getting in touch on Twitter or Slack, and know that I’ll always have an open ear for your questions, ideas and concerns. Onwards!

Posted by Paul Bakaus, AMP Developer Advocate, Google