We’ve updated the AMP Roadmap to reflect some of the progress made in the first quarter of 2017. You can read more about some of the highlights below.
We continue to place a big focus on making the AMP format conducive to more interactive and engaging user experiences. We’ve made amp-bind, a flexible event binding system that enables vastly more interactivity in AMP, available in an experimental beta release. This means you can test out some of the basic behaviors of amp-bind, such as how it can work together with an image carousel—but amp-bind won’t yet be valid for use in production AMP pages until its launch, which is targeted for later this quarter.
We’re also working on scroll-dependent interactions. We’ve started by directly addressing two concrete use cases: parallax scrolling and contextually-displayed headers. In addition, we’re working on a general, flexible framework for scroll-bound animations.
Finally, earlier this month we launched AMP Start, a collection of quick-start code templates and components, intended to give developers and designers the tools to create great-looking AMP sites quickly and easily. In the coming weeks we’ll be working on ways to make it easier to use and configure these pages without having to edit the code directly.
We’ve made an update to sticky ads by removing the restriction to load the ad only after the first viewport – this should boost viewability. We’re hopeful this change can also drive greater monetization due to the viewability increase for your sticky ads implementation. We’ve also updated the sticky ad to collapse when there are no ad fills instead of displaying an empty container.
In addition, this quarter we reached the milestone of 100 ad networks supporting AMP. To help these ad networks serve AMP ads, Cloudflare has launched an ad network implementation that makes it easy for any ad network to serve them. In addition, Cloudflare launched Firebolt, a suite of services that makes it easy for publishers and ad networks to serve AMP ads.
We’ve launched support for dynamic call tracking, which is typically used in ad landing pages for identifying ad attribution.
In the next quarter, we’re working on performance improvements to non-AMP ads being served to AMP pages. In addition, we’ll also be working on serving AMP ads to non-AMP pages.
We expanded support for variable substitutions, notably Client ID, to links and forms. The former can be used to manage user state involving multi-page sessions. The latter is useful to build add-to-cart flows for e-commerce.
We also completed a migration to Intersection Observer to support visibility features. You’ll hopefully notice no changes as a result of this migration. It does, however, shift AMP analytics toward a highly respected approach for measuring element viewability. We also introduced a new trigger, “ini-load”, which is triggered when the initial contents of an AMP element or an AMP document have been loaded. In contrast to the document-level “visible” trigger that has long been available, “ini-load” used at the document level will not fire until all of the content elements visible in the viewport are also loaded. This is helpful to support AMP Ad–related features and offers a different way to measure engagement based on actual content visibility.
Finally, we’ve started a project that will enable extensions to take advantage of amp-analytics to report data to extension authors so that extension authors have greater visibility into how their extensions are performing.
* * *
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 Rudy Galfi, Product Manager, AMP Project