Accelerated Mobile Pages are just like any other HTML page, but with a limited set of allowed technical functionality that is defined and governed by the open source AMP spec
And from the Spec:
Enable the AMP runtime to manage the loading of external resources, which may slow down the initial render or cause jank. Allow AMP authors to include functionality above and beyond standard HTML, while maintaining the security- and performance-minded requirement that no author-written JavaScript is executed
Appears we won't have access to Canvas2D, WebGL, WebRTC, Fetch and other HTML5 Web APIs. AMP's subset of declarative elements and caching will be great for longform-y "static" content. The kind of articles I find myself reading more of on Mobile Chrome during down times in transit. Thinking of Medium confessionals and NewYorker dispatches, etc.
But how do you implement something like ChartBeat? Snapshots of dynamic chart images and data pre-rendered on the server and pushed out to the cdn? Sort of eliminates the performance benefits of geospatial caching doesn't it...
I do take heart however in Tony Haile's pull quote from the ampproject.org homepage:
The mobile open web experience is terrible and some have suggested it's too slow to compete. We can choose to see the mobile open web as a relic of its time and flee to the warm embrace of closed platforms and apps. Or we can say that the open web means something important to the world and if it’s broken it’s our job to fix it. I think we should fix it.