cramforce

The AMP team 100% agrees with you. But the project goal is to be fast in current generation browsers. As soon as the current generation can perform well with more relaxed rules, the rules in AMP can be changed accordingly.

This would typically be added by a CMS or similar software. Note, that only the aspect ratio is required (including support for media queries), so you don't have to know actual pixels which may be device specific.

This already happens, but the extra roundtrip still kills performance.

Not having to make an extra HTTP request is the only way to get good performance in this case.

I'm the tech lead of the AMP project.

Our work was mostly related to ensuring that native scrolling of the main page works as expected when the finger touches the ad iframe. This is non-trivial and most implementations do it by forwarding touch events from the ad up to the page, which then feels laggy and leads to touches that are interpreted as clicks.

The primary (but not only) reason is increase in so called viewability of ads (AMP renders fewer ads that nobody ever sees). Because click-through-rate is calculated as percentage of "renders", rather than "views", the CTR goes up when you have less "renders" that don't turn into a "view", because nobody can click on an ad that they have never seen.

Would you mind filing an issue with an example article: https://github.com/ampproject/amphtml/issues/new

This is definitely not a known issue.

Edit: We can repro and filed https://github.com/ampproject/amphtml/issues/3481 It might be a bug in Google News (Because Google Search is fine), but we'll track it in AMP.

We spent a lot of time making accidental clicks unlikely (and making sure that scrolling on the ad scrolls the page)

One other benefit is that because the ad is on a parallax pane, it can resize itself without disrupting the page flow (which AMP does not allow).

That is exactly what we are doing. We spent roughly 4 weeks of pure research to get the scroll UX to 100% perfect (Turns out making a fixed positioned background element scroll the main scroller and be clickable is hard. Which is also why many implementations of flying carpet suck).

The goal is absolutely to make this not annoying at all.

You know, I think it would be great if web browsers fixed things. AMP is fixing a very real problem that users have today.

If and when browsers change (including those used by a lot of people that only update once a year) AMP can just change its guidelines. These are things people have to do today anyway to get fast sites. AMP just packages up in an easy to consume package.

amp-iframe is what you want is this case.

See https://medium.com/@cramforce/2016-will-be-the-year-of-concu... for the long game as to how to build such things in AMP without iframes.

Actually not at all. AMP is specifically designed with HTTP/2 in mind and takes full advantage of it. E.g. it loads articles, scripts, images, fonts, etc. through a single HTTP 2 tunnel.

Yep, we're not done. Being careful with defining this finally because it can basically never be changed. Follow the project for details.

It has an implementation in Chrome and Firefox and both Microsoft Edge and the WebKit teams have indicated that they will support it. On top of that there are 2 super excellent polyfills.

In the world of the web platform it doesn't get much more standard than that.

I totally agree that the "penalizing" approach is important.

But I like to present both a solution "this is how you make it fast" as well as the penalty.

If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.

Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile...

<amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work.

<amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks.

You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/

We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.

To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.

In case you haven't tried, check out this video https://www.youtube.com/watch?v=i2_lAEzmOPo&feature=youtu.be I so much want my experience to be like that (or try g.co/ampdemo on your phone yourself).

One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.

With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.

That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.

A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.

I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change. 't

Business model is the same as any other content website. Monetization through ads, paywalls, etc.

Same as before, just with happier users including myself. Happy users are good for business in the long term.

This is kind of orthogonal to RSS. AMP and RSS work great together. Your feed reader can detect that the feed item URL has an AMP alternate and chose to display that instead.

We support currently many / future most (if they chose to participate) ad networks and there is no rev share.

Exactly. AMP is very much about addressing that issue.

You might get it :) There isn't that much to it. AMP is as much about technology as finally getttig that tech adopted. Since AMP is built on web tech there is nothing in it that you cannot chose to do yourself

The problem we are solving is that many sites don't.

Its a joined project by many partners. See other comment in thread for details.

Yep, I'm a Google employee. ampproject.org has the full list of partners working together. One example is https://blog.twitter.com/2015/introducing-accelerated-mobile...

Many ad networks are supported already, all will be. There is no rev share at all.

OK "just web technologies". I stopped seeing HTML as just the markup language, but I'm fine with people liking that distinction!

AMP is two things: Technology and a strategy to adoption. The latter was missing so far or load times wouldn't have been as bad as they were.

Custom elements are a thing in HTML. Using them doesn't make it a superset. http://w3c.github.io/webcomponents/spec/custom/

Also: We can use a Service Worker for reliable caching of the JS.

We'll most likely relax this. Related to embedding fidelity.