AMP

AMP Contributor Summit 2019 Applications Now Open

Developer Experience, Events

Applications for the AMP Contributor Summit 2019 are now open!  If you have contributed to the AMP open source project–or want to start–please apply to attend today.

This year’s summit will take place in New York City on October 9 & 10, with an optional New Contributor Workshop / Hackathon Day on October 8.

The AMP Contributor Summit is our annual opportunity for the AMP open source community to meet face-to-face to discuss the latest in AMP and where AMP is going.  This technical summit consists of a mix of different formats, including talks, breakout sessions and many opportunities for informal conversations.

The day before the main summit kicks off, we’ll have an optional New Contributor Workshop / Hackathon day, with two different tracks depending on your experience:

  • If you haven’t contributed to AMP before or want a refresher, we’ll have a New Contributor Workshop with talks and codelabs to get you up to speed on how to contribute to AMP.
  • If you already have some experience contributing to AMP, we’ll have a Hackathon for people who want to have a fun, concentrated day of coding with others in the community to make AMP better.

100% of those who responded to a post-summit survey for last year’s AMP Contributor Summit said they’d recommend the event, and our goal is to make this summit even better.

Apply to attend the AMP Contributor Summit by July 22, 2019.  We’ll get back to all applicants soon after that.

All of the content for the summit comes from the community, including the talks!  Please help us craft the summit agenda by proposing a talk or letting us know what topics/speakers you’d suggest by August 15, 2019.  

If you have any questions, please reach out to ampcs2019-support at amp.dev.

We’re looking forward to seeing you in NYC in October!

Posted by Joey Rozier, member of AMP’s Outreach Working Group and Engineering Manager, Google

Learn web development with AMP!

Developer Experience, Websites

We’re excited to announce the release of our new courses that teach AMP. Appropriately, they’re called Web Development with AMP!

We think AMP is an excellent starting point for aspiring web developers. After all, AMP lets you create interactive websites without having to use JavaScript. If you know a bit of HTML and CSS, but haven’t yet learned JavaScript, you can use AMP to create interactive websites.

On the other hand, if you’re an experienced web developer, and you’re seeking a simpler way to build performant, well-behaved websites, these courses are for you too.

Finally, if you teach web development, these courses are free to use. For beginners, these AMP courses bridge the gap in a curriculum between HTML/CSS and JavaScript. Others can use the courses to pick up the principles of AMP quickly.

Web Development with AMP is divided into beginning, intermediate, and advanced courses. These are available in many forms:

What’s coming next?

  • Videos for the other two courses will appear later this summer.
  • We’ll also be providing compressed versions of these courses for developers who are either more experienced or impatient.

Enjoy!

Posted by Ben Morss, Developer Advocate at Google

Introducing Cloudflare AMP Real URL

Developer Experience, Signed Exchanges

The following post was written by Zack Bloom, Director of Product and John Graham-Cumming, CTO at Cloudflare

Join us for a free webinar this week where we will cover how Cloudflare is helping its customers drive better results with AMP, and increasing conversions.

The promise of the AMP project was that it would make the web, and, in particular, the mobile web, much more pleasant to surf. The AMP framework was designed to make web pages load quickly, and place the focus on the user experience.

Initially, it was particularly aimed at publishers (such as news organizations) that wanted to provide the best, fastest web experience for readers catching up on news stories and in-depth articles while on the move. It later became valuable for any site which values their mobile performance including e-commerce stores, job boards, and media sites.

As well as the AMP HTML framework, AMP also made use of caches that store copies of AMP content close to end users so that they load as quickly as possible. Although this cache makes loading web pages much, much faster they introduce a problem: An AMP page served from Google’s cache has a URL starting with https://google.com/amp/. This can be confusing for end users.

Users have become used to looking at the navigation bar in a web browser to see what web site they are visiting. The AMP cache breaks that experience. By serving the page from Google’s cache they may be confused by the ‘google.com’ URL they see in the address bar.

Last November we at Cloudflare announced a technical solution to these problems that would allow AMP pages to be served from a cache while retaining the original page URL and all its benefits. The in-depth technical blog post by Gabbi Fisher and Avery Harnish gives the full details. The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from.

In cooperation with a browser that understands Web Packaging, this means that a page can be stored in an AMP cache and served quickly from it while showing the original site URL in the browser’s navigation bar. A major win all round!

We’re calling this “AMP Real URL” and it’s free to all Cloudflare customers.

How It Works

Google’s AMP Crawler downloads the content of your website and stores it in the AMP Cache many times a day. If your site has AMP Real URL enabled Cloudflare will digitally sign the content we provide to that crawler, cryptographically proving it was generated by you. That signature is all a modern browser (currently just Chrome on Android) needs to show the correct URL in the address bar when a visitor arrives at your AMP content from Google’s search results.

More importantly, your site is still being served from Google’s AMP cache just as before; all of this comes without any cost to your SEO or web performance.

Want to Learn More?

We will be hosting a webinar on Wednesday, June 19th at 10:00 am PDT “Building AMP Experiences that Drive Results” that will feature a broader understanding of AMP architecture and how AMP Real URL leverages Cloudflare’s serverless platforms to deliver signed exchanges. U.S. Xpress will also share insights and results that they’ve experienced having deployed Cloudflare AMP Real URL for their AMP content.

Register today!

Innovation in navigation on the web platform

Web Standards

In this third post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of innovating on the concept of navigation for web content. Additionally, we’re taking a look at how new primitives in the web platform are helping to make AMP simpler and “less of a thing”.

If you haven’t read the first or second post, we’d suggest to hop over there before reading this.

For as long as the web has existed, navigation meant that when the user clicked a link, the browser would paint white, and eventually it would paint the new page and update the URL bar. While this is an amazing model, more sophisticated interaction patterns have emerged on mobile. So far it has only been possible to implement these on the web using complicated “single-page app” patterns that use iframes for third-party content. Iframes are a great asset to the web platform. They enable composability, one of the SLICE special powers of the web. Unfortunately, the composability enabled by iframes inherently results in restrained user experiences. An iframe is like a fixed window: it lets you see into another world, but since it can’t be opened it doesn’t let you cross to the other side. The Chrome team took notice of an early exploration called iframe promotion which was designed to give iframes the ability to be navigated to. After a few rounds of discussion to build on this idea, the Chrome team identified a way to avoid the architectural complexity of a solution based on iframes and proposed a similar approach called Portals which allows for unfettered composability.

https://blog.amp.dev/wp-content/uploads/2019/06/portals_h264.mp4
Portals demo

We’ve seen a lot of interest about Portals from the web community, if only because they’ll allow for applications with the simplicity and robustness of having single pages per URL with the interaction fidelity of single-page apps.

With Portals we hope to be able to implement experiences like Google’s Top Stories carousel without having to rely on application layer solutions like AMP. Beyond that there are a lot of exciting use cases for Portals such as payment or single-sign-on solutions that are visually integrated into a website, but when activated show the user the true origin they are interacting with such as their payment provider.

Simplifying AMP

Putting all the things we introduced in this and previous posts together, one cool side-effect of the web platform getting more powerful is that we are getting ready to make large chunk of AMP literally go away and be replaced by simple platform primitives.

One example that is within arm’s reach is the removal of amp-img as a web component. With lazy loading, priority hints, and intrinsic sizing being implemented in browsers, it is possible to see a future in which there is no longer a need for the custom component–and while it’ll stick around for backward compatibility, it makes us incredibly happy to make AMP less complicated and instead focus even more on providing high level components in an easy to use framework, as opposed to the platform magic on top to make it all work.

Summary

A lot of progress has been made over the last year in advancing web standards along various dimensions. Above we highlighted the areas that the AMP team together with our friends from Chrome and Igalia have invested the most time on, but we also want to recognize that lots of other folks in the entire web community are doing awesome work on web standards which are helping make the web better every day. The AMP team is learning a lot from the web community and is currently most excited about isInputPending, display locking, and Animation Worklet.
Concrete proposals for privacy-preserving instant loading, innovative navigation, performance assessment, and development guardrails are now on the table and in varying stages of implementation. We hope that these projects are a step in the right direction to help all web developers create more delightful experiences regardless of implementation choices. We are eager to hear your feedback and can’t wait for the progress that will be made in the next year!

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google 

Save the Date – AMP Contributor Summit 2019

Developer Experience, Governance

This year’s AMP Contributor Summit will be held October 8-10, 2019 in New York City, and we need your help to help make it happen!

The AMP Contributor Summit is a technical summit for AMP’s open source contributors.  At the first AMP Contributor Summit last year more than 80 members of the community got together to meet face-to-face, talk about the latest developments in AMP and discuss where AMP should head into the future.  At the end of the summit 100% of those who responded to a post-summit survey said they’d recommend the summit to members of the community.

Starting this year the AMP Contributor Summit will be organized by the community with guidance from the Outreach Working Group.  We’re looking for volunteers to help with all of the aspects of planning a successful summit–everything from setting a theme to vetting talks to dealing with schedule logistics.

If you’re excited about bringing the AMP community together and would like to get involved in planning the summit, please let us know by Tuesday, June 11.  We’re planning on having an organizational kickoff meeting on June 12 and it would be great to have you there!

If you have any questions, reach out to mrjoro on Slack or GitHub.

For everyone in the community, please save the dates of October 8-10, 2019, and keep an eye out for details on applying to attend the summit soon!

Posted by Joey Rozier, member of AMP’s Outreach Working Group and Engineering Manager at Google


Debunking Common AMP Myths

Ecommerce, Websites

AMP is a great and easy way to build very fast sites. Since its launch in 2015, AMP has grown to power billions of pages across the web from tens of millions of domains. We’ve seen many examples of businesses in both the publishing and e-commerce spaces see success with implementing AMP on their websites. As the AMP project has grown, we have noticed a number of misconceptions & myths have arisen — so we thought we would take this opportunity to bust some of the most common myths about AMP.



MYTH: AMP is exclusively a Google project.
FACT: AMP is an open source initiative led by Google along with other companies and members of the web community.

AMP developers, companies and individual contributors participate in the development of this project: Over the last 3 years, AMP received contributions from 850+ contributors, 78% of whom were employed by companies other than Google, such as Twitter, Pinterest, Yahoo, Bing, and eBay. AMP moved to a new governance model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users, and representation from companies such as Twitter, Microsoft, Pinterest, The NY Times, Washington Post, AliExpress and many others.

MYTH: AMP only works from Google.com.
FACT: AMP pages are accessible across the web including any distribution platform and device.

Users can access AMP pages via links on distribution platforms (e.g., search engines) or sites. Some platforms (e.g., Google, Bing, LinkedIn, Twitter, Yahoo JP, Baidu and more ) will always serve AMP pages by default on mobile, when available. Some platforms (e.g., google.com, bing.com) take an extra step to cache your content for a much faster user experience.

MYTH: AMP is only for mobile.
FACT: AMP is designed with responsiveness in mind, to work across all screen sizes.

AMP is now just AMP, and does not stand for Accelerated Mobile Pages anymore. AMP isn’t just for mobile, it not only works across many device types including desktop and tablet but comes with super handy responsive design features. AMP is designed to be mobile friendly, and with slow hardware and high latency connections, the boost you get with AMP on smartphones is going to be felt a lot stronger than on desktops. It should also be understood that some features for third-party platforms (e.g., Google’s Top Stories carousel) may only be designed for the mobile experience. For more information, see this article.

MYTH: Every AMP page has to also have a non-AMP version.
FACT: An AMP page can be associated with a non-AMP version, but it’s not a requirement.

In some cases, you might want to have both a non-AMP and an AMP version of the same page, especially during the early phases of your AMP migration when you might want to also support testing AMP and non-AMP. But this is not a requirement and you don’t need to maintain two versions of the same content if you think AMP is the right solution for your business. You can choose to have one page, and that page could be an AMP page. This means lower maintenance costs to build, maintain, and monitor a single version of each document (as opposed to building both a non-AMP and paired AMP page). More details here.

MYTH: AMP landing pages are usually difficult to build.
FACT: It typically takes less than a week to build AMP landing pages for the majority of page types and use cases.

80% of development teams we contacted said they built AMP Landing Pages in less than a week. Having said that, AMP development effort varies on the page type. Some AMP pages can be built within a day, others take longer. Check out amp.dev for some free AMP templates to reduce your development time even further.

MYTH: AMP is only for publishers or static websites.
FACT: More than 60% of Google Search clicks to AMP pages go to non-news sites.

AMP is built thanks to a deep collaboration with thousands of developers, publishers and websites, distribution platforms and tech companies. When AMP first launched, it was initially adopted by publishers but now advertisers and e-commerce companies are also leveraging AMP to gain speed benefits. Read some of the success stories on our site.

MYTH: AMP doesn’t support interactive experiences.
FACT: AMP components now enable design customization and interactive experiences.

When AMP first launched, it had limitations to visual design. As the AMP project has grown thanks to the collaboration of the open source community, new components have been built that allow companies to do design customization and create interactivity. Today, most interactive experiences are supported:

  • Rich Media: there are ever increasing AMP components and anyone can contribute if something is missing.
  • Third-Party (3P) integrations: there are many available now and growing.

Companies such as BMWAliExpress and Rep from La Repubblica have been able to build great interactive experiences on AMP, with some using AMP for the majority of their site pages.

MYTH: AMP is not capable of supporting e-commerce websites.
FACT: AMP is a natural fit for e-commerce because AMP makes web pages fast, and fast pages help with purchase conversions.

When AMP first launched, it was initially adopted by publishers. As the AMP project has grown, new components have been built that allow brands to create interactive experiences. We are excited by the speed with which the internet is adopting and extending the AMP platform, and AMP can be used to build a fast, beautiful e-commerce experiences. For more details, check “Getting started with AMP for e-commerce” and “E-commerce At The Speed of AMP” blog posts.  

MYTH: It’s not possible to serve fresh content on AMP Pages.
FACT: There are many options to keep content on AMP pages up to date.

You can serve fresh content on AMP either relying on the default AMP Cache mechanism (stale-while-revalidate), using the update cache functionality, or using dynamic components (like amp-list). Many big e-commerce companies have demonstrated great success when implementation is planned properly.

MYTH: AMP is not secure/private enough.
FACT: The AMP framework is built to preserve privacy and ensure data security.

AMP landing pages are often served from the Google AMP Cache, which simply caches a version of your AMP landing page for purposes of validating AMP documents and for providing reliable, fast delivery. The Google AMP Cache as well as AMP JavaScript are served from cookieless domains that do not track users in any way. Additionally, AMP has a security review process that is routinely used when launching new AMP components. For further reading we recommend this blog post “Privacy and user choice in AMP’s software architecture”.

MYTH: AMP pages don’t convert as well as non-AMP pages.
FACT: Properly optimized AMP pages often perform better than their non-AMP equivalents.

Many advertisers and publishers have seen success with AMP as documented on amp.dev. A study from Forrester found that a site implementing AMP could expect 20% increase in sales conversion rate on AMP pages, 10% year-over-year increase in AMP site traffic, and 60% increase in pages per visit. There are a few reasons why an AMP page might appear to perform less well than an non-AMP page. If you are seeing poor performance, these are a few areas to explore:

  • Measurement and tracking issues: Make sure you’ve setup analytics on your AMP page using the following two setup guides.
  • Inconsistent landing pages: If AMP page looks different from non-AMP page, it can affect conversion rates. Landing pages should be identical both in appearance and in function in order to accurately assess AMP performance. Also make sure you offer user-friendly landing pages.

You can check this blog post for the things to keep in mind when testing and evaluating AMP.

Posted by Cemal Buyukgokcesu, Global Product Lead, Mobile Web, Google

Privacy-preserving instant loading for all web content

Web Standards

In this second post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of instant loading. If you haven’t read yesterday’s post, we’d suggest to hop over there before reading this.

So what is privacy-preserving instant loading? It can be summarized as:

  • Instant loading means link navigations work instantly without any perceivable wait time.
  • In general that means they work without going to the network, because the network may be slow.
  • But not going to the network when the user clicks means to request the page some time before the user really initiated the navigation.
  • This may leak sensitive information to the page, such as that the user is interested in it, without user consent.
  • Privacy-preserving instant loading is instant loading where this information leak does not happen.

For more on this topic, see our post on privacy and user choice in AMP’s software architecture.

Below we describe a set of changes that combined enable content sharing websites, social media platforms, and search engines, such as Google Search, to provide privacy-preserving instant loading for web content that is not based on AMP.

After an extensive process where both AMP and Chrome teams identified and assessed potential solutions, encouraged by W3C TAG’s recommendation, Chrome’s web platform team eventually convinced us to explore the emerging Web Packaging standard and its component Signed Exchanges (SXG), and further invest in its standardization and implementation. SXGs help with privacy-preserving instant loading by allowing the referring site (such as the search engine) to load a resource from a trusted server without leaking any additional information to a third-party. Then, once the user navigated to the SXG, everything behaves just like any other web navigation (except for the faster load).

SXG support has recently landed in the stable version of Chrome, but is not yet available in non-Chromium based browsers. SXGs are a big step for the web platform: They disentangle attribution (who created a piece of content) from initial delivery (how is the initial view of the content delivered to the user), and guarantee content integrity (the content distributor cannot change it). While this creates exciting new opportunities like a more decentralized web, it also creates new security challenges that need to be worked through diligently.

On top of SXG support, we’ve worked with Igalia on making prefetching available across browsers. While <link rel=prefetch> had been specified for a while and widely used, it wasn’t available in browsers like Safari because of incompatibilities with double-key caches. The Chrome team proposed and discussed a change that makes prefetching compatible with double-keying, and Igalia’s patch just landed in WebKit.

Additionally, the Chrome team worked with the community on clarifying the spec for nested prefetches, i.e. when a prefetched resource schedules additional sub-resources to be downloaded. A Chromium contributor subsequently added support to preload for image srcsets after discussion with other w3c members and our partners at Igalia, who help us with implementing web features in WebKit, have recently landed similar patches in WebKit.

Summary

This was part 2 in our series of contributing lessons learned from AMP to the whole web. We’ve now discussed how to measure performance at scale and how to enable instant loading for web content. In the next post in the series we’ll talk about ideas for how to innovate on the concept of navigation.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google 

A year into contributing back lessons learned from AMP to the whole web

Web Standards

In March of 2018 we wrote about our effort to contribute back the things we learned from AMP for the benefit of all web developers by addressing gaps in the web platform. In this work we’ve collaborated with the Google Chrome team, Igalia, who is helping us with implementation work in WebKit, and, of course, the wider web standards community. We’ve also learned a lot from the community and have seen a lot of exciting work that we can’t wait to apply. This is an update on how that effort is going.

Our work has focused on bringing the benefits that AMP implemented on the application layer to the whole web platform (AMP or otherwise):

  • Measuring performance and user experience: Make it possible to objectively measure high load performance and certain UX properties, such as a stable loading experience without content that is shifting around as it loads.
  • Privacy-preserving instant loading: Allow the preloading of web content, before a user clicks, without leaking the user’s interest in the page to the page author until the user navigates.
  • Innovation in navigation: Navigation from one web page to another through means other than the traditional click. E.g. by swiping through a carousel or scrolling from one article to another one.
  • Guardrails: Provide a mechanism for development teams to avoid the use of certain legacy features of the web platform that are harmful to UX. Give development teams  similar control over the behavior of third-party code.

We’ve made significant progress distilling our original wide-ranging ideas and worked with the web community to turn them into concrete standard proposals. This is a lot to go through, so we’ll split things up into a series of posts starting with the topics Measuring performance and user experience and Guardrails today.

Measuring performance and user experience

The AMP team often gets the question: Why don’t you just measure whether a page is fast instead of relying on AMP? And we agree, that is a good question.

One of the big changes in the web space since AMP was created is that there are now tools like the Chrome User Experience Report, which do, in theory, provide a way to get performance data for most sites on the web. Looking at this further we realized, however, that the existing metrics are insufficient to really make statements about the desirable user experience properties of web pages.

Legacy metrics like onload aren’t great proxies for user-perceived performance. Pages can both appear loaded long before onload fires and can appear NOT to have loaded long after onload fires.

One modern metric, First Contentful Paint (FCP), is the only currently available candidate metric for measuring perceived performance at scale. Unfortunately, while good user experiences always have a good FCP, having a good FCP is insufficient to really know whether a page is fast. FCP should probably have been called First Not-Completely-Trivial Paint because it is clear that users would in many instances not consider a page to be sufficiently rendered at the time of its FCP. For example, a loading indicator would trigger FCP, but the user wouldn’t be happy at this stage.

For these reasons we invested in defining additional metrics that would paint a more holistic image of user perceived performance. The two metrics currently under discussion are Largest Contentful Paint (LCP, name subject to change), which fires when the largest element of text or image on a page has painted, and Layout Stability, which is an indicator for how stable the layout is during page load. We’re hoping that these metrics, together with First Input Delay, which is further along in standardization, would allow one to say with reasonable confidence whether a page is fast and well-behaved from a user point of view.

An example of a page doing badly on the layout stability metric.

Guardrails

AMP introduced the AMP validator to ensure that documents complied with a range of best practices and to give helpful error messages when they didn’t. Based on earlier work by Tim Kadlec and Yoav Weiss on the Content Performance Policy idea, the notion of Feature Policies was developed through discussions with the web community. They provide both a way to turn off harmful legacy features, such as synchronous XHR, and to report violations of best practices, such as loading images that are much bigger than necessary, to the development team of a website.

A whole range of Feature Policies are in the works now covering many aspects of web development. One interesting aspect for Feature Policies that while wide browser support is desirable for enforcement, for reporting only mode, where you get notified about issues with your website, partial browser support is often sufficient to solve the identified issues for users of all web browsers.

Summary

This ends part 1 of our series of posts on contributing back lessons learned from AMP to the whole web. Thanks to the whole web community for the amazing help in getting these standards proposal on track and the great feedback to make them much better than we could have ourselves!

Next up in this series of posts is Privacy-preserving instant loading and Innovation in navigation. They’ll be posted on this blog in the coming days.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google

Signed-Exchange: Solving the AMP URLs Display Problem

Signed Exchanges

Editor’s note: the below was originally posted on Medium by Sarang Khanna, Software Engineer, OYO

For an AMP Page at URL example.com/awesome-amp-page, your SEO users are probably seeing this — google.com/amp/s/example.com/awesome-amp-page. At OYO, we solved the much dreaded AMP-Cache URL display problem for good, without losing any AMP benefits!

As a fast and responsive web pattern, AMP has taken over the web. But a major concern about AMP pages is that whenever users land on the page from a Google search, the displayed URL is never the publisher’s original URL. This has been a topic of both discussion and concern till now. Signed-Exchange is something which can help you show your own domain in AMP page URLs, with all the AMP-Cache capabilities intact.

AMP URLs can now be the page’s original domain (notice the address-bar)

TLDR;

Prelude AMP enjoys caching benefits on Google’s Search pages. Opening an AMP page from Google Search Results (the ones with the symbol) shows a “pre-fetched” version of the page coming from Google’s own cache. Hence, it opens with lightning-fast speed, as there is absolutelyno document-fetch done over the network upon clicking. (Read: OYO’s starting steps with AMP)

The issue However, since the content is fetched from Google’s Cache Server rather than the Publisher’s actual server, the URL shown to the users for that page starts with something like google.com/amp/s/,and is not the page’s actual URL.

Before the Fix: An AMP page opened from Google Search Results

This leaves chances of doubt about the authenticity of the page’s content for the end-user. However, now there is a way to solve this issue and show the page’s actual URL, even when it’s served from Google Cache.

The solution 

The solution resides in implementing Signed Exchange — which basically lets you “allow” third-parties (like AMP-Cache) to be able to serve your page’s content from their servers but the browser can show your domain and URL in the address bar.

What is Signed Exchange and how can it help? 

Signed Exchange (or “SXG”) is an emerging technology which provides a way to prove the authenticity of a web document. This can be used to determine a page’s original publisher, no matter where the document is served from.

A publisher can “sign” an HTTP request-response pair with their domain’s certificate. Thus generated signed-exchange can be served to browsers, similar to web pages! With it, the browser can safely show the publisher’s URL in the address bar because the signature proves that the content originally came from the publisher’s origin.

Simply put,

Signed-Exchange = A Web Page + Certificate of its Origin

This can allow us to improve AMP URLs. The idea here is to serve a signed-exchange for Google’s AMP crawler to cache, instead of a web document, when your AMP page is crawled.

Subsequently, now when a user will select your page from Google Search, the cached signed-exchange will be served from the AMP-Cache to the client’s browser . It will allow the browser to show the actual page URL (even though the page came from a Google Cache server).

(How HTTP Signed Exchange works to deliver better AMP URLs)

See it in action. 

Google has announced the support for Signed Exchanges in Chrome and has adopted it for the benefit of AMP on it’s search result pages. The current browser support is Chrome 73 and above.

So go ahead on Google, search an OYO city and look for the lighting-symboled AMP pages. Keep an eye on the address bar to see the magic of SXGs.

The following section explains how we enabled Signed-Exchange to have actual URLs displayed for the AMP pages being served from Google…

Implementing Signed-Exchange to show your own domain in AMP URLs. 

  1. Get a Digital Certificate for your domain
  2. Set-up a packager (signer) for your AMP pages (See deploy-amppackager-aws for help!)
  3. Proxy your AMP pages through the packager before serving them
  4. Profit!

1. Get a Digital Certificate for your domain

For signing the HTTP request-responses for AMP pages, you need to get a Digital Certificate issued for your domain.
Note: The private key must be ECDSA, curve secp256r1. And the certificate should have the CanSignHttpExchanges extension enabled for production use.

Psst! For testing purposes, you can use free certificates or self-signed certificates. For production use, DigiCert issues the certificate with the needed extension.

For reference, here is how to generate an EC P-256 key and a Certificate Signing Request (CSR) which you can submit to CA for signing:

## To generate a new EC P-256 private key
openssl ecparam -genkey -name secp256r1 | openssl ec -out privkey.pem
## Generate a CSR using the key:
openssl req -new -sha256 -key privkey.pem -nodes -out ec.csr -outform pem

Give the CSR to a CA who will issue you a new certificate for the private key. For SXGs, you will need the privkey.pem and the issued Certificate Chain, fullchain.pem.

2. Set-up a packager (signer) for your AMP pages

Next, you need to run a “Packager” server, something which will sign (or, “package”) the required pages using your certificate and it’s private key.

Thankfully, the AMP team has come-up with the amppackager tool, a Golang server for this purpose which anybody can use with minimal configurations (GitHub repo).

All you need to do is fetch the tool, provide your configurations (the path to your certificate, your domain name and the URLs to sign) and run it. On local machine, you can try it out with a demo request and it should serve a signed-exchange for your page!

AMPPackager Basics: By default, amppackager listens on port 8080. Suppose it is running on localhost:8080, it serves the signed-exchanges on URLs of this format:

localhost:8080/priv/doc/<Document's URL>

For example, the signed-exchange for https://www.oyorooms.com/hotels-in-delhi/ (AMP Page) will be served at: 
localhost:8080/priv/doc/https://www.oyorooms.com/hotels-in-delhi/

It serves other resources like certificate information on the URLs of this format:

localhost:8080/amppkg/<Path to Resource>

Note: Productionising the amppackager tool is still very vague.
We have open-sourced a boilerplate deployer (GitHub: deploy-amppackager-aws), which can be used to deploy amppackager on AWS Elastic Beanstalk! Use it for reference on how we streamlined the flow and put it to good use on OYO production.

3. Proxy your AMP pages through the packager before serving them

Upto this point, we have an amppackager server running to sign our AMP page requests. Time to look into which pages need to go through the packager and under what conditions.

Let’s address the exact requirements here (for the amppackager tool):

  • All requests starting with /amppkg/ path should be forwarded to the amppackager server unmodified.
  • For AMP page requests having the AMP-Cache-Transform header present (Google Crawler will have it, to indicate that it accepts SXGs), rewrite the URL to prepend /priv/doc and forward the request to the amppackager.
  • While serving AMP pages, set the Vary response-header to AMP-Cache-Transform, Accept. (Google Crawler will look for this header before asking an SXG from you)

Here is an example for a frontend Nginx proxy with the amppackager running on an upstream server amp_pkgr:

###
### AMP Packager resources:


location /amppkg {
# to amppackager, unmodified
proxy_pass https://amp_pkgr;
}



###
### Pages which are AMP:


location ~* ^/(.*)/amp {


# check for the "AMP-Cache-Transform" header
# (which Google crawler requests will have)
# to selectively pass this request to amppacakger or
# your usual web server
if ( $http_AMP_Cache_Transform ) {
rewrite /(.*) /priv/doc/https://$host/$1 break;
proxy_pass
https://amp_pkgr;
break;
}



# add "Vary" response-header for normally served AMP pages
# (responses from amppackager will already have the header)
add_header Vary 'AMP-Cache-Transform, Accept';


# proxy pass to your usual AMP pages' server
proxy_pass https://website_server;


}

Troubleshooting

  • It may take Google’s Crawler some days to cache your AMP pages as Signed-Exchanges.
  • Avoid proxying non-AMP pages to amppackager.
  • Don’t expose amp_pkg to the outside world; keep it within your internal network.
  • Set up your amppackager server to be scalable as well as secure. It is a machine that will probably hold your certificate and private key too.

Links to infinity and beyond 

Hope you’ll enjoy the journey from google.com/amp/s to yourdomain.com as much as we did. Thanks for reading… Have a cookie!

AMP as your web framework

Developer Experience

Update (5/2/2019): Added a paragraph to clarify compatibility with other frameworks (to not suggest a zero-sum game), and removed some language on how AMP was misunderstood that wasn’t needed to get the point across.

Read a blog post comparing popular frameworks lately? Participated in a frontend tooling survey? I can almost guarantee that AMP was not on the list. Which strikes me as odd, considering the millions and millions of domains running it. So, how come?

Here’s the content of this blog post in super over-produced video form. You should watch this. Trust me. It’ll be worth it.

How we got here: HTML vs. JS Frameworks, perception as distribution format, and paired AMP

The first reason why AMP isn’t perceived as a framework is that AMP isn’t a JavaScript framework. It’s a framework written in JS, but the authoring language for you is HTML, so technically it’s an HTML framework. The idea of HTML Frameworks isn’t new but they’re still fairly rare, so they are often not considered a serious alternative.

The second reason is that many compare AMP to RSS, and the media positioned it as competitor to certain other big companies’ walled garden media formats. That narrative certainly didn’t help, and for what it’s worth, we, the AMP team, never loved that comparison (but we also did our part we did confuse people with complicated words such as runtime and AMPHTML format). Web pages are already a great distribution format, and AMP just improves upon it by accelerating delivery via AMP caches and by bundling the main content further, for instance by inlining CSS.

And third, most AMP sites today use Paired AMP, a technique we allow to connect an existing non-AMP webpage to an AMP equivalent. Look, Paired AMP can be useful because the initial investment is much lower: If I packed my bag and later realize I want to pack more stuff, I can just pack another one and travel with two, but it gets really annoying. The same is true for Paired AMP. It’s super hard to maintain both versions over time, and Paired AMP was never meant to be the end state. (That’s why we’re now calling it Transitional mode in AMP for WordPress).

From Accelerated Mobile Pages to AMP

https://blog.amp.dev/wp-content/uploads/2019/04/only_amp.mp4

Even our name has been a cause for confusion. I’ve been struggling to properly explain what AMP is for a while now, especially to those who are familiar with its long form: Accelerated Mobile Pages. The reality is that we’ve outlived our own name long ago:

  • AMP isn’t just accelerated, it comes with all sorts of built-in UX advantages (e.g. disallowing interstitials, enforcing a free main thread for smooth interactions).
  • AMP isn’t just for mobile, it not only works across many device types including Desktop and tablet but comes with super handy responsive design features
  • And AMP doesn’t just power pages anymore – you can now build ads, emails and stories with it.

So, what’s the solution? Easy: As announced by AMP’s tech lead Malte at AMP Conf, AMP is now just AMP, and does not stand for Accelerated Mobile Pages anymore (if you must have an expanded form, how about Awesome Magical Power).

From page to site: Going AMP First and using AMP as a service

We, the AMP team, want AMP to become a natural choice for modern web development of content websites, and for you to choose AMP as a framework because it genuinely makes you more productive. This represents our core mission this year, and we’ve rolled out our new site at amp.dev (along with plenty of new content and beginner-friendly courses) to help you do it. So what do you get when you embrace AMP as your development framework (besides the obvious, like speed, UX, easy to use components)?

For starters, you’ll focus more on layout, style and content, and less on boilerplate code. Web development has gotten too hard, and it’s more important than ever to choose the right level of abstraction, with just the right amount of flexibility for your use case. We’ll worry about maintaining the JS for all components, and will ship backward compatible updates every two weeks. We call this way of lowering your maintenance burden “AMP as a Service” (watch Naina’s excellent talk on the topic).

You’ll now only maintain one version of each page by making your AMP canonical, or so-called “AMP first“, and that means your pages benefit from AMP’s performance and UX optimizations across Desktop, mobile and beyond.

Bento: Mix and match AMP components on non-AMP pages, interop with other frameworks

Watch the Bento announcement in What’s next in AMP from AMP Conf ’19.

AMP First doesn’t mean that strictly all pages of your site must be AMP – sometimes you might want maximum flexibility and distribution is not a big concern, like with a member-only area or complex shopping cart. In that case you could use vanilla JavaScript or another framework to power that part of the experience.

To then make it possible to re-use existing templates you’ve built with AMP components, we’re working on what we call Bento AMP, the ability to use AMP components in an “un-managed” way, without loading AMP’s main JS file (v0.js), and coexisting with other web components and frameworks on the same page.

This, along with frameworks like Next.js adding support to server side render AMP and amp-script, the ability to run custom JavaScript in a web worker, means AMP and other frameworks can co-exist peacefully and can make each other stronger, which we’re really excited about.

Accelerated development with support for JS and running AMP components outside AMP

Of course, it might not make sense for you to drop everything and reimplement your site in AMP today, and that’s OK! I just want you to know that we’ve grown up quite a bit, and when you set out to redesign or create something new, AMP is here to help you succeed.

With the dynamic state binding capabilities of amp-bind, the dynamic data fetching of amp-list and the ability to use custom JavaScript via amp-script, the possibilities for content sites are now endless. And with new open project governance in place, the future of AMP is open for everyone to shape – everyone who wants the web to continue to flourish.

Posted by Paul Bakaus, Developer Avocado, AMP