In my mind I actually separate it into three (from Google):

- The specs/docs for building AMP pages, which can be found on www.ampproject.org - note that, a lot of these are non-free, like standardized components for specific media/social sites, and requires you to include script tags for cdn.ampproject.org component implementations. This all tells you how to add an AMP version of your page to your site, and how to link it to the original content.

- The "Google AMP Cache" CDN that hosts cached versions of AMP pages under .cdn.ampproject.org - it seems that anyone can use this...? Note these are in a separate context than the google search result page (that people think of as "AMP pages") which means a generic XSS on AMP isn't an XSS on google.com.

- The integration into Google Search. On the frontend this looks like some javascript that preloads iframes to the .cdn.ampproject.org page for results, and also uses History.pushState() to give you the google.com/amp/foo.com/ urls. If you go to those URLs directly you'll get redirected (that's the server-side implementation of them and why you don't ). There's also some crawler (and ranking?) implementation too, presumably.

A lot of discussion about AMP seems to muddy all three of these things together, which is a bit unsurprising considering Google's messaging muddles them together, but I think it's important to distinguish between them. In the "Twitter AMP redirect" case of the article, only the first portion is coming into play.

As an aside - if you're interested in seeing how AMP works under the hood I highly recommend the Chrome Android USB debugging - I hadn't played with this before trying to figure out how AMP worked and it was really a godsend to be able to "Inspect Element" on my phone, especially because anything AMP-related is very aggressive about only AMPing to phones on cell networks.

>Good news! iOS 11 fixes this.

It doesn't fix the "crappy wrapper that wants to do its own scolling instead of complying with the system" issue though.

Well, the wrapper has the same scrolling as the rest of the system and pages now.

Yes, but still implemented non-natively -- along with all kind of other bizarro differences that might be lurking.

No, AFAIK the only reason that view had different scrolling was because it was an overflowing div which had the -webkit-overflow-scroll: touch property to give it any momentum.

This page should demonstrate the same scrolling behaviour as AMP pages on iOS, without any 'custom' non-native scrolling https://s.codepen.io/joshhunt/debug/Xgeyoo

I worked on a website that experienced this same problem several years ago. The designers were pretty insistent on a design that would require the crappy non-native scrolling, but luckily management stepped in and said no to them.

Point being, UX should dictate design, not vice-versa. If you can't implement something the way you want without messing up something as important as scrolling then don't do it.

The irony here is that the two most important features of the web are arguably URLs and scrollable pages. And AMP screwed up both of them.

It is implemented natively. It's just a scrolling div versus a scrolling page. It's not a custom scrolling implementation.

My thoughts exactly. Remember blogspot hijacking horizontal swipes? Ew!

"Remember"? It's still the case everywhere and it's obnoxious

Do you think lots of the complaints would go away if publishers could opt-out (or opt-in, but that seems more fanciful) of the CDN preloading? Obviously you'd lose those attendant benefits from the CDN, but there still seems to be a lot of gain from the spec.

Re: two products, I realized this but never really thought about it. Can one self-host an AMP (framework) implementation? Does Google still promote such content, even if it isn't part of their CDN?

Sure. It's just a stricter subset of HTML and a JS library for custom components. Self host it.

No, Google won't give you the special AMP-bolt - nor should they because they can't provide the instant load as they can for other AMP sites that they self-host on their CDN.

That's where I have trouble accepting AMP. I love the concept and Google's support would be huge, but Google doesn't seem to be truly promoting making the mobile web better with AMP. They are promoting making the mobile web better with their CDN (i.e. by centralizing/controlling the content).

I actually converted my blog (http://dangoldin.com/) a while back to be entirely in AMP. In this way I'm using the framework without caring about the CDN element.

After reading this I may just bite the bullet and remove AMP and just cut out a bunch of crap to get it optimized for lower bandwidth devices.

It could be re-implemented, it's just "web components" last I looked