One of the top pieces of feedback that people share about AMP is about the “google.com/amp…” URLs that are used when linking to a piece of AMP content in Google Search. A couple of months ago, the AMP team at Google outlined a plan to display better AMP URLs, and today we’d like to share progress on this effort.
Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the work of actually delivering that exchange to a browser. When the browser loads this “Signed Exchange”, it can show the original publisher’s web origin in the browser address bar because it can prove similar integrity and authenticity properties as a regular HTTPS connection.
Addressing this issue is great for users and publishers alike. Users see URLs that are consistent with their expectations based on the publisher identified on the search results page. Publishers benefit from retaining their brand in the address bar and the instant loading, thanks to pre-fetching.
To confirm the proposed tech works in practice, the AMP Project worked with two partners, Pinterest and Food Network, who signed their AMP content and published those signed exchanges to the web. To make this process easier, they used a new set of tools available at https://github.com/ampproject/amppackager. Additionally a non-AMP–specific package tool is also available at https://github.com/WICG/webpackage/tree/master/go/signedexchange.
The Chrome team has built enough Signed Exchange support for developers to try it out. Starting with Chrome 67 on Android—in Beta channel at the time of writing—you can enable the experimental “Signed HTTP Exchange” flag under chrome://flags to use Web Packaging’s signed exchanges. In parallel with this experimental implementation, the Chrome team has also been collecting feedback from members of standards bodies, other browser vendors, security experts, and publishers and web developers to refine and improve the Web Packaging specifications.
Last, to tie everything together, the Google Search team has implemented a version of Google Search that illustrates the end-to-end flow. When a signed exchange is available, instead of linking to an AMP page served from Google’s AMP Cache, Google Search links to a signed AMP page served from Google’s cache.
There’s a lot happening behind the scenes to ensure that opening a Food Network result from Google Search is blazingly fast!
As you can see in the animation above, the final URL for the AMP content is on the foodnetwork.com domain, exactly as desired, and with the fast load speed that people enjoy with AMP pages. We’re very excited to validate that the imagined approach works across multiple layers of technology. However, it’s important to keep in mind that it’s still early and what you see isn’t ready to ship. As noted above, we expect more feedback from browser vendors and the web community to further refine the Web Packaging related specifications and work toward finalizing them.
Please reach out if you’re interested in this area and we’ll continue our commitment to provide updates as there is additional progress to share.
Posted by Kinuko Yasuda, Chrome Software Engineer, and Eric Steinlauf, Software Engineer, Google Search