[lern_too_spel]

> No, none of this is needed. Make speed a factor in search results and sites get faster.

You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to.

> AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results.

If that's the case, why does Bing use it?

> It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.

What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with.

> Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers.

Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?

[manigandham]

It doesn't matter if it's prerendered, as long as it's fast enough, and fast HTML sites are fast enough. If AMP was so good then this entire SSR wouldn't even be necessary in the first place, let alone all the complaints about user experience and data.

You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification. It's more work for no gain. Google already has vast control over UX by using search results, the very same search results it currently uses to pressure sites to implement AMP.

If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight. It can do all of this if the intentions were pure, but it doesn't, because the only intentions are more control over publishers and data.

Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web. And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.

[lern_too_spel]

> It doesn't matter if it's prerendered, as long as it's fast enough, and fast HTML sites are fast enough.

If that were true, Bing et al would not spend resources maintaining AMP caches. It's clearly not true.

> If AMP was so good then this entire SSR wouldn't even be necessary

This just shows that you don't know what AMP does. It allows prerendering from the link aggregator, and it does this well enough that every competent search engine implements it. The problem this solves is that people share AMP links directly, which can't be prerendered because they aren't loaded until someone puts the link in the location bar. In this case, it is slower than plain HTML, but this isn't the case AMP is meant to solve. By using SSR, they can make it faster than most plain HTML and just slightly slower than hand-optimized HTML with above the fold optimizations.

> You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification.

The publishers use it, and as we demonstrated above with Bing's A/B testing, the users want it. What more justification do you need?

> If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight.

Who says they don't? None of those solve the problem that AMP solves, which is instant loading of pages .

> Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web.

It's the same with the search engines and AMP.

> And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.

So what you're saying is that RSS is exactly like AMP, where pubs can share as much or as little as they want.

[manigandham]

Your arguments are circular and repetitive. Publishers do not want AMP. Users dont care about AMP, just fast sites. "Instant" is a marketing gimmick and makes no material difference when sites are fast enough. AMP is not necessary to make sites fast enough.

Google can influence site speed through SERP rankings, speed that is lacking primarily because of its other products, but instead it's forcing AMP pages. This is the fundamental problem that you are not acknowledging. There is no way around AMP if you don't want to lose ranking on an existing search results page.

FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently. Apple News doesn't even support the web and can already accept RSS feeds. They also get plenty of critique that you're ignoring. Have you ever worked with a publisher?

[lern_too_spel]

Your arguments are unsupported by evidence.

> Users dont care about AMP, just fast sites.

Then why does every major search engine support it? They're trying to please their users, so they just need fast, not instant

> "Instant" is a marketing gimmick and makes no material difference when sites are fast enough.

Instant means actually instant, not just fast. Of course it makes a difference, or the search engines, Apple, and Facebook would not put in the resources to enable it.

Your current problem is that you're confusing your hatred for Google's search results ranking with AMP. If you don't like how Google ranks its results, just use a different search engine. Bing ranks differently and also uses AMP.

[manigandham]

The comments on this page alone are evidence, let alone the 100s of publishers my company has business relationships with and the feedback I get.

The only speed that search engines are responsible for is the results page. AMP has nothing to do with their user experience. And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.

And no, the ranking is not my problem. I don't know where you came up with that. The argument is that publishers lose ranking unless they use AMP and the same effective speed can be provided in much more neutral and friendly ways that doesn't require an extra copy of the site.

Anyways, it's clear that you're religiously defending AMP at this point with no acknowledgement of any of the arguments by myself or others on this page so I'll end it here.

[lern_too_spel]

> The comments on this page alone are evidence.... AMP has nothing to do with their user experience.

The comments on this page are from people who don't understand what AMP does and have a blind hatred for anything produced by Google, as I have repeatedly demonstrated. If people actually didn't like AMP, Bing wouldn't spend the money to support it.

> And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.

Where has that been stated several times? This is the first time you have used "Bing" in any comment in this thread. If it were really the case that people prefer slower loading articles, it would be a competitive advantage for a search engine not to support AMP.

> And no, the ranking is not my problem. I don't know where you came up with that.

Let me refresh your memory:

"There is no way around AMP if you don't want to lose ranking on an existing search results page. FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently."

Notice how you even confuse a publishing technology (RSS) with ranking.

> The argument is that publishers lose ranking unless they use AMP

Because users prefer fast loading results! If users preferred slower loading results, a competing search engine could rank non-AMP results higher than AMP results or not show AMP results at all to win users from the search engine that shows instant loading AMP results.

> with no acknowledgement of any of the arguments by myself or others

I've quoted your arguments and addressed each one. As I've shown above, you've pretended arguments were made that weren't, and now you're blaming me for not acknowledging these phantom arguments.

[dmitriid]

> The publishers use it

You mean those same publishers who now say that AMP is bullshit, doesn't deliver on any of the original promises and causes problems? https://digiday.com/media/google-amp-beat-facebook-instant-a...

> as we demonstrated above with Bing's A/B testing, the users want it.

Users want faster webpages. Thank you, Captain Obvious.

[lern_too_spel]

> Thank you, Captain Obvious.

Continuing in the Captain Obvious role, how do you propose to replace FBIA, Apple News, RSS, and AMP with something that both users and publishers love? AMP is just as fast as the first three, and it provides more control to the publishers than the first three, yet you are not ranting about the first three. Why?

[dmitriid]

> which AMP is the open alternative to.

It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]

The only reason AMP exists is because Google needed its own way to control content. That is it.

> If that's the case, why does Bing use it?

Because you're forced to compete against the behemoth on the behemoth's terms.

> What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages)

AMP's problems are well documented. You chose to ignore all of them and go for "instant loading pages".

> Yet only AMP gets the rabid hate. Why is that?

Because it reaches a wider audience and Google has the gall to call it "open" and "good for the web". It's neither.

> AMP is essentially RSS items

It is not like RSS in any way, shape, or form.

[1] https://news.ycombinator.com/item?id=16455593

[lern_too_spel]

> It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]

Your examples predate https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-pro... and no longer seem to apply.

> The only reason AMP exists is because Google needed its own way to control content.

That's nonsensical. Why then does Bing use it?

> Because you're forced to compete against the behemoth on the behemoth's terms.

Why are they forced to use it? I would really like to see your position stated coherently.

> AMP's problems are well documented.

How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?

> It is not like RSS in any way, shape, or form.

This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.

[dmitriid]

> Your examples predate <Advisory Committee>

Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email).

And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web.

> Why are they forced to use it? I would really like to see your position stated coherently.

Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features.

> How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?

There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes.

> This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.

I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators.

RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.

Also, RSS always leads to the original URL.

AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache).

They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.

They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed.

An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.

Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches).

[lern_too_spel]

> Advisory Committee has no say in anything that AMP does.

Why did you focus on one irrelevant aspect of that document? The document also includes the Technical Steering Committee, a majority of whose members do not work for Google. That doesn't fit your narrative.

> In order to compete with it you need to provide nearly all of the same features.

In other words, users want it.

> There are no bugs in iOS that preclude instant pages.

iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.

> RSS is a web feed.... There is no feed.

I was talking about items in the RSS feed as you quoted yourself in an earlier comment and then somehow forgot, but lets ignore this strawmanning and continue.

> That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.

So exactly the same as AMP.

> They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.

Aside from effort, this is exactly the same as RSS. The additional effort is from doing things that RSS cannot do like monetization, interactivity, analytics, A/B testing, and above the fold optimizations. Cloudflare handles that effort fine.

> An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.

Exactly the same as RSS. A link to an RSS reader is a link to the reader's URL, not the original URL.

[dmitriid]

> Why did you focus on one irrelevant aspect of that document?

Because that irrelevant part was the only one that would give AMP any semblance of being open.

> iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.

I advise you learn something for yourself. Several fixes were provided to AMP but they were rejected without discussion.

> Exactly the same as RSS.

Let's see how AMP is "exactly the same as RSS":

- RSS is a feed, AMP is not

- RSS feed is discoverable via a meta tag, AMP pages are not (you have to search in a search engine, or have a cache of pages)

- RSS is a simple format that can be trivially parsed to retrieve data such as: author, publish date, url to original page, description, and content. AMP requires a near-full HTML parser with AMP-specific extensions: AMP is not valid HTML 5, AMP validator will allow some non-valid HTML5. Additionally, AMP relies on custom elements.

- Any and all RSS readers and aggregators link to the original website in a trivial and discoverable way. There's no url hijacking. AMP all but requires AMP Caches to be fast, and AMP Cache design all but requires to display content not at the original link, but at the Cache's URL. For several years the "open" AMP would deny this was a problem and pretended "it was an implementation detail that AMP is not concerned with" and "we will work with browsers on how to present the canonical URL". And even now the largest AMP cache regularly employs dark patterns to prevent users from visiting the canonical URL.

So yeah. I see how AMP is exactly like RSS.

[lern_too_spel]

> Because that irrelevant part was the only one that would give AMP any semblance of being open.

No, that is the only part of the document when taken out of context that gives AMP any semblance of not being open. The TSC is what makes AMP open, and you ignored it and continue to ignore it after I explicitly called it out.

> Several fixes were provided to AMP but they were rejected without discussion.

Where?

> RSS is a feed, AMP is not

You need to work on your reading comprehension. That quote that you took out of context says that AMP is exactly like RSS on that particular point. I have repeatedly explicitly pointed out that AMP is like RSS items, not like RSS feeds.

Let me know when you're ready to continue the discussion in earnest instead of going to great distances to strawman every point.