cramforce

AMP only starts loading ads after the content loaded anyway.

Ads can be served from the publisher's server, but this is rarely done.

WebKit bug to follow on scrolling inertia being different for overflowed elements from the main scroller https://bugs.webkit.org/show_bug.cgi?id=162499

Only data in the first viewport is loaded during pre-rendering phase.

It is not true that AMP does not accept contributions. What is your data to back that up?

Here is actual data: https://github.com/ampproject/amphtml/graphs/contributors AMP currently has 275 contributors (people whose code was merged) on its open source project. Lets aim high and say 50 of them work for Google (probably a bit less), that leaves about 225 other contributors.

Google could have, indeed. We were aiming at instant loading, though, and for instant loading we needed to do pre-rendering, and the only known way to do that does not allow for changing the origin (has to stay https://www.google.com).

We are working on a few ways how to both make access to the base URL easier and how to eventually even get the right URL in place.

AMP supports many dozens of ad providers. 2 of them are owned by Google.

We are working on a direct path from AMP pages loaded from Google Search to the canonical to fix the link issue & sharing will use the canonical link where technically possible.

There is lots of recent data out there. The general trend is that those findings from the mid 2000s hold even more true today. People are much more sensitive to latency, while the problem has gotten harder due to last mile flowing through congested air. https://www.doubleclickbygoogle.com/articles/mobile-speed-ma...

They won't unfortunately implement that caching scheme, because that leaks the sites you have visited to attackers.

See https://github.com/ampproject/amphtml/blob/master/ads/README...

I think with the numbers of ad tech companies coming on board every week one can safely say that the process is working for them.

If you have an alternative implementation strategy that enables pre-rendering and swiping while showing the source article origin I am all ears.

We can do it in our native apps, and we do.

The UI logically and visually belongs to the opening app, indeed. If the page itself opens a modal it opens on top of the bar and it's close button closes that modal.

There are things that can be done with AMP, that cannot be done with regular fast results (and you can very much build pages that load faster than AMP not only as fast!): - pre-rendering - result swiping

The banner is needed to show the logical origin, given that the browser is still on Google.com and the article is shown in a iframe (to enable pre-rendering). Our native apps do not have this constraint and thus don't have the extra bar.

I can't give you a 100% reason for the X. I know multiple UI versions were tested and this did well.

The pre-rendering is one feature that requires a trust relationship between the host (to only serve valid AMP) and the platform. Otherwise the page may e.g. use a lot of CPU while in the background.

That is where we currently are. In our user testing it tests really well, but there appears to be confusion in this community which would be good to address.

My current feature request is to link the "publisher domain" to the origin article, so that one can always click that to get there and use it to copy the link.

AMP works great in Firefox (modulo this bug right now https://github.com/ampproject/amphtml/issues/5479 :) and all other modernish browsers. Google Search currently chooses not to display it for FX, but that is not due to a limitation in AMP.

Well, it certainly works with templates (like the WordPress AMP plugin), but that only gets you that far. It is definitely work to adopt AMP, but most people who have done it are pretty happy with the workflow. We are always listening for feedback, though, and are looking for ways to make it easier.

Somebody is currently doing that:

An external contributor is currently building first class support for "My simple ad network that just wants to put an image with a link on the page" https://github.com/ampproject/amphtml/issues/5541

There are other ways to do it, though.

Happy to address the close button:

You are on a search page, you go on layer deep by clicking. The close button goes back. I don't see what else it should do. Mind you that I do understand that a link to the origin server would be a good improvement (and I've stated that in the post).

I'm not sure what you find disingenuous. AMP are just web pages saying "HEY I A AMP, please use treat me as AMP". You can publish the same bytes minus the "HEY I A AMP" and get the old behavior.

Posting my comment from the article here:

Hey, this is Malte and I am the tech lead of the AMP Project for Google. While I work on the AMP open source project, I did check back with the Google Search team that is more directly responsible for most of the points mentioned in the post. I personally find it very important to respond, because “stealing traffic” is literally the opposite of what AMP is for. The original idea behind AMP was to allow content to be distributed to platforms (such as Google, Twitter and Pinterest) in a way that retains branding and monetization control for the publisher. AMP traffic is the publisher’s traffic. Period.

I also realize that “just turning on the WordPress plugin” doesn’t get you there. Especially if a WordPress installation is heavily customized, one will need to invest similar effort to get the AMP pages to the same quality. While this may be a lot of work, this is by design: We recommend to really optimize AMP pages and fine tune them to your needs. AMP is not a templated format for that reason. While neither the AMP project, nor Google are directly responsible for the WordPress plugin, the AMP open source project working closely with the authors of the plugin(s) to improve the quality and scope. AMP is very flexible and should be capable of providing most features of a typical WordPress site, but this flexibility also requires respective work to make custom plugins and development show up in the AMP version.

Getting more literal about “stealing traffic”: there are audience measurement platforms that attribute traffic to publishers. They might in theory wrongly attribute AMP traffic to the AMP Cache (not Google) rather than to a publisher because they primarily use referrer information. That is why we worked with them in worldwide outreach to get this corrected (where it was a problem), so that traffic is correctly attributed to the publisher. If this is still a problem anywhere, AMP treats it as a highest priority to get it resolved.

“Ask Google to give users an easy option to view the original post.”

Let us start by saying that we love URLs as much as everyone else, and we tried hard to make the AMP URL scheme as usable as possible given the technical constraints of web apps. We’re looking at ways to make the source link more discoverable and will update once that is done. AMP is super flexible in terms of how a publisher can direct traffic to their site. Typical ways to get to a publisher’s homepage (like clicking the logo) should just work and are in no way restricted. Also, make sure to check out amp-sidebar (https://ampbyexample.com/components/amp-sidebar/) for adding a menu to your AMP pages.

If you are not comfortable with traffic on your AMP pages, please do not publish AMP pages. Google Search has 2 types of AMP related features:

Normal search: AMP does not influence ranking. Your pages will appear in the same spot with or without AMP. AMP specific features (such as the “Top Stories Carousel”): For these features, we believe that AMP is the format that currently delivers the best possible user experience on the mobile web. That is because AMP allows for consistent speed, caching, pre-rendering, and enables swiping between full-length pages. This is a big deal for topics where there isn’t “that one best result” that a user might want to look at.

“Google takes away ad revenue on AMP pages”

AMP supports over 60 ad networks (2 of them are owned by Google) with 2-3 coming on board every week and makes absolutely no change to business terms whatsoever. There is no special revenue share for AMP.

“If Google cares so much about the mobile experience, why cover 15% of the small mobile screen with a fat bar at the top?”

The Android users might have already noticed that it is now scrolling out of the way and the same is coming soon for iOS (we’re just fighting a few jank issues in Safari). Similarly we’re spearheading a long term effort (https://github.com/bokand/NonDocumentRootScroller) to allow web apps to define how the address bar is hidden on scrolling. It looks like this will land in Chrome soon, providing even more space to web pages.

With this solution they can't outside the comments because their JavaScript does not run on the page directly.

This is a different feature unrelated to the launch today. It doesn't always show on top, but often will because the sites posting AMP content tend to rank well.

Update happens independent of crawler and you can ping for it https://developers.google.com/amp/cache/update-ping

Even if this would be correct (which it is not), it would only require to observe, not influence scrolling.

Everything scroll related is in CSS. The long explanation is here https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...

This is just CSS which exists for unrelated reasons.

Note, that this launch is explicitly not a ranking change. Your non-AMP result will continue to be displayed in the same spot.

This is just a frontend change: If there is an AMP version of a URL, link there is instead.

Forms support is launching within a few days/weeks.

AMP doesn't implement scrolling in software. It is native GPU accelerated scrolling. iOS does have 2 modes and it might be that AMP hits the one some people don't like.

Edit: Filed https://github.com/ampproject/amphtml/issues/5125 to see if AMP can switch to other GPU scrolling mode.