Why AMP is Fast

The AMP Project aims to bring instant rendering to web content. This is an unsorted list of optimizations that apply to all AMP based documents, which in aggregate makes them load fast. Every web page can have these optimizations, but AMP pages cannot not have them.

While this article is about optimizations in AMP, it might also be useful as a kind of todo list for optimizing a non-AMP website. If we are missing any optimization that might be benifitial to AMP, please leave a comment or send us a pull request.

Lazy loading

Resources are lazy loaded when it becomes likely that they’ll be seen by the user or when the document is otherwise idle.

Extensive use of preconnect

The new preconnect API is used heavily to ensure HTTP requests are as fast as possible when they are made. This helps makes lazy loaded requests faster when they are eventually made.

Prefetching of lazy loaded resources

Resources are loaded as late as possible, but prefetched as early as possible. That way things load very fast but CPU is only used when resources are actually shown to users.

All async JavaScript

AMP files are only valid if all JavaScript files are loaded asynchronously.

Inline style sheets

Only inline style sheets are allowed in AMP. This removes 1 or often more HTTP requests from the critical rendering path compared to most web pages.

Zero HTTP requests block font downloads.

Because all JS in AMP has the async attribute and only inline style sheets are allowed, no HTTP requests block the browser from downloading fonts.

Instant loading through prerendering

AMP is optimized for making it relatively “cheap” and reliable to prerender a resource. This means that it is rendered before the user explicitly states that they’d like to navigate to a page. With this a page might already be available by the time the user actually selects it, leading to instant loading.

While prerendering can be applied to all web content, that may (and does in practice) use up a lot of bandwidth and CPU. AMP is optimized to reduce both of these factors:

Prerendering only downloads resources above the fold

When AMP documents get prerendered for instant loading, only resources above the fold are actually downloaded. Details.

Prerendering does not render things that might be expensive in terms of CPU

When AMP documents get prerendered for instant loading, resources that might use a lot of CPU (like third party iframes) do not get downloaded.Details.

Intelligent resource prioritization

When AMP downloads resources it optimizes downloads so that those resources that are currently most important for the user are downloaded first.

Uncoupling of document layout from resource downloads

External resources such as images, ads or iframes need to state their size in the HTML. That means they don’t have to be downloaded first to layout the document.

Maximum size for style sheet

The inline style sheet has a maximum size. While this size is big enough for very sophisticated pages, it still requires the page author to practice good CSS hygiene.

FastDOM-style DOM change batching

We batch all DOM measure and mutate operations to minimize style recalculations in the browsers.

In practice this means that in each “animation frame” we first do all the DOM read operations, and then when those are done, do all the write operations. The result is a reduction to 1 style recalculation per frame.

Optimized for low count of style recalculations and layout

Independent of the above, AMP is optimized to avoid expensive style recalculations and layouts in the browser.

Mitigations for third party JS worst-practices such as document.write

In particular if third party JS uses the super-bad-for-performance “document.write” API, it does not block rendering the main page.

Runtime cost of analytics instrumentation is independent of number of used analytics providers

The way analytics are being implemented in AMP, pages that have more than one analytics provider do not get bloated with additional JavaScript and do not use significant extra CPU.

Extensions don’t block page layout

AMP supports extensions for things like lightboxes, instagram embeds, tweets, etc. While these require additional HTTP requests, those requests do not block page layout and rendering.

CDN delivery available to all AMP documents

AMP offers a proxy-based CDN for delivering all valid AMP documents, offering fast and reliable performance across all AMP content.

All resources and the document are loaded from the same origin through the same HTTP 2.0 tunnel

When using the proxy-based AMP CDN, the document, all JS files and all images are loaded from the same origin that is using HTTP 2.0 for maximum efficiency.

Animations can be GPU accelerated

The rules for animation related CSS in AMP ensure that animations can be GPU accelerated on modern devices, so they are smooth and buttery.

Posted by Malte Ubl, AMP Project Tech Lead at Google

Why AMP is Fast

Building a Faster Mobile Web Experience with AMP

As a discovery engine with billions of Pins, Pinterest works best when content is relevant, fast and easy to access. With more than 80 percent of Pinners using Pinterest on mobile devices, we’re excited to work on an industry-wide approach to a lighter-weight, speedier version of mobile web pages – Accelerated Mobile Pages (AMP) – with Google, WordPress, Twitter and the open-source community.

AMP is all about solving a pain point for everyone on the mobile web — speed. AMP is an open-source architecture for fast mobile-optimized content. It’s based on AMP HTML, a restricted subset of HTML, and a well-defined set of custom elements and JavaScript-based components. The result is an incredibly fast browsing experience that loads minimal data over the network.

In early tests, we found that AMP pages load four times faster and use eight times less data than traditional mobile-optimized pages. A better, faster mobile web is better for everyone, including users, platforms like Pinterest and publishers.

Pinterest Amplified

Pinterest Amplified.gif

Pinterest without AMP

Without AMP .gif

Delivering AMP content

Every Pin on Pinterest is a visual bookmark that links back to its original website. We periodically visits these sites using Aragog, our URL fetching system. We then parse the fetched HTML content using an internal system we call Atlas (which we’ll write about in the future). In addition to gathering metadata we include on Rich Pins, we also learn useful information about the page itself, such as its canonical link, primary language and whether it offers an AMP HTML version of its content. Publishers can use our URL Debugger to see how a page was parsed.

A page advertises its AMP HTML equivalent using a <link> relationship:

<link rel="amphtml" href="http://www.example.com/news/article.amp.html">

We record all of this information as part of the link’s entry within Aragog’s URLStore. We use this metadata, along with additional signals we’ve gathered to select the highest quality links we use within our applications. This provides Pinners with the best possible browsing experience whenever they click through on a Pin to learn more about it.

Pinterest widgets

We’ve also developed an AMP component that allows publishers to add Pin It buttons and embedded Pins to their AMP HTML pages.

The <amp-pinterest> extension was developed to take full advantage of AMP’s JavaScript runtime. This is great from a performance perspective, and it makes it incredibly easy for publishers to add Pinterest elements to their pages.

Here we have a Pin It button:

<amp-pinterest height=20 width=40 
data-description="Next stop: Pinterest">

Screen Shot 2015-12-14 at 1.06.28 PM

And here’s an embedded Pin:


You can create your own buttons and widgets for your AMP pages using our Widget Builder.

Looking ahead

We’re currently testing AMP pages with a small group of partners. We’ll continue working on and contributing to the AMP Project, and we encourage you to take a look at AMP for your site so we can make the mobile web better together.

Posted by Jon Parise, a software engineer on the Pinterest Product Platform team

Building a Faster Mobile Web Experience with AMP

Continued Momentum For The AMP Project

The AMP effort is building both momentum and speed. There has been significant progress not only since the Developer Preview in early October, but even since the last update a couple of weeks ago. Let’s take a look:

Google will begin sending traffic to AMP pages in Google Search as early as late February, 2016. Twitter will begin to experiment with linking to AMP content provided by publishers early in 2016. Pinterest, currently testing publisher AMP pages in their iOS and Android apps, found that AMP pages load four times faster and use eight times less data than traditional mobile-optimized pages. In addition, today we’re announcing that leading messaging apps LINE, Viber, and Tango will link to AMP content in early 2016 as well.

CMS and analytics providers are critical players in the AMP ecosystem and have stepped up with fantastic support for the initiative. WordPress will support all publishers that wish to enable AMP pages beginning in January. From the world of analytics, comScore, Chartbeat, Google Analytics, and Parse.ly will have AMP support in their tools by late February.

We also want to update you on four key areas of the AMP Project: Advertising, Analytics, Subscriptions, and Content Format Innovation.

  • Advertising: The initial roadmap for ads includes faster ads, ads that can resize, and support for viewability; as well as integration with certain data management providers, and sponsored content providers. While these new capabilities are being implemented in AMP, publishers and ad tech partners are working in parallel to implement and test them. Buyers have also been engaged: Annalect (Omnicom Media Group) is currently reviewing the project and excited about what AMP is trying to accomplish for users and advertising. Advertising companies that have expressed their intention to support AMP include: Outbrain, AOL, Taboola, OpenX, DoubleClick, AdSense, Pubmatic, Integral Ad Science, Moat, Smart AdServer, Krux, Polar, Nativo and Teads.tv.
  • Analytics: The design for a richer analytics framework was posted to Github in early November for feedback. Implementation is in progress, with the initial functionality landing in December and more coming in the subsequent weeks. Preliminary end-to-end testing for publishers and analytics vendors is expected to start in late December, with full testing happening in mid to late January. In addition to the analytics partners mentioned above, Nielsen, Adobe Analytics, and ClickTale have expressed their intention to support AMP in 2016.
  • Subscriptions: The design draft for metered paywall and subscription access is being reviewed with several publishers. The proposed solution covers metering and access for subscribers. Engineering is working out technical details on the spec and on prototyping the solution.
  • Content Format Innovation: New components and enhancements to existing ones continue to be designed and added to AMP. Highlights include amp-iframe, which now has resizing capability, and amp-click-to-play to enable a rich experience within an iframe once a user interaction has occurred. We now have templates to dynamically fetch fresh content, inspired by the need to support onward journey experiences. What’s more, several technology partners have contributed new code to AMP: Brightcove has submitted the amp-brightcove component to enable a Brightcove Video Cloud or Perform player to be displayed and Vine has built an amp-vine component to display a Vine embed. Several more initial format components have been prioritized and are being tracked on Github.

Many more new publishers have come on board to express their intention to support AMP next year.  These include Network18, NDTV, and DNA India in India; Tempo and Kompass in Indonesia; Chosun, Joongang, Maekyung, Yonhap, YTN, Newstapa, and Slow News in South Korea; Inquirer in the Philippines; Televisa and Grupo Expansión in Mexico; Fox News in the US; and LINE, Nikkan Sports, CINEMATODAY, and IID, Inc. in Japan. LinkedIn intends to support AMP in early 2016 by serving faster-AMP alternatives to its published content when available.

The AMP Project is working to make the mobile web experience better for everyone, and it is thrilling to be part of this industry-wide effort to reshape how content is consumed online.  In the coming weeks, look out for updates on new technology partners, new platforms, and new publishers, as well as the specific launch plans of supporting platforms. And in the meantime, we encourage you to create your first AMP page.

Posted by Richard Gingras, Head of News, Google

Continued Momentum For The AMP Project