[aaronm67]

> It is not a requirement for AMP. CDNs now let you roll your own domains on the AMP standard

All these certificates do is make it so Google's browser (and only Google's browser) will mask the fact you're on Google's domains if you sign the file a certain way.

If anything, this shows more anti-competitive practices -- they're adding features into their browser that specifically benefit a features of their search engine.

[bduerst]

That's not true. CDNs also use their own non-Google domains and infrastructure for AMP hosting:

https://amp.cloudflare.com/

[manigandham]

Effectively 0 AMP sites are using anything other than Google's CDN.

[leereeves]

Is this link using Google's CDN?

https://amp.businessinsider.com/lambda-school-online-coding-...

[manigandham]

Yes, sites just host the original copy submitted to Google. You can see all the resources are loaded from https://cdn.ampproject.org

If you visit the page from search results (which is the only place it would be linked) then it would never leave Google's domain.

Here's the actual URL used from search results: https://amp-businessinsider-com.cdn.ampproject.org/v/s/amp.b...

[d1zzy]

But as long as it's possible it doesn't qualify as lock-in.

[manigandham]

You don't need lock-in to be anti-competitive. The requirement of extra work to implement AMP to get that higher search results page placement is the issue.

[d1zzy]

At which point pushing for new technologies as a private entity is anti-competitive vs moving technology forward?

If the criteria is just "needs extra work" then unfortunately almost nothing can change and we're all going to live with the existing technology. Change inherently has friction and requires "extra work" with the hope that's an investment which provides returns long term.

In other words, say you are a large Internet company that is trying to improve web page loading times. You profile why most web pages are slow and identify issues. You publicly report on those issues and develop guidelines and criteria. Nobody bothers because "extra work". You develop new technology that directly addresses those issues, this technology works within the existing environment but it requires both client and server support to be most effective. Do you think anyone cares? No, because of "extra work". That's why there needs to be incentives. Now you have a "penalty" for not doing that "extra work". You can file it under "it's anti-competitive" (maybe it is) but if you do the "extra work" then suddenly the anti-competitive part works for you, not against you. IMO that's why it's not anti-competitive.

Other examples: why do you think there are so many people that complained when iPhone released with Flash reader? "extra work". Similarly when it removed the audio jack. Change is friction and friction is extra work. But most of the time that's not anti-competitive...

[manigandham]

Let me explain based on my 15 years of adtech experience:

HTML is already fast (see HN for an example). HTML is already universal across devices and browsers. HTML is already published and easily cached for billions of pieces of content.

AMP is a fork of HTML that only targets mobile browsers specifically linking from Google search results. It's useless on its own, but AMP is required to get higher placement on search results pages, so publishers are effectively forced to spend technical resources to output an entirely new format just to maintain that ranking.

If Google wanted faster pages then it can do what it always does and incentivize that behavior by ranking results based on loading speed. These signals are already collected and available in your Google webmaster console. There's nothing new to build, just tweak ranking calculation based on existing data. Sites would get faster overnight, and they would be faster for every single user because HTML is universal.

Do you know why they didn't do that? Because it's the ads and tracking that's slow, not the HTML. Google's Doubleclick and Google Analytics are the biggest adserver and tracking systems used on the web. This entire AMP project is created to circumvent their own slow systems. It creates more work for publishers while increasing data collection by running a "free" CDN that never leaves a Google-owned domain and thereby always supports first-party cookies. It's a perfect solution to protect against anti-tracking browsers and why Chrome now will also block 3rd-party cookies, because it won't affect AMP hosted on Google domains.

[IfOnlyYouKnew]

So the user sees your URL, you're getting the revenue from the ads that are shown, sharing will share your URL, your statistics work flawlessly.

In other words: if it behaves exactly as a page hosted on your site (just faster), why do you care?

I'm getting the impression that HN users care a whole lot about seeing the request in the nginx log they are tailing.

[gpvos]

Well, as a user, I care about not announcing loudly to Google every single step I take on the web.

[lern_too_spel]

Then why are you searching on Google? That's where you would see an AMP page served from a Google AMP cache. If you searched on Bing, you would get AMP pages served from a Bing AMP cache instead.

[bashinator]

In the past year, I've seen amp pages increasingly often linked from all sorts of places (reddit, FB, here, etc) besides Google's search results.

[lern_too_spel]

AMP pages hosted by the publisher, Google's AMP cache, Bing's AMP cache, or some other company's AMP cache? GGP was complaining about sending any information to Google. Only one of those options does so.

[gpvos]

I am obviously not.

[manigandham]

It's not always faster. There are plenty of performance and usability issues with AMP pages, not to mention all the extra development effort needing to maintain a different version of the site just for a few mobile browsers.

[modo_mario]

It's anticompetitive af.